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

نعرف نحن مطوّري البرامج أهميّة اتّباع أفضل الممارسات الأمنية؛ إلا أننا نتسرّع غالبا في تنفيذها، ربما بسبب ما تستدعيه من العمل الجادّ حتى ترسخ في الأذهان. يحدُث أحيانا أن ترى ممارسة أمنية شديدة الخطورة لدرجة أنها تبقى محفورة في ذهنك. أمرّ في عملي مدير أنظمة على الكثير من الممارسات الأمنية الخاطئة، إلا أن الثلاثة التي سأتحدّث عنها في هذا المقال هي أساسيّات يجب على كلّ مطوّر برامج تفاديها. أنبّه هنا إلى أنني أرى كل واحدة من الممارسات المذكورة لدى شركات كبيرة ومطوّرين ذوي خبرة طويلة، لذا فليس صحيحا لصقُها بالمطوّرين المبتدئين. لا تستخدم التعمية لكلمات السّر .. بل التجزئة Hash عملتُ في وقت سابق من مسيرتي المهنية مع شركة تستخدم نظام إدارة يخزّن بيانات شديدة الأهميّة، وفي أحد الأيام طُلِب مني إجراء مراجعة أمنية للشبكة والبرنامج الذين تعتمد عليهما بياناتنا الحرجة. قضيتُ بضع دقائق في البحث ثم قرّرت تشغيل Wireshark لرؤية حركة البيانات عبر الشبكة. استخدمتُ حاسوب العمل للدخول إلى نظام المعلومات ولاحظتُ أمرا غريبا. رغم أن هذه الحادثة كانت قبل انتشار SSL إلا أنني لم أكن أتوقّع أن أرى نصوصا واضحة تحوي حقولا مثل username (اسم المستخدِم) وpassword (كلمة السرّ). بدا بعد التدقيق أن النظام كان يُرسِل اسم المستخدم الخاصّ بي وسلسلة محارف عشوائية - لم تكن كلمتي للسرّ - عبر الشبكة. لم أستطع ترك الأمر على تلك الحال، فحاولتُ تسجيل الدخول مجدّدا إلا أنني هذه المرة أدخلتُ - عن قصد - كلمة سرّ خاطئة. لم أغيّر كلمة السّر كليّةً، بل اكتفيتُ بتغيير محرف واحد فقط. كنتُ أتوقّع رؤية سلسلة محارف جديدة مختلفة تمامًا تمثّل كلمتي للسّر تمرّ عبر الشبكة. بدلا من ذلك، لم يتغيّر سوى أول محرفيْن من سلسلة المحارف. كان الأمر مثيرًا للانتباه، فرغم أن خبرتي كانت متواضعة نوعا ما، إلا أنني كنتُ أعرف أنه إن طُبِّقت دالة تجزئة Hash بطريقة صحيحة على كلمتي للسرّ فستكون سلسلة المحارف مختلفة تماما، وليس فقط أول محرفين. ياللهوْل.. حتى مخطّط تعميّة (تشفير) جيّد كان سيُنتج سلسلتيْ محارف مختلفتين تماما، وهو ما يبدو أن مخطّط التعمية المستخدَم لا يقوم به. جرّبتُ كلمتي سرّ أخرييْن. تسلّحتُ بأوراق وقلم رصاص وقضيتُ الساعتيْن المواليتيْن في محاولة العثور على مخطّط فكّ التعمية. كان لديّ بانتهاء هاتيْن الساعتيْن سكريبت بايثون يمكنه أخذ أي واحدة كلمات السّر “المعمّاة” تلك ثوم فكّ تعميّتها وكشف كلمة السّر الأصلية؛ أمر يُفترَض أن لا أحد بإمكانه فعله. أنا متأكّد من أنه لم يدُر بخلد الشخص الذي وضع ذلك المخطَّط أن أحدا سيجلس ساعتيْن ويعمل على تفكيك مخطّطه؛ إلا أني فعلتُ ذلك. لماذا؟ لأنه كان بإمكاني ذلك. لا تعمّي كلمات السّر إن اضطررت لتخزينها من أجل المقارنة، فهناك دائما إمكانية أن يستطيع أحدهم إيجاد خوارزميّة أو مفتاح لفك التعميّة. لا يوجد عكس مباشر للتجزئة، بمعنى أنه لا يمكن لأحد الحصول على الأصل إلا إذا كان لديه جدول يربط بين النص الواضح وتجزئته (أو أنه خمّنه). معرفة آلية التجزئة وطريقة عملها لا تضرّ بسلامة البيانات، في حين يحدُث ذلك عند معرفة مخطّط التعمية ومفتاحها. 2. لا تترك منافذ خلفية Backdoors سريّة في البرامج كنتُ في وظيفة سابقة لدى إحدى شركات الخدمات البرمجية أقدّم الدعم لمستخدمين أخبروني أن أسماء المستخدمين التي بحوزتهم لم تعد تعمل. كان الدعم جزءًا من خدمة مدفوعة تقدّمها الشركة المطوّرة للبرنامج المستخدَم. خطر ببالي، قبل محاولة معرفة المشكل الكامن وراء إحدى أكثر مكالمات الدعم الفني إضجارا (“بيانات الدخول الخاصة بي لا تعمل”)، أن أجرّب تسجيل الدخول بنفسي. بالفعل لم تكن أسماء الدخول تعمل. كان النظام منصةً تعليمية مبنية على تقنيات الوِب، وكنا قد دفعنا مقابل وظائف محدودة من قدراتها الكثيرة. لفت أمر نظري بينما كنتُ أبحث في صفحة تسجيل الدخول. بدا حرف في إحدى المحارف ذا شكل مختلف قليلا عن البقية. ربما كان السببُ استخدام خط مختلف عن بقية الصفحة. عرضتُ مصدر الصفحة ولاحظتُ وجود رابط على هذا الحرف بالضبط. كان الرابط مخفيًّا عن قصد ولم تكن حالة المؤشّر تتغيّر عندما يحوم على الرابط. فتحتُ - بحذر شديد - الرابط في نافذة متصفّح جديدة. فجأةً بدت أمامي شاشة تفصّل معلومات عن مجموعة كاملة من الحواسيب، وتعطيني التحكّم الكامل في ما يمكن لهذه الحواسيب أن تعمله. كان بمقدوري إطفاء هذه الحواسيب، إعادة تشغيلها، أخذ لقطات من الشاشة.. أي شيء. هاتفتُ الشركة المطوّرة للبرنامج وطلبتُ الحديث مع مسؤول التقنية لديهم. تحدّثتُ في الأخير بعد المرور على أشخاص عدّة مع مَن يبدو أنهم يفهم ما أتحدّث عنه. أجاب “آه.. فعلا”، وأكمل “أضفنا ذلك الرابط ليسهل علينا الوصول. ولا أحد - قبلك - أبدا عثر عليه. سنحذفه فورا”. سألني قبل أن ننهي المكالمة سؤالا أخيرا: “لماذا بدأت في النظر إلى شفرات HTML في صفحة الدخول؟” كانت إجابتي بسيطة: “لأنني أستطيع ذلك”. لا يستحق وضعُ منفذ خلفي في نظام ما أي درجة من المخاطرة.. سيعثُر عليه شخص ما في نهاية المطاف. مهما كانت درجة الغموض فإن تحليل الشفرات البرمجية - كذلك البحث والحافز عموما - يحمل في طيّاته أكثر النتائج غرابة وفجائية. 3. استوثق من المستخدمين على جميع الصفحات.. وليس فقط صفحة الدخول كنتُ في مرحلة سابقة من مسيرتي المهنية جزءًا من مشروع تطوير برمجي كان يتولّى تنفيذه مطوّر متمرّس. كنتُ أحسّ بعدم الارتياح مع هذا التطبيق خصوصا، فأخبرتُ مديري بأننا نحتاج لإجراء مراجعة أمنية معمَّقة للشفرة البرمجية. طُلِب مني أن أنظُر في التطبيق بحثا عمّا يمكنني العثور عليه. بدأتُ بالتجوّل في التطبيق، تسجيل الدخول، وعرض بعض البيانات. ثم لاحظتُ أمرا بدا لي مثيرا للاهتمام. إن علمتُ Bookmarked رابطا بعد تسجيل الدخول والتجول في النظام فإن بإمكاني نسخه ثم لصقه في متصفّح آخر وسأحصُل على نفس الصفحة المُعلَّمة، دون الحاجة لتسجيل الدخول. سألتُ المطوّر “لماذا لا تتحقّق في كل صفحة من أن المستخدم مسجَّل الدخول؟ إذ يكفي أن أحصُل على رابط بعد تسجيل الدخول ونسخه ويمكنني الوصول إلى هذه الصفحة متى أردت دون الحاجة لتسجيل الدخول”، فسألني “لماذا تفعل ذلك؟”. أجبتُه: “لأنه يمكنني ذلك”. لا تترك أي شيء للصدفة حتى المطوّرون المتمرّسون يقعون في هذه الأخطاء؛ فهم يظنّون ألا أحد سيتعمّق في نظام لا يحقّ له الوصول إليه. المشكلة أن المستخدمين سيتسكّعون في النظام وسيعثرون على هذه الثغرات في النهاية. النصيحة الأهم التي يمكن لشخص مثلي، مجرّد هاو لمجال الحماية، أن يقدّمها هي:لا تترك أي شيء للصدفة. يوجد أشخاص - مثلي - يحبون التعمق في الأشياء لمعرفة كيف تعمل ولماذا. ولكن يوجد آخرون ربما أكثر خبرة ومعرفة سيتعمّقون في الأنظمة بحثا عن اكتشاف الثغرات ولاستغلالها. لماذا؟ لأن باستطاعتهم فعل ذلك. ترجمة - بتصرّف - للمقال 3 security tips for software developers لصاحبه Pete Savage. حقوق الصورة البارزة محفوظة لـ Freepik

تستغل هجمات حقن 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.

طُوّرت على مدار تاريخ الإنترنت العديد من الأدوات والطرق للتأكد من حماية المواقع من الاختراق، أو على الأقل جعله مستعدًا لمجابهة ذلك الخطر. أيًا كان مشروعك، متجرًا إلكتروني، أو مدونة عصرية أو حتى موقعًا لإحدى الشركات، تجب مراعاة تدابير الحماية في كل الأوقات. إذا كنت مطور/مصمم ويب، فمهمتك لم تعد تقتصر على بناء صفحات ويب جميلة، بل عليك المحافظة عليها محمية من جميع الجهات التي قد ترغب باختراقك واستغلال موقعك. ستحتاج لإجراء تدابير أمنية لمنع حصول شيء كذلك. هنالك العديد من الطرق لاختراق المواقع، لذلك يجب وضع تدابير حماية متعددة لقطع جميع تلك الطرق. لكن لا وجود لطريقة محددة قادرة على حمايتك بالكامل من المخترقين، أفضل ما يمكنك فعله هو تصعيب المهمة على المخترقين على نحو كافِ لدرجة تجعلهم ييأسون من المحاولة. طرق الاختراق الشائعة كما أسلفنا، هناك العديد من الطرق يستعملها المخترقون لتخطي حماية الموقع بهدف تدميره أو التلاعب به. سنذكر هذه الطرق حتى يمكنك إجراء تدابير وقائية للتصدي لهذه المحاولات. حقن استعلامات SQL لا يمكن إنكار أن حقن استعلامات SQL‏ (SQL Injection) هي إحدى أكثر طرق الاختراق خطرًا على كل من المواقع والأنظمة. على نحو عام، تتضمن هذه الطريقة إدخال استعلامات SQL في حقول الإدخال مثل حقول تسجيل الدخول أو حتى شريط العناوين الخاص بالمتصفح. بفعل ذلك يتمكن المخترق من الوصول لقواعد البيانات الخاصة بالموقع أو النظام. عندما تدخل اسم المستخدم وكلمة السر في حقل تسجيل الدخوليُدرَج النص الذي أدخلته إلى استعلام SQL. ذلك الاستعلام سيفحص البيانات التي أدخلتها ويوازنها بقاعدة بيانات الموقع أو النظام. بمجرد تطابق القيم المدخلة مع المسجلة ستحصل على تصريح دخولك، إذا لم تتطابق فلا يسعك الدخول. حقن قواعد البيانات يحدث عندما يحاول المخترق إدراج استعلامات SQL في حقول الإدخال الخاصة بموقعك. في العادة سيفحص الموقع البيانات المدرجة ويتأكد من صلاحيتها. إذا حدث واحتوت بياناتك مجرد علامة اقتباس (‘) بنهاية بيانات اسم المستخدم قد تفسرها قاعدة البيانات كاستعلام SQL بنَّاء، وهكذا سيُعدُّ استعلامًا صحيحا. قد لا يدخل المخترقون إلى موقعك عن طريق ذلك الاستعلام بالتحديد، لكن هذه الطريقة ستسمح لهم بالوصول إلى اسم قاعدة بياناتك، والجداول وحقول المفاتيح. وبامتلاك هذه البيانات سيحتاجون فقط إلى إدخال استعلام SQL في أحد حقول موقعك، عندها سيتمكنون من رؤية كامل محتويات قاعدة بياناتك. كيف يمكن التصدي لحقن SQL التأكد من إدخال نوع البيانات الصحيح الاستعلام باستخدام الوسائط (Parameters) تحديد الصلاحيات ترشيح IIS موحَّد تفعيل توثيق طلبات الاستعلام فكر باستخدام إطار لربط العلاقات بالكائنات (ORM) هجمات XSS الهجمات بالسكربتات العابرة للمواقع Cross Site Scripting، التي تُعرف اختصارًا بهجمات XSS، هي إحدى أكثر طرق الاختراق التى يصعب التصدي لها. في الأعوام السابقة، واجه كلٌّ من Microsoft، و MySpace، و Google صعوبات كبيرة في التعامل مع تلك الهجمات. تعتمد هجمات XSS على إرفاق سكربتات خبيثة مكتوبة بلغة جافا سكربت بالروابط الداخلية بهدف التحكم بسجلات الجلسات (Sessions) الخاصة بالموقع، أو اختطاف الإعلانات أو سرقة المعلومات الشخصية. لابد أنك تذكر حدوث هذا: قمت بالضغط خطأً على إعلان غريب الشكل، فأرسلك إلى صفحة شبيهة بتطبيقات الدردشة. ثم ترى رسالة من فتاة لطيفة تطلب منك الضغط على رابط ما للدردشة معها. وعند الضغط على الرابط يظهر لك عنوان URL غريب الشكل مثل العنوان التالي: [%63%61%74%69%6f%6e%3d%274%74%70%3a%2f%2f%77%7…] قد تعتقد أن لا شئ قد حدث ولكن لا، أنت مخطئ بالتأكيد. هذه الروابط تساعد على سرقة ملفات تعريف الارتباط (Cookies) والتي بدورها تعين المخترق على سرقة معلوماتك الشخصية. كيف يمكنك التعامل مع برمجيات تخطي المواقع لا تسمح بإدخال بيانات غير موثوقة إلا إذا تطلب الأمر ذلك خلّص (Escape) وسوم HTML عند معالجة البيانات المدخلة للحقول خلّص خصائص العناصر قبل إدراج البيانات على الموقع خلّص نصوص JavaScript من الحقول حتى تتفادى تسلل بيانات غير موثوقة إلى قيم جافاسكريبت. تخطي الاستيثاق كما يوحي الاسم، تخطي الاستيثاق مخيف. يستهدف عادةً التطبيقات أو أنظمة إدارة المحتوى سيّئة التصميم، ويمكن له إحداث فوضى عارمة بموقعك. يحدث الاختراق على نحو مشابه للتالي: البحث وإيجاد صفحة تسجيل دخول ضعيفة الحماية. فتح الشفرات المصدرية للصفحة. نسخ الشفرات إلى محرر نصِّي. حذف تعليمات JavaScript الخاصة بإدارة التصاريح وتعديل رابط أو اثنين. حفظ التغييرات على النص البرمجي. فتح الملف البرمجي الجديد على متصفحك، سجل الدخول كما لو أنك تمتلك الموقع. وهكذا نجح الاختراق! هل موقعك عُرضة لهذا الاختراق؟ هذا يعتمد على إجابة الأسئلة التالية: هل يقوم خادم موقعك بتشغيل العمليات مستعملًا صلاحيات الجذر، أو مدير النظام، أو النظام المحلي أو حسابات إدارية أخرى؟ هل يُمنح موقعك/تطبيقك صلاحيات الوصول لقاعدة البيانات عبر حساب SA (بالنسبة لأوراكل) أو حسابات أخرى مشابهة؟ هل يمتلك تطبيقك القدرة على الوصول لقاعدة البيانات عبر حسابات تمتلك صلاحيات أعلى من المطلوب؟ هل تعمل الحوسبة الافتراضية بخادم موقعك باستعمال كل الصلاحيات أو بثقة كاملة ببيئات عمل J2EE و NET.؟ هل بالإمكان تحديد إمكانية الوصول لموارد موقعك باستعمال قدرات المنصة المستعملة؟ إذا أجبت بنعم ولو على سؤال واحد فموقعك معرَّض للخطر. كيف يمكنك حماية موقعك تطوير الموقع، واختبارات الأداء ومنهجية التطوير يجدر القيام بها باستعمال أقل صلاحيات ممكنة. تأكد من أن الحسابات التى تدير بيئة العمل محدودة الإمكانات بأقصى قدر ممكن. لا يجوز أن يستخدم خادم موقعك صلاحيات مدير النظام، أو صلاحيات الجذر، أو غيرها من الحسابات الحسّاسة. حدّدد صلاحيات حسابات المستخدمين بموقعك على نحو يتناسب مع حاجتهم. لا يجوز أن تحظى حسابات الشركاء بصلاحيات إدارية والعكس صحيح. عليك استخدام حسابات مختلفة لمهام مختلفة. التدابير الشائعة لمنع الاختراق حافظ على الملحقات والبرامج محدَّثة باستمرار لا شيء يسعد المخترق أكثر من برمجية/ملحق منتهي الصلاحية. عادةً هذه هي أهدافهم المفضلة لاحتوائها على أعطال، أو خلل أو ثغرة أمنية. هذا هو السبب الرئيسي لتحديثها أساسا. لنقلها بهذه الطريقة، أنت تستخدم نوعًا ما من أقفال الأبواب تم التحايل عليه ألاف المرات. هل تتوقع أن يواجه اللص التالي مشكلة في التعامل معها؟ لذا استمع لهذه النصيحة، حدّث الآن! استخدم كلمات مرور قوية كم مرة تمت التوصية بهذا؟ من المهم للغاية استعمال كلمات مرور قوية. ربما لا تدرك أن المخترقين يحاولون سرقة كلمات مرورك باستمرار. إذن، كيف ننشىء كلمة مرورفعّالة؟ طريقة التبديل هذه طريقة جيدة للحفاظ على كلمات مرورك آمنة. حسب المبدأ، عليك استبدال الأحرف والأرقام بأحرف خاصة باستخدام طريقتك الشخصية. مثلاً: استعمل رمز '@' عوضًا عن حرف 'a' استعمل رمز '$' عوضًا عن حرف 's' استعمل رمز '%' عوضًا عن المسافات استعمل الرقم '0' عوضًا عن حرف 'o' استعمل رمز '!' عوضًا عن حرف 'i' بهذه الطريقة قمنا بتحويل كلمة سر بسيطة مثل ‘whoisjohngalt’ إلى كلمة أكثر تعقيدًا ‘wh0!$j0hng@lt’. طريقة Business Insider ابتكرت مجلة Business Insider مؤخرًا طريقة لتشكيل كلمة مرور قوية يسهل تذكرها. طبقًا للمجلة عليك إنشاء كلمة مرور طويلة لأنها تجعل الحواسيب تستغرق وقتًا طويلًا لتكتشفها. المبدأ الرئيسي لهذه الطريقة هو إنشاء كلمات مرور طويلة جدًا باستخدام كلمات غير ذات علاقة بك أو ببعضها. استخدم أداة Google Webmaster لدى Google طريقة لمساعدتك في تأمين موقعك. باستعمال أدوات Webmaster ستحظى بتنبيهات في حال العثور على برمجيات خبيثة. في حال اختراقك وعدم قدرتك على إزالة الاختراق، ستساعدك غوغل عن طريق إضافة موقعك للقائمة السوداء مما يمنحك متسعًا من الوقت للتعامل مع البرمجيات الخبيثة بموقعك، أيضًا هذه الخدمة تتيح لك رؤية تفاصيل المشكلة المرصودة. لا تعرض رقم إصدار WordPress بجانب تحديثك لمنصة التدوين، عليك دائمًا منع المخترقين من معرفة أي من إصدارات WordPress تستعمله. فعل ذلك سيمنعهم من استغلال ثغرات الحماية في موقعك. يمكنك فعل ذلك بتعديل ملف functions.php الخاص بموقعك وإضافة التعليمات التالية: function remove_version() { return ''; } add_filter('the_generator', 'remove_version'); تشديد الحماية على ملف htaccess. عادةً، حماية ملف htaccess متساهلة افتراضيًّا، لكن يمكنك تخصيصها لحمايتك من الاختراق عبر التلاعب بعناوين URL، أو حقن قواعد البيانات أوغيرها. هنالك الكثير من الطرق لتعديل ملف htaccess. لكننا سنشير إلى أكثرها جدوى. تذكّردائمًا أخذ نسخ حتياطية من الملف. order allow,deny deny from all أضف الاستعلامات التالية لمنحك مزيدًا من الأمان، علمًا أنه لن يُسمَح بالوصول غير المرغوب فيه، وستمنع زواحف محركات البحث من الوصول إلى ملف wp-admin.php. يمكن تطبيق تعليمات مماثلة على ملفات أخرى مثل install.php و eror_log. RewriteEngine On RewriteBase / RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC]RewriteRule ^(.*)$ - [F,L]RewriteCond %{QUERY_STRING} \.\.\/ [NC,OR]RewriteCond %{QUERY_STRING} boot\.ini [NC,OR]RewriteCond %{QUERY_STRING} tag\= [NC,OR]RewriteCond %{QUERY_STRING} ftp\: [NC,OR]RewriteCond %{QUERY_STRING} http\: [NC,OR]RewriteCond %{QUERY_STRING} https\: [NC,OR]RewriteCond %{QUERY_STRING} (\|%3E) [NC,OR]RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|%3D) [NC,OR]RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)||ê|"|;|\?|\*|=$).* [NC,OR]RewriteCond %{QUERY_STRING} ^.*("|'|<|>|\|{||).* [NC,OR]RewriteCond %{QUERY_STRING} ^.*(%24&x).* [NC,OR]RewriteCond %{QUERY_STRING} ^.*(%0|%A|%B|%C|%D|%E|%F|127\.0).* [NC,OR]RewriteCond %{QUERY_STRING} ^.*(globals|encode|localhost|loopback).* [NC,OR]RewriteCond %{QUERY_STRING} ^.*(request|select|insert|union|declare).* [NC]RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in_.*$ RewriteRule ^(.*)$ - [F,L] الخاتمة التعرض للاختراق بالتأكيد محبط. أنت ترى ثمرة جهودك تنهار مثل برج رملي. لكن درهم وقاية سيكون دائمًا أفضل من دينار علاج، لذا بينما كل شيء على ما يرام قم بتحسين وإصلاح كل ما يمكن إصلاحه تحسبًا لوقوع الكوارث. ترجمة -وبتصرف- للمقال Security Advice for Preventing Your Website from Being Hacked من إعداد فريق موقع 1stwebdesigner

نشعر بالأمان أكثر كلما اكتشفنا طرقًا جديدةً لزيادة أمن مواقع ووردبريس، وهذا الأمر جيّد وسيّء في نفس الوقت، فهو جيّد لأنه يعني أننا نثق بالأدوات والخدمات التي استثمرنا فيها لتأمين ووردبريس، وهي سيئة لأننا نخلط بين زيادة أمن المواقع وعقليّة "ضعها وانسها". بصراحة: يحاول القراصنة اختراق موقعك، فإذا كنت تعتقد أن موقعك صغير أو جديد ليكسب انتباه القراصنة، ففكّر من جديد، إذ يوجد 90978 هجوم أمني يحدث كل دقيقة من كل يوم، ولا يفكر القراصنة في حجم الموقع أو العمل عندما يهاجمونه. يعلم القراصنة أن لووردبريس نقاط ضعف كثيرة، لذلك إذا أردت زيادة أمن موقعك فيجب عليك التفكير كمخترق، حدد نقاط الضعف في موقعك وفكر في الطرق المختلفة التي يمكنك من خلالها استغلال هذه النقاط، وعندها فقط ستكون قادر على درء الهجمات. أين تقع أضعف البقع في موقع ووردبريس؟ ربما من الأشياء الأكثر رعبًا أن القراصنة لا يبحثون بشكل خاص على موقعك (خاصة إذا كان جديد أو صغير)، فالعديد من القراصنة يبحثون عن نقاط الضعف باستخدام bots، فالأخيرة تكشف عن المداخل للقراصنة، لذلك فإن أي موقع ووردبريس يمكن أن يكون الضحيّة. لذا من المهم التعرّف على أشهر نقاط الضعف في ووردبريس لإبقاء القراصنة بعيدين عن موقعك. كلمات المرور أي بقعة في الواجهة الخلفية (backend) أو الأماميّة (frontend) من موقعك التي تطلب اسم مستخدم وكلمة مرور هي من الأماكن الرئيسية التي يستهدفها القراصنة، ومنها منطقة تسجيل الدخول الرئيسية لووردبريس: لوحات التعليقات: حسابات التجارة الإلكترونية أو بوابات الدفع: يعرف القراصنة أن المستخدمين لا يهتمون دائمًا بإنشاء كلمات مرور قويّة لكل حساب يملكونه على الإنترنت (يتعارض هذا مع أساسيات أمن كلمة المرور 101). وسيكون هذا أحد الأهداف الأولى على موقع ووردبريس الخاص بك. التعليقات ليست التعليقات مشكلة أمنية بسبب عنصر تسجيل الدخول (إذا كان هنالك واحد)، فيمكن للتعليقات أن تكون مشكلة بسبب الرسائل غير المرغوب فيها، ولهذا فإن بعض الناس يختارون تعطيل التعليقات بالكامل في ووردبريس. وإليك مثال لتعليقات من عملاء سيئين. قد لا يؤدي هذا الرابط إلى شيء ضار، لكنه بالتأكيد لا ينتمي إلى هذه المجموعة من التعليقات. نماذج الاتصال نماذج الاتصال، أو نماذج الاشتراك، أو نماذج الدفع أو أي جزء من الموقع يطلب من المستخدمين إدخال تفاصيل هو مكان واضح يستهدفه القراصنة. بالطبع، يمكنك اختراق الموقع ومن ثم الاستيلاء على البيانات الحساسة التي أُدخلت إلى هذه الحقول، وهنالك طريقة يمكن للقراصنة من خلالها سرقة البيانات من خلال مراقبة نقرات المستخدمين إما عن طريق لوحات المفاتيح اللاسلكية أو عن طريق استخدام البرامج الضارة التي تُثبّت على أجهزة الحاسوب الخاصة بهم. قاعدة بيانات ووردبريس في حين أنه من الرائع أن ووردبريس قد بسّط تسمية الملفات وهياكل قاعدة البيانات في جميع المواقع، لكنه أحدث أيضًا مشكلة كبيرة إذ أن كل شخص منا (بما في ذلك المخترقين) يعرفون أن البادئة “wp-‎” تُستخدم لتسمية كل شيء تقريبًا، وهذا سيترك قاعدة بيانات ووردبريس مكشوفة بشكل كامل وعرضة للهجوم إذا لم يتغير ذلك. نواة ووردبريس هل تعلم أن 73% من نسخ ووردبريس القديمة تحتوي على نقاط ضعف داخلها؟ على الرغم من أنه ليس من مسؤوليتكم إدارة نواة ووردبريس (WordPress core)، فمن المؤكد أن من مسؤوليتكم أن تثبتوا أي تحديث جديد لووردبريس، فيجتهد الفريق الأمني لووردبريس دائما لجعل النواة محدّثة، ومن المهم أن يفعل مطورو ووردبريس الأمر نفسه حتى لا تبقى نقاط الضعف هذه في مواقعهم. إضافات ووردبريس إن الإضافات أكثر عرضة للانتهاكات الأمنية من نواة ووردبريس، في الحقيقة، تتحمل إضافات ووردبريس 50% من الهجمات الأمنية على مواقع ووردبريس. بالطبع، لا ينبغي لهذا أن يجعلك تخاف من استخدام إضافات ووردبريس، فهي جزء أساسي من العمل الذي تقوم به لإنشاء مواقع تفاعليّة وجذابة لجمهورنا، ومع ذلك، فهذا يعني أنك بحاجة إلى إيلاء اهتمام أكبر لما يحدث مع مجموعة الإضافات الحالية كما يجب أن تبقي عينيك وأذنّيك مفتوحة عند مراجعة إضافات جديدة لموقعك. هنالك بشكل عام طريقتان يمكن من خلالها أن تضعف الإضافات أمن موقعك: عند تحديثها من قبل المطور، لكنك لا تحدّثها في موقعك (أو عدم فعل ذلك في الوقت المناسب). عند إضافة إضافة ووردبريس مزيّفة إلى موقعك دون قصد. لذلك، تأكد من اهتمامك بهذه النقاط. قوالب ووردبريس الشيء نفسه ينطبق على قوالب ووردبريس، على الرغم من أنه لا داعي للقلق حول استخدام قالب مزيّف، فهي مجرد مسألة إصدار التحديثات من المطور في الوقت المناسب. خدمة استضافة المواقع للأسف، ليست كل شركات استضافة المواقع متشابهة وهذا يمكن أن يؤثر غالبًا على مستوى أمن الخادم، وبطبيعة الحال، يجب عليك التأكد من هذه النقاط عند اختيار خطة استضافة مواقع: التشفير وجدار حماية جانب الخادم. نوع خادم الويب NGINX أو Apache. برامج مضادات الفايروسات والبرامج الضارة. أنظمة الأمن في الموقع. توفر شهادات SSL و CDN. يوجد أيضا خطر الإصابة عن طريق عدة مواقع عند وجود عدة نطاقات تتشارك في نفس المساحة على الخادم، فإذا كانت هذه هي حالتك، فقد تحتاج إلى اتخاذ احتياطات أمنية إضافيّة على مستوى الخادم. ماذا يريد المخترقين من موقعك؟ إذا فكرت في "موقعي صغير/جديد/محلي، فماذا يريد المخترقون منه؟” فلقد حان الوقت لتغيّر رأيك، فالقراصنة لا يريدون فقط تدمير الشركات الكبيرة، انهم ببساطة يبحثون عن أي ضعف يمكن استغلاله. لذا، في المرة القادمة التي تفكر فيها بـ "ليس لديّ أي شيء يُريدونه”، فكّر في الفرص التالية التي قد يستفيدون منها: 1- حقن محتوى خبيث في بعض الحالات، يريد القراصنة ببساطة إضافة محتوى خبيث أو شيفرات برمجية على الواجهة الأماميّة من موقع ووردبريس مع أمل أن يضغط زوارك على الروابط الخاطئة، ويمكن أن يحدث هذا عن طريق التعليقات غير المرغوب فيها، أو عن طريق اختراق البريد الإلكتروني لموقعك وإرسال رسائل غير مرغوب فيها لمتابعينك، أو من خلال إرسالات (submissions) المحتوى الحالي. كمثال على الأخيرة، الق نظرة على نقطة ضعف إضافة NextGEN Gallery، فعن طريقها، استطاع المخترقين تعديل شيفرة PHP الخاصة بالموقع ومن ثم مهاجمة الموقع عن طريق هذه الإضافة. 2- نشر الفايروسات من الطرق الأخرى التي يستخدمها المخترقين لإرهاب زوارك هي عن طريق استخدام موقع ووردبريس الخاص بك لنشر الفايروسات والبرامج الضارة، ويمكنهم إجراء ذلك باستخدام شيفرة برمجية ضارة كتبوها في الواجهة الخلفية أو مع الملفات المرفوعة للتحميل في الواجهة الأماميّة وعندما يتفاعل الزوار معهم، يسرق المخترقون معلومات الزائرين أو يستخدمون حواسيبهم لنشر الفايروسات على مواقع ويب أخرى. إن إضافة BlogVault backup هي مثال جيّد على هذا، فمن خلال هذا الهجوم، استطاع المخترقون على إصابة مواقع ووردبريس التي تستعمل هذه الإضافة ببرامج خبيثة. 3- سرقة المعلومات الشخصية للزائر هذه أهم واحد يقلق حولها الزوار ويجب أن تأمل أن لا تحدث على الإطلاق لأنها مكلفة للغاية، فأي خرق أمني سيُسيء للعمل التجاري، لكن في هذه الحالة، يجب عليك تعويض زوارك وعملاءك للمال والخصوصية التي تعرضت للخطر في الهجوم، ناهيك عن فقدان الثقة في علامتك التجاريّة. يمكن للمخترقين الحصول على هذه المعلومات بطرق مختلفة ويمكنهم الاستفادة منها كثيرًا، في بعض الأحيان لمكاسب ماليّة، لكن في أحيان أخرى مثل اختراق Ashley Madison حيث أنهم يحاولون تقديم بيان. 4- سرقة بيانات أعمال خاصة تعمل الشركات بجد للحفاظ على تفاصيل تتعلق بالشركة (وخاصةً فيما يتعلق بالأمور الماليّة وتفاصيل حساب العميل) تحت الأغطيّة، ولهذا السبب، من المهم للغاية عدم وصول هذه المعلومات إلى موقع أعمال المنافس. نقطة ضعف Heartbleed هي مثال حديث لهذا النوع من الهجوم وهو بسبب مشكلة في OpenSSL وهو شيء مصنوع لزيادة حماية المواقع، وبدلا من ذلك، ما فعله OpenSSL هو إرسال بيانات عمل حساسة إلى المخترقين عند إرسالهم طلبات وهمية إلى خوادم المواقع المصابة. 5- استضافة صفحات التصيد في خادمك يشير التصيّد في المواقع بشكل أساسي إلى إنشاء القراصنة لصفحة مزيفة على موقع ووردبريس لمحاولة جمع المعلومات من الزائرين الذين يرغبون في إعطائها. ويمكنهم القيام بذلك عن طريق تضمين نموذج اتصال في الصفحة وجمع البيانات بشكل مباشرة أو يمكنهم إعادة توجيه الزائرين إلى موقع آخر حيث ستُرفع هذه المعلومات. يقوم جوجل بإدراج 50000 موقع كل أسبوع في القائمة السوداء بسبب عمليات التصيّد. 6- استضافة صفحات شرعية في خادمك بعض القراصنة يبنون صفحات شرعيّة في مواقع ووردبريس من أجل تحسين SEO (تحسين محركات البحث) الخاص بهم، وتتحدث هذه الصفحات عن شركتهم الخاصة وروابط لهم من أجل تحسين من قوّة موقعهم في محركات البحث، أو قد يختارون تخطي الصفحة المقصودة ويستخدمون نهج أكثر دقة لتعزيز SEO الخاص بهم، في هذه الحالة، سيستخدمون نظام الروابط الخلفية (backlinks) من موقعك لمواقعهم. 7- حمل زائد على خادمك عندما قيام القراصنة بتحميل زائد على خادمك عن طريق أعداد كبيرة من الزيارات، وهذا ما يعرف بهجوم الحرمان من الخدمات (DdoS)، فسيتوقف موقعك عن العمل عندما يصلون إلى ذلك، وسيفوزون، ولماذا يفعلون ذلك؟ ما الذي يمكنهم الحصول عليه من إيقاف موقعك؟ حسنًا، ربما يحصلون على لذة الانتصار، أو بسبب ثأر شخصي ضد العلامة التجارية، أو ربما موقعك هو واحد من عدة ضحايا في هجوم واسع النطاق، أو ربما فعلوا ذلك من أجل المطالبة بفديّة. 8- سرقة عرض نطاق (Bandwidth) الموقع تحدثتُ سابقا كيف يمكن سرقة الصور من موقع ووردبريس الخاص بك بعلمك أو بدون علمك، وواحدة من هذه الطرق هي عن طريق الربط الساخن (hotlinking)، والذي يحول موقعك إلى استضافة لحركة مرور بيانات (traffic) المواقع الأخرى عن طريق روابط الصور. ومع ذلك، هنالك طرق أخرى يمكن من خلالها للقراصنة سرقة موارد خادمك لاستضافة أنشطتهم السيئة مثل تعدين البيتكوين وهجمات الحرمات من الخدمة وهذا بالضبط ما حدث في قضيّة اختراق Monero mining حيث أصبحت المواقع التي اخترقت "عبيدًا”، تُستخدم في أنشطة التعدين للقراصنة. 9- تخريب موقعك وبطبيعة الحال، هنالك تخريب المواقع، ففي أغلب الأحيان، يفعل المخترقون هذا لإنشاء هويّة لأنفسهم بينما يضرون في الوقت نفسه علامتك التجاريّة، ولقد حدثت هذه التشويهات في مجموعة كبيرة من مواقع ووردبريس، واستمرت في حدوث حتى بعد تحديث ووردبريس لأن المستخدمين فشلوا في التحديث في الوقت المناسب. الخاتمة لإنهاء هذا بملاحظات إيجابيّة، لنحاول التركيز على ما نعرفه: لا، فوردبريس ليس "غير قابل للقهر”. ولكن نعم، لدينا الوسائل لوضع دفاع جيّد ضد المتسللين إذا كنا نعرف إلى أين ننظر. كتذكير، هذا ما يمكنك القيام به: عمل نسخة احتياطية من موقعك بانتظام. تأمين موقعك على كافة المستويات: الخادم، والنواة، والإضافات، والقوالب، وحتى جهاز حاسوبك والشبكة. استخدام إضافة أمنيّة. استخدام CDN. استخدام شهادة SSL. تأمين كلمات السر الخاصة بك. لا تنسَ فحص نقاط الضعف في موقعك بانتظام للتأكد من أن موقعك خالٍ منها. ترجمة -وبتصرّف- للمقال Do You Know Why Hackers Are Targeting Your WordPress Site?‎ لصاحبه Brenda Barron

سنتعرف في هذا المقال من سلسلة المقالات حول التعامل مع ويندوز 10 على جدار الحماية Firewall الخاص بويندوز 10 ، حيث سنتعلّم التعامل معه بشكل أساسيّ، ثم نبحر في بعض التفاصيل حول كيفيّة ضبطه، ومن ثمّ التحكّم بوصول التطبيقات المثبتة على ويندوز 10 إلى الانترنت. ما هو جدار الحماية؟ جدار الحماية Firewall ببساطة عبارة عن برمجيّة تعمل على إدارة حركة الاتصالات الشبكيّة الصادرة من، والواردة إلى الحاسوب. حيث تسمح بمرور أو منع هذه الاتصالات بالاستناد إلى قواعد محدّدة معرّفة سابقًا. كما قد يكون الجدار الناري عبارة عن جهاز مستقل بذاته يشكل همزة وصل بين الشبكة الداخلية لإحدى الشركات وبين شبكة الانترنت. يحتوي ويندوز 10 كما هو الحال مع الإصدارات السابقة، على برمجيّة جدار حماية مضمّنة فيه يمكن الوصول إليها وإعدادها. توجد في الواقع العديد من البرمجيّات الأخرى التي من الممكن أن تلعب مثل هذا الدور. وخاصّة برمجيّات مكافحة الفيروسات التي تتضمّن في الكثير من الأحيان برمجيّة جدار الحماية. سنتحدّث في هذا المقال عن برمجيّة جدار الحماية الخاص بويندوز 10. إعداد جدار الحماية الخاص بويندوز 10 انقر زر ابدأ، ثم انتقل إلى لوحة التحكم. ستظهر لك نافذة شبيهة بما يلي: انقر النظام والأمان كما يظهر في الشكل السابق لتحصل على الشكل التالي: يظهر من الشكل السابق بند "جدار حماية Windows"، انقره للوصول إلى النافذة الرئيسيّة لتطبيق جدار الحماية كما في الشكل التالي: يظهر من هذا الشكل وجود نوعين من الشبكات التي يقوم جدار حماية ويندوز بمراقبتها. سبب وجود أكثر من شبكة يساعد على جعل العمل على ويندوز 10 أيسر. هناك نوعين من الشبكات كما هو واضح من الشكل السابق: النوع الأول هو "شبكات خاصة" والتي تشتمل على الشبكات المنزليّة، وشبكات العمل والتي تُعتبر بيئة عمل آمنة، فقد يرغب المرء بمشاركة الملفات والصور بين أجهزة الحاسوب المتصلة على نفس الشبكة، أو الوصول إلى الطابعة اللاسلكية مثلًا، وغيرها من الأجهزة التي يمكن وصلها على الشبكة. فمن الممكن في هذه الحالة تعطيل جدار الحماية على هذا النوع من الشبكات، وذلك لجعل تنفيذ مثل هذه العمليّات أسهل بكثير، ودون الحاجة إلى ضبط الكثير من الاعدادات، كون أنّ مثل هذه الشبكات تكون آمنة على المستوى الشخصي. أمّا النوع الثاني فهو "شبكات عامة أو شبكات الضيوف" وهو نوع غير آمن بالضرورة، حيث نحتاج في هذه الحالة إلى تفعيل جدار الحماية للوقاية من الأخطار الكامنة. يتيح لنا التصنيف السابق أن نجعل عمليّة الحماية انتقائيّة بحسب نوع الشبكة. فبالنسبة إلى النوع الأوّل يمكننا تعطيل جدار الحماية بكل بساطة، أمّا بالنسبة إلى النوع الثاني، فيمكننا إبقاء حالة التشغيل له، وسيتذكّر ويندوز 10 مثل هذه الخيارات دومًا بالنسبة لكل شبكة، مما يغنينا عن تشغيل أو إيقاف جدار الحماية بالنسبة لكل نوع. لإيقاف تشغيل جدار الحماية بالنسبة للشبكات الخاصة انقر على الرابط "تشغيل جدار الحماية Windows أو إيقاف تشغيله" الموجود في الجهة اليمنى من النافذة التي تظهر في الشكل السابق لتظهر لك النافذة التالية: انقر على خيار "إيقاف تشغيل جدار حماية Windows (غير مستحسن)" الخاص بإعدادات الشبكات الخاصة. ثم انقر زر "موافق". إنشاء قواعد للتحكم بوصول التطبيقات إلى الانترنت يمكن التحكّم بوصول تطبيق مُحدّد موجود على الحاسوب إلى الانترنت، أو حتى إلى الشبكة الخارجية، وذلك عن طريق الإعدادات المتقدّمة الموجودة في الجهة اليمنى من النافذة الرئيسية الخاصة بإعدادات جدار الحماية. عند نقر "إعدادات متقدّمة" ستحصل على شكل شبيه بما يلي: انقر Outbound Rules للتحكم بقواعد الاتصالات الصادرة. ستعرض النافذة جميع القواعد المتوفرة كما في الشكل التالي: انقر الخيار New Rule الموجود ضمن العمود الأيمن من النافذة في الشكل السابق، لتحصل على شكل شبيه بما يلي: يتم من خلال هذه النافذة تحديد النوع الذي ستطبّق عليه هذه القاعدة. فيما إذا كان برنامج عادي Program أو منفذ Port أو قاعدة معرفة مسبقًا Predefined أو قاعدة مخصّصة Custom. سنترك الخيار الافتراضي وهو Program. انقر بعد ذلك الزر Next. ستظهر لك نافذة تسمح لك بتحديد البرنامج الذي سيتم تطبيق هذه القاعدة عليه. انقر زر Browse لتحديد مسار الملف البرمجي المطلوب كما في الشكل التالي: اختر مسار البرنامج الذي ترغب بمنعه من الوصول إلى الانترنت. بالنسبة إلي سأختار برنامج المفكرة المحلق بالويندوز على سبيل المثال. انقر بعدها على Next. ستظهر نافذة تطلب منك تحديد نوع القاعدة فيما إذا كانت قاعدة منع للاتصال أم قاعدة سماح للاتصال أم قاعدة سماح بالاتصال في حال كان الاتصال آمنًا secured. وهذا يعني أنّ نفس الخطوات ستجري تمامًا إذا أردنا السماح لتطبيق ما بالاتصال بالانترنت وليس منعه. سنختار بالطبع منع التطبيق من الاتصال بالانترنت “Block the connection” في مثالنا هذا. انقر زر Next للمتابعة حيث ستحصل على الشبكات التي سيتم تطبيق هذه القاعدة عليها. اترك الاختيارات الافتراضية كما هي، ثم انقر زر Next مجددًا. بقي أمر أخير قبل إنشاء القاعدة وهو تحديد اسم لها Name، مع إضافة بعض الوصف ضمن الحقل Description. بالنسبة إلي سأختار الاسم Block Notepad Application. اضغط زر Finish ليتم انشاء القاعدة ومن ثمّ إدراجها ضمن مجموعة القواعد التي لديك. الخلاصة تعرّفنا في هذا المقال على كيفيّة التعامل مع جدار الحماية الخاص بويندوز. ذلك التطبيق المهم الذي يُستخدم للحماية من الأخطار التي تهدّد الخصوصيّة والأمن للمستخدم. تعلّمنا كيفيّة ضبطه بالشكل الملاءم للشبكة التي نتصل من خلالها، كما تعلّمنا كيفيّة منع تطبيق مُحدّد من الاتصال بالانترنت حسب قواعد rules خاصّة. هناك الكثير مما يمكن قوله حول جدران الحماية، ولكن سنكتفي بما أوردناه في هذا المقال.

تعد Let’s Encrypt خدمة تقدم شهادات SSL مجانية من خلال واجهة برمجة تطبيقات تلقائية (automated API). أما عميل Let’s Encrypt الأكثر شيوعًا فهو عميل Certbot الخاص بـ EFF. يقدم Certbot مجموعة متنوعة من الطرق للتحقق من صحة المجال الخاص بك، وجلب الشهادات، وتكوين Apache و Nginx تلقائيًا. في هذا المقال، سنناقش الوضع المستقل لـ Certbot وكيفية استخدامه لتأمين أنواع أخرى من الخدمات، مثل خادم البريد أو وسيط الرسائل مثل RabbitMQ. لن نناقش تفاصيل تكوين طبقة المنافذ الآمنة (SSL)، لكن عند الانتهاء ستحصل على شهادة صالحة يتم تجديدها تلقائيًا. وإنك ستكون قادرًا على أتمتة إعادة تحميل الخدمة للحصول على الشهادة المُجددة. المتطلبات قبل مباشرتك بقراءة هذا الدليل, ستحتاج إلى: خادم دبيان 10، مستخدم غير جذري بإمتيازات sudo، وجدار حماية أساسي. اسم نطاق يشير إلى الخادم الخاص بك. يجب عدم استخدام المنفذ 80 أو 443 على الخادم الخاص بك. وإذا كانت الخدمة التي تحاول تأمينها موجودة على جهاز مزود بخادم ويب يشْغل كلا هذين المنفذين، فسيلزمك استخدام وضع مختلف مثل وضع webroot_ الخاص بـ Certbot أو وضع التحدي المعتمد على DNS. الخطوة الأولى - تثبيت Certbot يحوي دبيان 10 على عميل Certbot في المستودع الافتراضي الخاص به، حيث يجب أن يكون محدثًا بما يكفي للاستخدام الأساسي. وإذا كنت بحاجة إلى القيام بتحديات مرتبطة بـ DNS أو استخدام ميزات Certbot الأحدث الأخرى، عندها يتوجب عليك التثبيت من buster-backports repo كما هو موضح في توثيق Certbot الرسمي. قم بتحديث قائمة الحزمة: $ sudo apt update استخدم apt لتثبيت حزمة certbot: $ sudo apt install certbot يمكنك اختبار التثبيت عن طريق مطالبة certbot بإخراج رقم إصداره: $ certbot --version certbot 0.31.0 بعد قيامك بتثبيت Certbot، قم بتشغيله للحصول على شهادتك. الخطوة الثانية - تشغيل Certbot يحتاج Certbot للرد على اختبار تشفير صادر عن واجهة برمجة التطبيقات (API) الخاص بـ Let’s Encrypt لإثبات أننا نتحكم في نطاقنا. حيث يستخدم المنافذ 80 (HTTP) أو 443 (HTTPS) لتحقيق ذلك. قم بفتح المنفذ المناسب في جدار الحماية: $sudo ufw allow 80 استبدل 443 أعلاه إذا كان هذا هو المنفذ الذي تستخدمه. حيث سيخرج ufw تأكيدًا بأنه قد تم إضافة ادارتك: Rule added Rule added (v6) يمكننا الآن تشغيل Certbot للحصول على شهادتنا. حيث سنستخدم ‎--standalone لإخبار Certbot بالتعامل مع التحدي باستخدام خادم الويب المدمج الخاص به. ويرشد خيار ‎--preferred-challenges إلى Certbot لاستخدام المنفذ 80 أو المنفذ 443. فإذا كنت تستخدم المنفذ 80، فستستخدم خيار ‎--preferred-challenges http. وأما بالنسبة إلى المنفذ 443، استخدم ‎--preferred-challenges tls-sni. والآن سنستخدم الراية ‎-d لتحديد النطاق الذي نطلب شهادة له. حيث يمكنك إضافة رايات ‎-d متعددة لتغطية نطاقات متعددة في شهادة واحدة. للتوضيح سنستخدم ‎‎--preferred-challenges http، لكن يتحتم عليك استخدام الخيار المناسب حسب حالة الاستخدام الخاصة بك. والآن قم بتشغيل الأمر التالي مع الخيارات المفضلة لديك للحصول على شهادتك: $sudo certbot certonly --standalone --preferred-challenges http -d your_domain عند تشغيل الأمر سيُطلب منك إدخال عنوان بريد إلكتروني والموافقة على شروط الخدمة. وبعد قيامك بذلك من المفترض أن ترى رسالة تخبرك عن مكان تخزين الشهادات موضحاً فيها بأن العملية كانت ناجحة: IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/your_domain/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/your_domain/privkey.pem Your cert will expire on 2019-08-28. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le ها قد حصلنا على شهاداتنا. دعنا الآن نلقي نظرة على ما قمنا بتنزيله وكيفية استخدام الملفات مع برنامجنا. الخطوة الثالثة - إعدادات التطبيق لن نتطرق في هذه المقالة إلى إعداد SSL لتطبيقك، حيث أن لكل تطبيق متطلبات وخيارات تهيئة مختلفة، لكن دعنا نلقي نظرة على ما تم تنزيله من قِبل Certbot. استخدم ls لعرض المجلد الذي يحوي مفاتيحك وشهاداتك: $sudo ls /etc/letsencrypt/live/your_domain سترى الناتج التالي: cert.pem chain.pem fullchain.pem privkey.pem README يحتوي ملف README في هذا المجلد على مزيد من المعلومات حول كل ملف من هذه الملفات. غالبًا ما ستحتاج فقط إلى ملفين من هذه الملفات: privkey.pem: هذا هو المفتاح الخاص بالشهادة. ويجب الإبقاء على هذا المفتاح بشكل آمن وسري، فهذا هو السبب في أن معظم ما في مجلد ‎/etc/letsencrypt لديه أذونات مقيدة للغاية حيث يمكن الوصول إليه فقط من قبل المستخدم الجذر root. ستشير معظم إعدادات البرامج إلى هذا الملف على أنه ملف ssl-certificate-key أو ssl-certificate-key-file. fullchain.pem: هذه هي شهادتنا مرفقة بجميع الشهادات الوسيطة. ستستخدم معظم البرامج هذا الملف للحصول على الشهادة الفعلية، وستشير إليه في إعداداتها باسم مثل ssl-certificate. لمزيد من المعلومات حول الملفات الأخرى الموجودة، راجع قسم Where are my certificate?‎ من توثيق Certbot. ستحتاج بعض البرامج إلى شهاداتها في تنسيقات أو مواقع أخرى، أو بأذونات مستخدم أخرى. من الأفضل ترك كل شيء في مجلد letsencrypt وعدم تغيير أي أذونات هناك (سيتم استبدال الأذونات عند التجديد على أي حال)، ولكن قد لا يكون هذا الخيار مناسبًا، ففي هذه الحالة ستحتاج إلى كتابة نص برمجي لنقل الملفات وتغيير الأذونات حسب الحاجة. حيث يجب تشغيل هذا النص البرمجي عند تجديد Certbot للشهادات والتي سنتحدث عنها بعد ذلك. الخطوة الرابعة - التعامل مع التحديثات التلقائية لـ Certbot تعد شهادات Let's Encrypt صالحة لمدة تسعين يومًا فقط. وهذا لدفع المستخدمين إلى أتمتة عملية تجديد الشهادة. حيث تقوم بذلك حزمة certbot التي قمنا بتثبيتها عن طريق إضافة سطر برمجي إلى ‎/etc/cron.d. ويعمل هذا السطر البرمجي مرتين يوميًا ليقوم بتحديث أي شهادة ستنتهي صلاحيتها خلال ثلاثين يومًا. مع تجديد شهاداتنا تلقائيًا ما زلنا بحاجة إلى طريقة لتشغيل مهام أخرى بعد التجديد. حيث سنحتاج على الأقل إلى إعادة تشغيل خادمنا أو إعادة تحميله لاستلام الشهادات الجديدة، وكما ذكرنا في الخطوة الثالثة قد نحتاج إلى التلاعب في ملفات الشهادات بطريقة ما لجعلها تعمل مع البرنامج الذي نستخدمه. وهذا هو الغرض من خيار renew_hook. لإضافة renew_hook، نحتاج إلى تحديث ملف تكوين تجديد الخاص بـ Certbot. حيث يتذكر Certbot جميع التفاصيل عن كيفية جلبك الشهادة لأول مرة، وسيتم تشغيله بنفس الخيارات عند التجديد. نحتاج فقط إلى إضافة الخطاف (hook) الخاص بنا. قم بفتح ملف التكوين باستخدام أي محرر تفضله: $sudo nano /etc/letsencrypt/renewal/your_domain.conf سيتم فتح ملف نصّي ‎/etc/letsencrypt/renewal/your_domain.conf مع بعض خيارات الإعدادات. بعدها قم بإضافة خطافك (hook) على السطر الأخير. نستخدم في هذه الحالة مثالًا يعيد تحميل خدمة rabbitmq: $renew_hook = systemctl reload rabbitmq قم بتحديث الأمر أعلاه بإضافة كل ما تحتاج تشغيله لإعادة تحميل الخادم أو قم بتشغيل سكربت مخصص للقيام بذلك. عادةً ما نستخدم في دبيان خدمة systemctl لإعادة تحميل الخدمة. احفظ الملف وأغلقه، ثم قم بتشغيل Certbot بوضعية التشغيل الجاف (dry run) للتأكد من أن الصيغة صحيحة: $sudo certbot renew --dry-run إذا لم ترَ أي أخطاء فأنت جاهز تمامًا. فقد تم تعيين Certbot للتجديد عند الضرورة وتشغيل أي أوامر مطلوبة للحصول على الخدمة باستخدام الملفات الجديدة. الملخص في هذا المقال، ثبّتنا Certbot Let’s Encrypt Client، وتنزيل شهادة SSL باستخدام الوضع المستقل، كما وقمنا بتمكين عمليات التجديد التلقائي بخطافات التجديد (renew hooks). فمن المفترض أن يمنحك هذا بداية جيدة لاستخدام شهادات Let’s Encrypt مع خدمات مغايرة خادم الويب الإعتيادي. لمزيد من المعلومات يرجى الإطلاع على توثيق Certbot ترجمة -وبتصرف- للمقال How To Use Certbot Standalone Mode to Retrieve Let's Encrypt SSL Certificates on Debian 10 لأصحابه Brian Boucheron و Kathleen Juell و Hanif Jetha

في الدرس السابق تحدثنا عن طرق تثبيت ووردبريس لأول مرة بأمان. في هذا الدرس، سنتحدّث عن كيفية تأمين موقع ووردبريس بعد تثبيته، سنتحدّث عن أساليب أفضل للحماية فوق مستوى نصائح "اختر كلمة مرور أكثر تعقيدًا" وسنحاول الغوص قليلًا في موضوع أمان ووردبريس. تقييد عمليات تسجيل الدخولواحدٌ من أول الأشياء التي يجب عليك فعلها لتأمين موقع ووردبريس الخاصّ بك هو تقييد عدد المرّات التي يمكن لشخصٍ ما أن يحاول تسجيل الدخول بها إلى الموقع. يحاول العديد من المخترقين القيام بهجمات التخمين أو ما يعرف بـ Bruteforce لمحاولة كسر اسم المستخدم / كلمة المرور الخاصّيَن بك، وحتّى لو لم تنجح هذه الهجمات في اختراق موقعك، فإنّه ستقوم باستهلاك جزء كبير من موارد خادومك وستقوم بوضع حملٍ عليه. عبر تقييد عمليات تسجيل الدخول، يمكنك منع المخترقين من محاولة القيام بهجمات Bruteforce. بمجرّد أن يقوم بمحاولة تخمين كلمة المرور مرتين أو ثلاث، فسيتم حظر عنوان الـIP الخاصّ به. يمكنك القيام بهذا الأمر بسهولة عبر تثبيت إصافة Limit Login Attempts، صحيحٌ أنّه لم يتم تحديثها منذ سنتين ولكنّها تمتلك مميزاتٍ رائعة، ولكن ربّما تودّ تجاهلها حاليًا بسبب انقطاع دعمها عن التحديثات الأمنية. عوضًا عن هذا، فإننا ننصح بإضافة Login Lockdown، تسمح لك هذه الإضافة أيضًا بتقييد عدد مرّات تسجيل الدخول الفاشلة قبل أن يتم حظر عنوان الـIP الخاصّ بالمستخدم الذي يحاول الدخول، كما يمكنك اختيار المدّة التي تريد حظر عنوان الـIP خلالها، ستصبح هجمات Bruteforce أصعب بكثير بعد تثبيت هذه الإضافة وضبطها، لأنّه سيجب على المخترقين استخدام وسيط (Proxy) بعد كلّ 3 محاولات فاشلة لتسجيل الدخول، وسيجب عليهم تغيير ذلك الوسيط آلاف المرّات ليتمكّنوا من تحقيق الهجوم، وهو الأمر الذي لا يتوفّر لديهم غالبًا. حظر المستخدمين الذين يحاولون تسجيل الدخول باسم Adminمن المهم ألّا تستخدم اسم "admin" كاسم مدير الموقع على موقعك، ومن المهم أيضًا أن تقوم بحظر كلّ من يحاول الدخول إلى ذلك المستخدم (طالما أنتَ لستَ المدير، والحساب غير موجود، فلماذا تحاول الدخول؟ إذن فأنتَ مُخترِق)، يمكنك القيام بهذا عن طريق إضافة Wordfence. تسمح لك هذه الإضافة بإعداد ميزة الحظر التلقائي هذه، بالطبع، هناك العديد من المميزات الأخرى في هذه الإضافة التي يمكنك استخدامها من أجل الحماية، مثل الاستيثاق الثنائي (two-factor authentication)، حظر الهجمات الشائعة والمزيد. ضبط صلاحيات الملفّات الصحيحةشيءٌ آخر يمكنك فعله هو ضبط صلاحياتٍ مناسبة للملفّات على موقعك. وفقًا لـ WordPress.org، فإنّ استخدام صلاحيات 777 للملفّات / المجلّدات هو أمرٌ خطير للغاية ويسمح للجميع أن يقوموا بتعديل ملفّات موقعك وإضافة أكواد خبيثة أو حتّى حذف الموقع بالكامل. يجب عليك أن تقوم بوضع صلاحيات 600 لملفّ wp-config.php، بينما يجب عليك أن تقوم بتعيين ملفّاتك الأخرى إلى وضع صلاحيات 640 أو 644، كما يجب أن تكون المجلّدات الموجودة على موقعك بالصلاحيات 750 أو 755. يمكنك تعلّم المزيد عن الصلاحيات عبر دليل ووردبريس الرسمي لتغيير الصلاحيات. إنشاء ملف htaccess.إذا كنتَ تريد تركيبة روابط دائمة (permalinks) جميلة لموقعك فإنّك ستحتاج ملفّ htaccess. عبر إضافة واحدٍ إلى موقعك فإنّك ستقوم بتحسين مستوى الحماية قليلًا، صحيحٌ أنّه ليس حلًا كاملًا ولا يمكنه فعل شيء جوهري لوحده ولكنّه إضافة جيّدة. هناك شرح شامل منشور على الويب حول إنشاء ملفّ htaccess. ، لن نقوم بشرح تلك العملية بالكامل هنا لأنّ العملية مشروحة بذاك الدليل بشكلٍ شامل. بمجرّد أن تقوم باتّباع ذاك الشرح فإنّه سيصبح بإمكانك منع الوصول إلى ملفّات معيّنة على موقع ووردبريس الخاصّ بك. إذا لم يكن الناس قادرين على الوصول إلى تلك الملفّات التي تريدها فلن يكونوا قادرين على العبث بها. لزيادة صعوبة اختراق موقع ووردبريس الخاصّ بك ستحتاج إلى إضافة بضع سطور من الأكواد لحظر الوصول إلى ملفّات معينة مثل: wp-config.phpreadme.htmllicense.txtwp-includes directoryيمكنك أيضًا منع الوصول إلى امتدادات معيّنة للملفّات، مثل ملفّات النسخ الاحتياطي، الإعدادات، السجلات المحفوظة على الخادوم.. إلخ. بشكلٍ عام، يجب حظر الوصول إلى أيّ شيء يتعلّق بالتصميم والتطوير والتوثيق الخاصّ بخلفيّة الموقع (back-end). إذا كنتَ تريد حظر الوصول إلى مجلّد إضافة أو قالب معيّن أو مسارٍ آخر على موقعك، فيمكنك حظر المجلّد بأكمله إن أردت. هذه حركة جيّدة للقيام بها في كلّ مجلّد لا يمتلك بداخله ملفّ index. حيث أنّ المجلّدات التي لا تحتوي على ملفّات index ستقوم بعرض كلّ الملفّات الموجودة بداخل ذاك المجلّد، مما يعطي معلوماتٍ هامّة يمكن استغلالها من طرف المخترقين، لذا يجب عليك إخفاؤها. إخفاء صفحة تسجيل الدخولهذا تعديلٌ آخر يمكن القيام به عن طريق htaccess. ولكن مختلف قليلًا عن التعديلات الأخرى ولذلك سنذكره هنا. يمكنك حظر وصول أيّ شخص إلى صفحة تسجيل الدخول الخاصّة بموقعك ومنح حقّ الوصول فقط إلى عنوان الـIP الخاصّ بك، وطبعًا، يجب أن يكون هناك مستخدمٌ واحد فقط للموقع بأكمله، وبالتالي فتلك ليست طريقة عملية حقًا لاستخدامها. إذا كنتَ تريد إبقاء خيارٍ مفتوح لإضافة كتّابٍ ومستخدمين آخرين إلى موقعك لاحقًا، فيمكنك استخدام إضافة Secure Hidden Login. تسمح لك هذه الإضافة بإخفاء حقول الإدخال من صفحة تسجيل الدخول الخاصّة بموقعك، ويتم إظهار حقول الإدخال لاسم المستخدم وكلمة المرور فقط عند الضغط على اختصاراتٍ معيّنة على لوحة المفاتيح، فإن حاول أحدهم فتح صفحة تسجيل الدخول، فلن يتمكّن من ذلك دون أن يعرف ما هي اختصارات لوحة المفاتيح التي تقوم بعرض صفحة تسجيل الدخول. إزالة وسم Generatorيقوم المخترقون بكلّ شيءٍ قد يمكّنهم من اختراق موقعك، واحدٌ من هذه الأشياء هو سكربتٌ شهير يستخدمه المخترقون لالتقاط المواقع التي تعمل بإصدارات معيّنة من ووردبريس عبر بصمات الأقدام (Footprints)، بصمات الأقدام هي عبارة عن سطور متعددة من الأكواد يمكن استخدامها للتعرّف على هوية موقع ويب ما، لسوء الحظّ فإن ووردبريس يستخدم هذه البصمات مما يجعل مواقع ووردبريس الموجودة على الشبكة قابلة للاكتشاف بسهولة. قد تبدو بصمة القدم الخاصّة بموقع ووردبريس كشيءٍ مثل: <meta name="generator" content="WordPress 3.8.4" />يمكنك إزالة هذا الوسم إن أردت من الشفرة المصدرية الخاصّة بموقعك، ولكن ما يزال عليك إضافة الشفرة التالية إلى ملفّ functions.php الخاصّ بقالبك: remove_action('wp_head', 'wp_generator');بعد هذا، لن يقوم موقع ووردبريس الخاصّ بك بتعريف نفسه على أنّه موقعٌ يعمل بسكربت ووردبريس، مما يصعّب المهمّة على المُخترقِين. تفعيل الاستيثاق الثنائي Two-Step Authenticationشيءٌ آخر يمكنك فعله لتأمين موقعك هو تفعيل الاستيثاق الثنائي أو ما يدعى بـ Two-Step Authentication. عندما تقوم بطلب خطوتين للاستيثاق من مستخدمي موقعك عوضًا عن خطوة واحدة فإنّك تصعّب الأمر جدًا على المُخترقِين. هناك عدّة إضافات موجودة لتفعيل الاستيثاق الثنائي على ووردبريس ومن بينها: Clef: بمجرّد تثبيت هذه الإضافة، فإنّ كل ما سيجب عليك فعله هو فتح تطبيق Clef على هاتفك المحمول وتركيز كاميرا الهاتف على شاشة الحاسوب الخاصّة بك، بعدها سيتم فتح القفل الموجود على موقعك وتتمكن من الدخول. Duo Two-Factor Authentication: بعد أن تقوم بإدخال كلمة المرور الخاصّة بك في مربّع الإدخال التقليدي، سيجب عليك إكمال خطوةٍ أخرى لإتمام عملية تسجيل الدخول، مثل تأكيد تسجيل الدخول من على هاتفك الذكي عبر رسالة SMS وغيرها من الطرق.الخاتمةإدارة الحماية على موقع ووردبريس الخاصّ وإعداد عمليات تسجيل الدخول ليتم تقييدها قدر المستطاع هو أمرٌ قد يستغرق منك بعض الوقت، ولكن بمجرّد أن تكتمل هذه الأمور، فإنّ موقعك سيكون أكثر أمانًا لمستخدميه. ترجمة -وبتصرف- للمقال The WordPress Developer’s Guide to Security: Management & Logins لصاحبته Brenda Barron.

أنهينا الجزء الأكبر من العمل على تقرير المبيعات في الدرس السابق وستكون مهمتنا في هذا الدرس إضافة بعض اللمسات السحرية والتشطيبات النهائيَّة لبدء استعمال التقرير. سنتعلم في هذا الدرس بعض التوابع الجديدة التي سنضيفها إلى تقرير المبيعات وسنعرِّج على موضوع حماية أوراق العمل والنطاقات أثناء مشاركة الملف مع الآخرين ثمَّ سنتعرَّف على كيفيَّة استعمال التنسيق الشرطي. دمج مجموعة من التوابع استعملنا في الدرس السابق القائمة المنسدلة لإدراج المنتج المُباع (حقل رقم المنتج والوصف) ولكن توجد حقيقةً طريقة أخرى متقدمة نستعمل فيها التوابع لاختيار وصف المنتج بالبحث عنه في جدول المخزون. التوابع التي سنستخدمها هي: التابع طريقة الاستعمال الوصف IFERROR IFERROR(value, [value_if_error]) يُرجع هذا التابع القيمة الأولى إن لم تكن خطأً، وإن كانت خطأ فيرجع القيمة الثانية إن كانت موجودة أو يرجع قيمة فارغة. يُستعمل للتحكم في ظهور الأخطاء في الخلايا. IF IF(logical_expression, value_if_true, value_if_false) يُرجع القيمة الأولى (value if true) إن تحقَّق التعبير المنطقي (logical expression) ويرجع القيمة الثانية إن لم يتحقق. ISNA ISNA(value) يُستعمل للتحقُّق إن كانت القيمة (value) هي خطأ ذو الرمز "#N/A" أي غير متاح أو متوافر (not available) أو لا يتوافر جواب للعمليَّة، ويُرجع العبارة "true" إن كانت القيمة هي خطأ من النوع السابق أو يُرجع العبارة "false" إن لم تكن خطأ. VLOOKUP VLOOKUP(search_key, range, index, [is_sorted]) يُستخدم للبحث العمودي، ومُدخلات هذا التابع هي: search_key: القيمة التي نبحث عنها. Range: المجال الذي نبحث فيه. Index: رقم الحقل الذي نريد جلب القيمة المقابلة للقيمة التي نبحث عنها في العمود الأول من المجال المحدَّد. is_sorted: إن كانت القيم في المجال المحدَّد مرتَّبة نضع "true" وإن لم تكن مرتَّبة نضع "false". قبل استعمال التابع دعنا نفعل شيئًا يسِّهل عملنا؛ سننتقل إلى ورق المخزون ونحدِّد جدول المخزون أي عمود رقم المنتج والوصف ثمَّ نضغط بزر الفأرة الأيمن ونختار “تعريف النطاق المحدَّد” ونعطي للنطاق المحدَّد عنوان “المنتجات” ثمَّ نضغط على “تم“؛ إن أردنا استعمال النطاق السابق في التوابع أو أي مكان فما علينا سوى كتابة اسمه. مزيَّة عنونة النطاق هي بقاء النطاق ثابت مهما تحركت الخليَّة أو نُسخت إلى مكان آخر في الجدول إذ إن لم يُثبَّت النطاق فسيتغير نسبة إلى تغير عنوان الخليَّة. نُدرج التوابع السابقة في الخليَّة E8 للبحث عن الوصف المقابل لرقم المنتج المُدخل في الخليَّة D8 في جدول المخزون وذلك كما موضح في الصورة. استعملنا أولًا التابع IFERROR لإظهار الرسالة التي نريدها إن وُجد خطأٌ ما لتجنب ظهور رموز لا نرغب بها؛ وضعنا في الدخل الأول التابع IF والدخل الثاني الرسالة “لم يُعثر على المنتج” لإظهارها في حال وجود أي خطأ. القيمة المنطقية للتابع IF هي التابع ISNA مع التابع VLOOKUP للتأكد من وجود القيمة التي نبحث عنا؛ إذا لم يجد التابع VLOOKUP ما يبحث عنه فسيُرجع الخطأ ‎#N/A وحينئذٍ سيُرجع التابع ISNA العبارة true أي يوجد خطأ وبالتالي يأخذ التابع IF القيمة الأولى وهي “لم يُعثر على المنتج”. أمَّا إن وجد التابع VLOOKUP القيمة التي يبحث عنها فسيرجع التابع ISNA القيمة false أي لا يوجد خطأ وبالتالي سيختار التابع IF القيمة الثانية وهي التابع VLOOKUP أي القيمة التي يرجعها هذا التابع وهي التي نبحث عنها في جدول المخزون. لاحظ أنَّنا استعملنا عبارة “المنتجات” للدلالة على عنوان جدول المخزون الذي نودُّ البحث فيه ويمكن استعمال النطاق مباشرةً مع الضغط على F4 لتثبيت عنوان النطاق. نسحب الخليَّة E8 إلى الخلايا السفليَّة لنسخ العلاقة وستكون النتيجة كما موضح بالصورة. إن وَجدت للوهلة الأولى أنَّ الأمر معقدٌ فجرِّب كتابة العلاقة السابقة بنفسك وأعد قراءة الشرح مرةً أخرى وستفهمها بالتأكيد. حماية الأوراق والخلايا انتهينا من إنشاء تقرير المبيعات وأصبح جاهزًا للاستخدام. سنشارك هذا الجدول مع العامل ليُدخل بيانات المنتجات التي يبيعها ولكن ماذا لو غيَّر قيم خلايا لا يحق له تغييرها مثل تغيير قيم جدول المخزون أو تغيير محتوى خليَّة الوصف التي تعذبنا كثيرًا حتى أنشأناها أو في محتوى الخلايا الأخرى بقصد أو بغير قصد؟! سنضطر هنا إلى حماية الأوراق أو الخلايا من عبث الأشخاص الذين نشاركهم ملفاتنا وسنعطي كلَّ شخص الصلاحيات المناسبة للتعديل على الخلايا والأوراق. نضغط على السهم الموجود بجانب ورقة المخزون ونختار “حماية الورقة” أو نختار من قائمة البيانات ← الأوراق والنطاقات المحميَّة وستظهر قائمة في الطرف الأيسر. نضع وصفًا لحماية الورقة ثمَّ نحدِّد إن كنا نريد حماية الورقة بأكملها أو نطاق محدَّد ضمن الورقة ثمَّ نحدِّد اسم الورقة وإن كنا نريد أن نستثني بعض الخلايا ليتاح تعديلها ثمَّ نضغط على “تعيين الأذونات“. يظهر لدينا خيارين؛ الخيار الأول هو إظهار تحذير عند تعديل النطاق أو الورقة المحميَّة إذ تظهر رسالة تنبهك إلى أنَّه لا يفترض تعديل هذا النطاق وإن كنت واثقًا من التعديل فاضغط موافق سواءً لك أو لمن تشاركهم الملف. الخيار الثاني هو تقييد من يمكنه تعديل النطاق أو الورقة ومنع جميع الأشخاص من التعديل باختيار “أنت فقط” أو اختيار “مخصص” للسماح لبعض الأشخاص من التعديل على الورقة أو النطاق بوضع إشارة بجانب أسمائهم. عند حماية الورقة أو الخلايا لن يتمكن الآخرون من التعديل عليها ولكن يستطيعون رؤيتها بحسب الإذن المعطى لهم. يمكن حماية حقول الوصف ونسبة ومقدار الضريبة والإجمالي في جدول بيانات المبيعات حتى لا يعبث أحدٌ بها فنحصل على معلومات خاطئة بالطريقة نفسها ولكن نختار “حماية نطاق” بدلًا من ورقة. فكرة إضافية: يمكن في جدول المخزون وضع سعر لكل قطعة وعندما نختار رقم المنتج يوضع سعرها في حقل بيانات المبيعات مباشرةً مثل حقل الوصف وهنا نحتاج إلى حقل يصف عدد المنتجات المُباعة وبذلك نحمي سعر المنتج ويتبقى إدخال التاريخ والوقت ورقم المنتج وعدد القطع المُباعة فقط. التنسيق الشرطي يُستعمل التنسيق الشرطي لتنسيق الخلايا اعتمادًا على مجموعة من القواعد يحدِّدها المستخدم والتي توازن محتوى الخليَّة مع تلك القواعد وتنسِّقها بناءً على ذلك. نستعمله في جعل لون الخليَّة أحمر مثلًا إن كانت تحوي عبارة “راسب” ليسهل علينا تحديد الطلاب الراسبين أو إن كانت قيمة الخليَّة أقل أو أكبر من قيمة معيَّنة؛ توجد الكثير من القواعد لتنسيق النصوص والتواريخ والأرقام ويمكن تخصيص قاعدة جديدة غير موجودة. يوفر تطبيق جداول بيانات google نوعين من التنسيق هما: لون فردي وتدرج ألوان؛ سنُنسق حقل مقدار الضريبة باللون الفردي لتحديد قيمة الضريبة الأقل من 200 ليرة. نحدِّد حقل مقدار الضريبة ونضغط بزر الفأرة الأيمن ونختار “تنسيق شرطي” أو من قائمة التنسيق ← تنسيق شرطي ثمَّ نختار قاعدة “أصغر من أو يساوي” ثمَّ نضع القيمة 200 ونحدِّد تنسيق الخليَّة ونضغط “تم“. سنُنسق حقل الإجمالي وفق تنسيق التدرج اللوني لمعرفة القيمة العظمى والقيمة الصغرى المباعة في اليوم. نضغط على إضافة قاعدة جديدة ونختار “تدرج اللون” ثمَّ نحدِّد خلايا الحقل في مربع “ينطبق على نطاق”؛ نختار التدرج اللوني المناسب ثمَّ نختار “الحد الأدنى” من خيارات القيمة الدنيا وخيار “الحد الأقصى” من خيارات القيمة العظمى. يظهر تنسيق الحقل كما موضح في الصورة. توجد قواعد كثيرة في التنسيق الشرطي تنتظرك لاستكشافها والتي تسهِّل عليك تنسيق جدولك وتحليل البيانات وقراءتها بسرعة. الخاتمة انتهينا من إنشاء تقرير المبيعات وأصبح جاهزًا لملء البيانات فيه وآمنًا لمشاركته مع الآخرين. إنَّ ما تعلمته إلى الآن يمكِّنك من إنشاء أغلب الجداول التي ستلزمك في جميع أمور حياتك اليوميَّة وبأفضل تصميم؛ كل ما عليك هو فتح تطبيق جداول بيانات جوجل والبدء بتصميم جدولك.

إن UFW، أو Uncomplicated Firewall (الجدار الناري غير المعقَّد)، هو واجهة للجدار الناري iptables الذي يجنح لتبسيط عملية ضبط جدار ناري؛ وعلى الرغم من أنَّ iptables هو أداةٌ قويةٌ ومرنة، لكن قد يكون من الصعب على المبتدئين أن يتعلموا استخدامه ليضبطوا جدارًا ناريًا ضبطًا سليمًا. إذا كنت تطمح إلى أن تبدأ بتأمين شبكتك، ولكنك لست متأكدًا من أيّ أداةٍ ستختار، فربما يكون UFW هو الخيار المناسب لك. سيريك هذا الدرس كيفية ضبط جدارٍ ناريٍ في أوبنتو 14.04 بوساطة UFW. المتطلبات المسبقةقبل أن تبدأ في تطبيق هذا الدرس، يجب أن تملك حسابَ مستخدمٍ ليس جذرًا لكنه يستطيع الحصول على امتيازات الجذر عبر الأمر sudo. يمكنك تعلم كيف يتم ذلك عبر تطبيق الخطوات من 1 إلى 3 على الأقل في درس الإعداد الابتدائي لخادوم أوبنتو 14.04. يكون UFW مُثبَّتًا افتراضيًا في أوبنتو؛ إذا ألغي تثبيته لسببٍ ما، فيمكنك إعادة تثبيته باستخدام الأمر: sudo apt-get install ufw استخدام IPv6 مع UFWإذا كان IPv6 مفعّلًا على خادومك، فتأكد أن UFW مضبوطٌ لدعم IPv6 كي تستطيع إدارة قواعد الجدار الناري الخاصة بعناوين IPv6 بالإضافة إلى IPv4؛ ولفعل ذلك، عدِّل ضبط UFW بمحررك النصي المفضّل؛ سنستخدم nano هنا: sudo nano /etc/default/ufw تأكد من أن قيمة «IPV6» مساويةٌ للقيمة «yes»؛ إذ يجب أن يبدو الملف كما يلي: /etc/default/ufw excerpt … IPV6=yes … احفظ واخرج، اضغط Ctrl-X للخروج من الملف، ثم Y لحفظ التعديلات التي أجريتها، ثم اضغط Enter لتأكيد اسم الملف. عندما يفعَّل UFW، فسيُضبَط لكتابة قواعد جدار ناري لعناوين IPv4 و IPv6. كُتِبَ هذا الدرس مع أخذ IPv4 بعين الاعتبار، لكنه قابل للتطبيق على IPv6 طالما كنت مفعِّلًا إياه. التحقق من حالة وقواعد UFWفي أي وقتٍ تريد، تستطيع التحقق من حالة UFW باستخدام هذا الأمر: sudo ufw status verbose افتراضيًا، يكون UFW معطّلًا لذلك سيظهر عندك شيءٌ شبيهٌ بما يلي: Status: inactive إذا كان UFW مفعّلًا، فسيخبرك الناتج ذلك، وسيُظهِر أيّة قواعد قد ضُبِطَت؛ على سبيل المثال، إذا ضُبِطَ الجدار الناري للسماح بالاتصالات من أيّ مكانٍ إلى SSH (المنفذ 22)، فسيكون الناتج شيئًا شبيهًا بما يلي: Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), disabled (routed) New profiles: skip To Action From -- ------ ---- 22/tcp ALLOW IN Anywhereيمكنك استخدام الأمر status في أي وقتٍ إذا أردت أن تعرف كيف ضَبَطَ UFW الجدارَ الناري. قبل تفعيل UFW، ربما تريد أن تتأكد أن جدارك الناري مضبوطٌ للسماح لك بالاتصال عبر SSH. لنبدأ بضبط السياسات الافتراضية (default policies). ضبط السياسات الافتراضيةإذا كنت قد بدأت لتوِّك مع جدارك الناري، فإن أولى القواعد التي عليك تعريفها هي السياسات الافتراضية؛ تتحكم هذه القواعد بطريقة معالجة البيانات الشبكية التي لم تُطابَق بدقّة مع أيّة قواعد أخرى؛ افتراضيًا، UFW مضبوطٌ لمنع جميع الاتصالات الواردة والسماح لكل الاتصالات الصادرة. هذا يعني أن أي شخصٍ يحاول أن يصل إلى خادومك السحابي لن يستطيع الاتصال، بينما يستطيع أيُ تطبيقٍ على خادومك أن يصل إلى «العالم الخارجي». لنرجع الضبط الافتراضي لقواعد UFW لكي نتأكد أنك تستطيع الإكمال مع هذا الدرس؛ استخدم الأمرين الآتيين لإعادة ضبط القيم الافتراضية المُستخدَمة من UFW: sudo ufw default deny incoming sudo ufw default allow outgoing وكما توقّعتَ، يعيد الأمران السابقان ضبط UFW إلى القيم الافتراضية بمنع الاتصالات الواردة والسماح للاتصالات الصادرة؛ قد تكون هذه القيم الافتراضية كافيةً للحواسيب الشخصية لكن تحتاج الخواديم إلى الرد على الطلبيات (requests) القادمة من المستخدمين الخارجيين؛ سنلقي نظرةً على ذلك لاحقًا. السماح لاتصالات SSHإذا فعّلنا جدار UFW الآن، فسيحجب جميع الاتصالات الواردة؛ هذا يعني أننا سنحتاج إلى إنشاء قواعد تسمح (وبدقّة) للاتصالات الشرعيّة (مثل اتصالات SSH أو HTTP) إذا أردنا أن يجيب خادومنا إلى ذاك النوع من الطلبيات؛ إذا كنت تستخدم خادومًا سحابيًا، فربما تريد السماح لاتصالات SSH الواردة كي تستطيع الاتصال وإدارة خادومك عن بُعد. لضبط خادومك للسماح باتصالات SSH، فاستخدم أمر UFW الآتي: sudo ufw allow ssh ينُشِئ الأمر السابق قواعد جدار ناري تسمح لجميع الاتصالات على المنفذ 22، الذي هو المنفذ الذي يستمع إليه «عفريت» (daemon)‏‏ ‏SSH؛ يعلم UFW ما هو «ssh» (بالإضافة إلى عدد كبير من أسماء الخدمات الأخرى) ولذلك لأنه مذكورٌ كخدمةٍ تَستخدمُ المنفذ 22 في ملف ‎/etc/services. نستطيع كتابة قاعدة مكافئة للقاعدة السابقة بتحديد المنفذ بدلًا من اسم الخدمة؛ على سبيل المثال، سيعمل هذا الأمر عمل الأمر السابق تمامًا: sudo ufw allow 22 إذا ضبطتَ عفريت SSH ليستخدم منفذًا آخر، فربما عليك تحديد المنفذ الملائم؛ على سبيل المثال، إذا كان يستمع خادم SSH إلى المنفذ 2222، فيمكنك استخدام الأمر الآتي للسماح للاتصالات على ذاك المنفذ: sudo ufw allow 2222 الآن، وبعد أن ضبطتَ جدارك الناري للسماح لاتصالات SSH القادمة، فعلينا تفعيله. تفعيل UFWاستخدم الأمر الآتي لتفعيل UFW: sudo ufw enable سيظهر لك تحذيرٌ يقول: «قد يقطع هذا الأمر اتصالات SSH الموجودة»؛ لكننا قد ضبطنا مسبقًا قاعدةً تسمح لاتصالات SSH، لذلك لا بأس من الإكمال، أجب بكتابة y. قد فعَّلتَ الجدار الناري الآن، تستطيع تنفيذ الأمر: sudo ufw status verbose لمعرفة القواعد المضبوطة. السماح لبقية الاتصالاتعليك الآن السماح لبقية الاتصالات التي يجب على خادومك الإجابة عليها؛ الاتصالات التي ستَسمح لها تتعلق باحتياجاتك. ولحسن الحظ، لقد تعلمت كيف تكتب قواعدًا تسمح للاتصالات بناءً على اسم الخدمة أو المنفذ (حيث فعلنا ذلك لخدمة SSH على المنفذ 22)؛ سنريك عدّة أمثلة لخدماتٍ شائعةٍ جدًا ربما تريد أن تسمح لها في جدارك الناري. إذا كانت لديك أيّة خدمات أخرى تريد السماح لاتصالاتها الواردة، فاتّبِع تلك الصيغة. خدمة HTTP – المنفذ 80يمكن السماح لاتصالات HTTP التي تستخدمها خوادم الويب غير المشفَّرة (unencrypted) بالأمر الآتي: sudo ufw allow http أو إذا كنت تفضِّل استخدام رقم المنفذ (80)، فنفِّذ هذا الأمر: sudo ufw allow 80 خدمة HTTPS – المنفذ 443يمكن السماح لاتصالات HTTPS التي تستخدمها خوادم الويب المشفَّرة (encrypted) بالأمر الآتي: sudo ufw allow https أو إذا كنت تفضِّل استخدام رقم المنفذ (443)، فنفِّذ هذا الأمر: sudo ufw allow 443 خدمة FTP – المنفذ 21يمكن السماح لاتصالات FTP التي تُستخدَم لنقل الملفات دون تشفير (والتي لا يجدر بك استخدامها على أيّة حال) بالأمر الآتي: sudo ufw allow ftp أو إذا كنت تفضِّل استخدام رقم المنفذ (21)، فنفِّذ هذا الأمر: sudo ufw allow 21/tcp السماح لمجالات منافذ معيّنةيمكنك تحديد مجالات منافذ عبر UFW؛ حيث تَستخدِم بعض التطبيقات عدِّة منافذ، بدلًا من منفذٍ واحد. على سبيل المثال، للسماح لاتصالات X11، التي تستخدم المنافذ 6000-6007، فاستخدم هذين الأمرين: sudo ufw allow 6000:6007/tcp sudo ufw allow 6000:6007/udp عند تحديد مجالات للمنافذ مع UFW، فيجب عليك تحديد البروتوكول (tcp أو udp) الذي تُطبَّق عليه القاعدة؛ لم نذكر ذلك من قبل لأنه عدم تحديد البروتوكول يسمح ببساطة بالاتصالات لكلي البروتوكولَين، وهذا مقبولٌ في أغلبية الحالات. السماح لعناوين IP محددةعند العمل مع UFW، تستطيع تحديد عناوين IP؛ على سبيل المثال، إذا أردت السماح للاتصالات من عنوان IP محدد، مثل عنوان IP للعمل أو المنزل الذي هو 15.15.15.51، فعليك استخدام الكلمة «from» ثم عنوان IP: sudo ufw allow from 15.15.15.51 تستطيع تحديد منفذ معيّن يُسمَح لعنوان IP بالاتصال إليه عبر كتابة «to any port» متبوعةً برقم المنفذ؛ على سبيل المثال، إذا أردت السماح لعنوان 15.15.15.51 بالاتصال إلى المنفذ 22 (SSH)، فاستخدم هذا الأمر: sudo ufw allow from 15.15.15.51 to any port 22 السماح للشبكات الفرعيةإذا أردت السماح لشبكة فرعية من عناوين IP، فيمكنك استخدام «ترميز CIDR»‏ (CIDR notation) لتحديد شبكة فرعية؛ فعلى سبيل المثال، إذا أردت السماح لجميع عناوين IP التي تتراوح بين 15.15.15.1 إلى 15.15.15.254 فيمكنك استخدام هذا الأمر: sudo ufw allow from 15.15.15.0/24وبشكلٍ مشابه، تستطيع أيضًا تحديد منفذ يُسمَح للشبكة الفرعية 15.15.15.0/24 بالاتصال إليه؛ سنستخدم أيضًا المنفذ 22 (SSH) كمثال: sudo ufw allow from 15.15.15.0/24 to any port 22 السماح بالاتصالات إلى بطاقة شبكية محددةإذا أردت إنشاء قاعدة جدار ناري تُطبَّق فقط على بطاقةٍ شبكيّةٍ محددة، فيمكنك فعل ذلك عبر كتابة «allow in on» متبوعةً باسم البطاقة الشبكيّة. ربما تريد أن تبحث عن بطاقاتك الشبكيّة قبل الإكمال؛ استخدم هذا الأمر لفعل ذلك: ip addr الناتج: … 2: eth0: حجب الاتصالاتإذا لم تعدِّل السياسة الافتراضية للاتصالات الواردة، فإن UFW مضبوطٌ ليحجب كل الاتصالات الواردة؛ عمومًا، هذا يُبسِّط عملية إنشاء سياسة جدار ناري آمنة وذلك بتطلّب إنشاء قواعد تحدد بدقة المنافذ وعناوين IP التي يسمح لها «بالعبور»؛ لكن في بعض الأحيان، تريد أن تحجب اتصالاتٍ معينة بناءً على عنوان IP المصدري أو الشبكة الفرعية، ربما لأنك تعلم أن خادومك يتعرض للهجوم من هناك. وأيضًا لو حوّلت سياسة التعامل الافتراضية مع الاتصالات الواردة إلى «السماح» (والذي ليس مستحسنًا لصالح الأمان)، فعليك إنشاء قيود «حجب» لأي خدمة أو عناوين IP لا تريد السماح بمرور الاتصالات إليها. يمكنك استخدام الأوامر المشروحة آنفًا لكتابة قيود الحجب، لكن مع استبدال «deny» بالكلمة «allow». على سبيل المثال، لحجب اتصالات HTTP، فعليك استخدام الأمر: sudo ufw deny http أو إذا أردت حجب جميع الاتصالات من 15.15.15.51 فيمكنك استخدام هذا الأمر: sudo ufw deny from 15.15.15.51 إذا أردت مساعدةً في كتابة قواعد الحجب، فانظر إلى قواعد السماح السابقة وعدِّلها بما يلائمها. لنلقِ الآن نظرةً على طريقة حذف القواعد. حذف القواعدمعرفة كيفية حذف قواعد الجدار الناري بنفس أهمية معرفة كيفية إنشائها؛ هنالك طريقتان لتحديد أيّة قواعد لتحذف: عبر رقم القاعدة أو عبر القاعدة نفسها (بشكلٍ شبيه لطريقة تحديد القاعدة عندما أُنشِئت). سنبدأ بطريقة الحذف عبر رقم القاعدة لأنها أسهل، مقارنةً بكتابة القواعد نفسها، خصوصًا إن كنتَ حديث العهد بالتعامل مع UFW. عبر رقم القاعدةإذا كنت تستخدم رقم القاعدة لحذف قواعد الجدار الناري، فإن أول شيء تريد فعله هو الحصول على قائمة بقواعد جدارك الناري؛ يملك أمر UFW status خيارًا لعرض الأرقام بجوار قواعدها، كما هو مبيّن هنا: sudo ufw status numbered الناتج: Status: active To Action From -- ------ ---- [ 1] 22 ALLOW IN 15.15.15.0/24 [ 2] 80 ALLOW IN Anywhereإذا قررت أنك تريد حذف القاعدة 2، التي تسمح بالاتصالات إلى المنفذ 80 (HTTP)، فيمكنك ذلك عبر تمرير رقمها إلى أمر UFW delete كما يلي: sudo ufw delete 2 ما سبق سيُظهِر محثًا (prompt) ليطلب موافقتك، ثم سيحذف القاعدة 2 التي تسمح باتصالات HTTP. الحظ أنك إن كنت قد فعَّلت IPv6، فعليك أن تحذف قاعدة IPv6 المناظرة لها. عبر القاعدة نفسهاالبديل عن تحديد رقم القاعدة هو تحديد القاعدة نفسها؛ على سبيل المثال، إذا أردت حذف قاعدة «allow http»، فيمكنك كتابة الأمر كما يلي: sudo ufw delete allow http يمكنك أيضًا تحديد القاعدة مستعملًا «allow 80»، بدلًا من اسم الخدمة: sudo ufw delete allow 80 ستَحذُف هذه الطريقة قواعد IPv4 و IPv6 إن كانت موجودةً. كيفية تعطيل UFW (خطوة اختيارية)إذا قررت أنّك لا تريد استعمال UFW لأي سببٍ كان، فيمكنك تعطيله عبر هذا الأمر: sudo ufw disable ستُعطَّل أيّة قواعد أنشَأتها باستخدام UFW، يمكنك بأي وقتٍ تنفيذ: sudo ufw enable إذا احتجت لتفعيله لاحقًا. إعادة ضبط قواعد UFW (خطوة اختيارية)إذا كانت لديك قواعد UFW مضبوطة، لكنك قررت أن تبدأ من الصفر، فيمكنك استخدام الأمر reset: sudo ufw reset سيُعطِِّل الأمر السابق UFW ويحذف أيّة قواعد عرَّفتَها سابقًا. أبقِ في بالك أن السياسات الافتراضية لن يُعاد ضبطها إلى إعداداتها الافتراضية إذا كنت قد عدَّلتها. الخلاصةيجب أن يكون قد ضُبِطَ جدارك الناري للسماح (على الأقل) لاتصالات SSH؛ تأكد أن تسمح لأيّة اتصالات واردة أخرى لخادومك بينما تقيّد أيّة اتصالات غير ضرورية، كي يكون خادومك آمنًا ويعمل عملًا صحيحًا. ترجمة -وبتصرّف- للمقال How To Set Up a Firewall with UFW on Ubuntu 14.04 لصاحبه Mitchell Anicas.

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.

مقدّمة من الممكن أن ننخدع بفكرة أنّ الخوادم لن تُهاجَم ما دام الخادوم جديدا، زواره قلائل أو أنّ المخترقين لن يستفيدوا شيئا من اختراقه. لكنّ العديد من الهجمات تكون مُؤتمتة وتُصمَّمُ خصيصا للبحث عن الأخطاء الشّائعة التي تُرتَكب عند ضبط الخادوم. تقوم هذه البرمجيات بفحص الشبكات لاكتشاف الخوادم فقط، ولا تكثرت بمحتواها. تمكين الاتصالات الخارجيّة من أكثر الحالات الشّائعة التي قد تُؤدي إلى وصول غير مُصرّح إلى قاعدة بيانات PostgreSQL. يُمكن أن يحدث هذا لأنّ الإعدادات تسمح للبرمجيات باستكشاف الخوادم الضعيفة بسهولة. في هذا الدّرس، سنلقي نظرة على كيفيّة تقليل خطر الوصول غير المُصرّح الذي يطرحه تفعيل الاتّصالات البعيدة (remote connections). ورغم أنّ هذه خطوة أولى بغاية الأهميّة، وبما أنّ الخوادم قد تتعرّض للاختراق بطرق أخرى، فإنّنا ننصح باتّخاذ إجراءات إضافيّة لحماية بياناتك، والتي يُمكنك أن تجدها في جزء "إجراءات إضافيّة لمزيد من الحماية” من هذا الدّرس. الوضعيّة لفهم الخطر الذي نحاول تخفيفه، تخيّل الخادوم على أنّه متجر صغير. إن كان المتجر يُنصت (listening) على أي منفذ (port)، فهذا يُكافئ قلب لافتة تُشير إلى أنّ المتجر "مفتوح”. أي أنّ الخادوم يكون مرئيّا على الشّبكة، ما يُمكّن البرمجيات المؤتمتة من إيجاده. يُمكننا أن نتخيّل بأنّ كلّ منفذ عبارة عن طريقة للدّخول إلى المتجر، مثل باب أو نافذة مثلا. يُمكن لهذه المداخل أن تكون مفتوحة، مُغلقة، مُقفلة أو مُعطّلة حسب حالة البرمجيّة التي تقوم بالإنصات، لكنّ الإنصات على واجهة عامّة يعني بأنّ البرمجيات الخبيثة تستطيع مُحاولة الدّخول. فمثلا، يُمكن أن تُحاول البرمجيّة استعمال كلمة مرور افتراضيّة على أمل أنّها لم تتغيّر. يُمكن لها كذلك استغلال ثغرات أمنيّة موجودة في البرنامج الذي يُنصِتُ على أمل أنّها لم تُصلَح بعد. يُمكن مُحاولة العديد من الأساليب، إن تمكّنت البرمجيّة الخبيثة من إيجاد نقطة ضعف وقامت باستغلالها، فهذا يعني بأنّ الوصول إلى الخادوم سيتمّ بنجاح وسيتمكّن الهجوم من تخليف خسائر كبيرة. إن قُمنا بتقييد عفريت (daemon) معيّن مثل postgresql ليُنصت محليّا فقط، فهذا مُشابه لمحو الباب الذي يوصل إلى الخارج. ولن يُمكن مُحاولة أي شيء آخر للوصول إلى Postgres. تحمي الجدران النّاريّة (Firewalls) وشبكات VPN بطريقة مُشابهة. في هذا الدّرس، سنُركّز على حذف الباب العمومي الذي يوصل إلى PostgreSQL. لحماية العفريت أو البيانات أثناء نقلها أو تخزينها، انظر فقرة "إجراءات إضافيّة لمزيد من الحماية” من هذا الدّرس. المُتطلّبات سنستعمل في هذا الدّرس خادومي Ubuntu، الأول لمُضيف قاعدة البيانات والآخر ليعمل كعميل يتّصل بالمُضيف عن بُعد. يجب على كلّ خادوم أن يُجهَّز بمُستخدم sudo وجدار ناري مُفعّل. يُمكنك الاستعانة بدرس الإعداد البدئي لخادوم Ubuntu. مُضيف قاعدة البيانات PostgreSQL (Ubuntu 16.04) إن لم تقم بتنصيب PostgreSQL بعد، يُمكنك القيام بذلك باستخدام الأوامر التّاليّة: sudo apt-get update sudo apt-get install postgresql postgresql-contrib آلة العميل (Ubuntu 16.04) لاختبار تمكين الاتصالات البعيدة، سنستعمل عميل PostgreSQL psql. لتنصيبها، استعمل الأوامر التّاليّة: sudo apt-get update sudo apt-get install postgresql-client عند استيفاء هذه المُتطلبات، ستكون جاهزا لاتّباع هذا الدّرس. فهم الإعداد الافتراضيّ عند تنصيب PostgreSQL من مستودع حزم Ubuntu، فالخيار الافتراضيّ هو الانصات على المُضيف المحليّ (localhost). يُمكن تغيير هذا الخيار الافتراضي عبر تعديل مقطع listen_addresses على ملفّ postgresql.conf، لكنّ هذا الإعداد الافتراضي يمنع الخادوم من الانصات آليّا على واجهة عموميّة (public interface). علاوة على ما سبق، فالملفّ pg_hba.conf لا يسمح سوى لاتّصالات من مقابس أسماء نطاقات Unix/Linux (Unix/Linux domain sockets)، وعنوان الاسترجاع (loopback address) الخاصّ بالخادوم المحلي، ما يعني بأنّ الاتّصالات من مُضيفات خارجيّة لن تُقبَل: # Put your actual configuration here # ---------------------------------- # # If you want to allow non-local connections, you need to add more # "host" records. In that case you will also need to make PostgreSQL # listen on a non-local interface via the listen_addresses # configuration parameter, or via the -i or -h command line switches. # DO NOT DISABLE! # If you change this first entry you will need to make sure that the # database superuser can access the database using some other method. # Noninteractive access to all databases is required during automatic # maintenance (custom daily cronjobs, replication, and similar tasks). # # Database administrative login by Unix domain socket local all postgres peer # TYPE DATABASE USER ADDRESS METHOD # "local" is for Unix domain socket connections only local all all peer # IPv4 local connections: host all all 127.0.0.1/32 md5 # IPv6 local connections: host all all ::1/128 md5 هذه الإعدادات الافتراضيّة تُحقّق هدف منع الانصات على واجهة عموميّة. إن تركناها على حالها وأبقينا الجدار النّاري مُفعّلا، فهذا كلّ ما في الأمر! يُمكننا الآن الانتقال إلى قسم "إجراءات إضافيّة لمزيد من الحماية” للتّعرف على كيفيّة حماية البيانات أثناء نقلها. إن أردت الاتصال من مُضيف بعيد، فسنتطرّق إلى كيفيّة تعديل الإعدادات الافتراضيّة إضافة إلى الخطوات التي يجب اتّخاذها فورا لحماية الخادوم في الفقرة التّاليّة. إعداد الاتّصالات البعيدة (Remote Connections) لإعداد بيئة إنتاج قويّة، وقبل بدء العمل مع بيانات حسّاسة، من المُفضّل تشفير مرور (traffic) PostgreSQL باستخدام SSL، إضافة إلى حماية باستخدام جدار ناري خارجي أو شبكة افتراضيّة خاصّة (VPN). قبل القيام بالأمور السابقة ذكرها، يُمكننا اتّخاذ طريق أقل تعقيدا عبر تفعيل جدار ناريّ على خادوم قاعدة البيانات الخاص بنا وتقييد الوصول لتقبل فقط المُضيفات التي تحتاج إلى الوصول إلى الخادوم. الخطوة الأولى – إضافة مُستخدم وقاعدة بيانات سنبدأ بإضافة مُستخدم وقاعدة بيانات لأغراض تجريبيّة. للقيام بذلك، سنستعمل عميل PostgreSQL psql للاتصال بصفة المُستخدم الإداري postgres. عبر تمرير الخيار -i للأمر sudo سيتمّ تشغيل صدفة تسجيل الدّخول (login shell) الخاصّة بالمُستخدم postgres، ما يضمن بأنّ الخيارات في ملفّ .profile أو في موارد أخرى مُتعلّقة بتسجيل الدّخول ستُحمَّل. يقوم الخيار -u بتحديد المُستخدم postgres: sudo -i -u postgres psql بعدها، سنقوم بإنشاء مُستخدم بكلمة مرور. تأكّد من استعمال كلمة مرور جيّدة عوضا عن المقطع mypassword في المثال أسفله: CREATE USER sammy WITH PASSWORD 'mypassword'; إن تمّ إنشاء المُستخدم بنجاح، فسنستقبل المُخرج التّالي: CREATE ROLE مُلاحظة: منذ الإصدار 8.1 من PostgreSQL، فالأدوار (ROLES) والمُستخدمون (USERS) يشتركون في المعنى.لكنّ هناك اتّفاقا يقول بأنّه إن كان لدور كلمة مرور فإنّنا نُسمّيه مُستخدما، ونُسمّي الدّور عديم كلمة المرور دورا، لذا أحيانا ستحصل على ROLE في المُخرج رغم أنّك تتوقّع أن ترى USER. تاليّاََ، سنُنشئ قاعدة بيانات وسنمنح كامل صلاحيّات الوصول لمُستخدمنا الجديد. تقول أفضل الممارسات بمنح المُستخدمين صلاحيّات الوصول التي يجتاجونها فقط، وعلى الموارد التي يجب أن يحصلوا عليها فقط، لذا فاعتمادا على حالة الاستخدام ( use case)، قد يُفضّل تقييد أحقيّة الوصول للمُستخدم. . CREATE DATABASE sammydb OWNER sammy; عند إنشاء قاعدة البيانات بنجاح، سنستقبل التّأكيد التّالي: CREATE DATABASE بعد إنشاء المُستخدم وقاعدة البيانات، سنقوم بالخروج من سطر أوامر PostgreSQL: \q بعد الضغط على مفتاح ENTER، سنرجع إلى سطر الأوامر وسنكون جاهزين للمُتابعة. الخطورة الثّانيّة – إعداد UFW في درس الإعداد البدئي لخادوم Ubuntu ، قمنا بتفعيل UFW وسمحنا لاتّصالات SSH فقط. قبل بدء الإعداد، لنتحقّق من حالة UFW: sudo ufw status مُلاحظة: إن كان المخرج يدُلّ على أنّ الجدار النّاري غير مُفعّل (inactive)، يُمكننا تفعيله بالأمر التّالي: sudo ufw enable بعد التّفعيل، فإنّ إعادة تنفيذ الأمر sudo ufw status سيستعرض القواعد الحاليّة. فعّل SSH إن كان ذلك مطلوبا: sudo ufw allow OpenSSH في حالة لم تُغيِّر من المُتطلّبات، فمُخرج الأمر sudo ufw status سيُشير إلى أنّ OpenSSH هي الخدمة الوحيدة المُفعّلة: Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) بعد التّحقّق من حالة الجدار النّاري، سنقوم بالسماح بالوصول إلى منفذ PostgreSQL وسنُقيّد الوصول لنسمح فقط للمُضيف أو المُضيفات المرغوبة. سيُضيف الأمر أسفله قاعدة للمنفذ الافتراضيّ لـPostgreSQL، أي المنفذ رقم 5432. إن غيّرت هذا المنفذ، فتأكّد من تعديل الأمر أسفله. تأكّد من استعمال عنوان IP الخاص بالخادوم الذي يحتاج إلى الوصول. أعد تنفيذ الأمر لإضافة كلّ عميل من العملاء الذين ترغب بإعطائهم أحقيّة الوصول إن كان ذلك لازما: sudo ufw allow from client_ip_address to any port 5432 استبدل client_ip_address بعنوان IP الخاصّ بالعميل. للتّحقّق من أنّ القاعدة قد طُبِّقت، يُمكنك تنفيذ الأمر ufw status مُجدّدا: sudo ufw status المُخرج: To Action From -- ------ ---- OpenSSH ALLOW Anywhere 5432 ALLOW client_ip_address OpenSSH (v6) ALLOW Anywhere (v6) مُلاحظة: إن لم تكن لديك دراية مُسبقة بأساسيّات UFW، يُمكنك تعلّم المزيد في درس أساسيات UFW: قواعد وأوامر شائعة للجدار الناري . بعد تجهيز قاعدة الجدار النّاريّ هذه، سنقوم الآن بإعداد PostgreSQL لتُنصت على عنوان IP العمومي. سنقوم بهذا عبر تعديل إعدادَيْن، خانة للمُضيف المُتصل في pg_hba.conf وإعداد listen_addresses في postgresql.conf. الخطوة الثّالثة – إعداد المُضيفات المسموح لها (Allowed Hosts) سنبدأ عبر إضافة خانة المُضيف في ملفّ pg_hba.conf. إن كنت تستعمل نسخة أخرى غيْرَ النُّسخةِ 9.5 من PostgreSQL فتأكّد من تعديل الأمر أسفله قبل تنفيذه: sudo nano /etc/postgresql/9.5/main/pg_hba.conf سنضع أسطر host تحت مقطع التّعليقات الذي يصف كيفيّة السّماح للاتصالات غير المحليّة. سنُضيف سطرا يحمل العنوان العمومي الخاص بخادوم قاعدة البيانات لاختبار ما إذا كان الجدار النّاري مُعدّا بشكل صحيح. استبدل المقطع client_ip_address بعنوان IP الخاص بآلة العميل الخاصّ بك: # If you want to allow non-local connections, you need to add more # "host" records. In that case you will also need to make PostgreSQL # listen on a non-local interface via the listen_addresses # configuration parameter, or via the -i or -h command line switches. host sammydb sammy client_ip_address/32 md5 قبل حفظ التغييرات، لننظر إلى كل قيمة من قيم السّطر الذي أضفناه في حالة كنت ترغب تعديل أي منها: المُضيف، المُعامل host يُحدّد بأنّ اتّصال TCP/IP سيُستَعمَل. قاعدة البيانات، العمود الثّاني، sammydb، يُحدّد أي قاعدة بيانات يُمكن للمُضيف أن يتّصل بها، يُمكنك تعيين أكثر من قاعدة بيانات واحدة عبر تفرقة أسمائها بالفاصلة ,. المُستخدم، sammy، يُحدّد المُستخدم المسموح له بالاتّصال. وكما مع عمود قاعدة البيانات، فتستطيع تحديد أكثر من مستخدم واحد باستعمال علامة الفاصلة. العنوان، يُحدّد عنوان آلة العميل ويُمكن أن يكون عبارة عن اسم مُضيف (hostname)، مجال عناوين IP (IP address range) أو كلمات مفتاحيّة خاصّة. في المثال أعلاه، قمنا بالسماح لعنوان IP الخاصّ بالعميل فقط. طريقة الاستيثاق (auth-method)، في الأخير، يُمكن تحديد طريقة استيثاق، يُشير md5 إلى كلمة مرور مزدوجة التّشفير بـMD5 ( double-MD5-hashed password ) لن تحتاج سوى كلمة المرور التي تم إنشاؤها للمُستخدم الذي سيقوم بالاتّصال. للمزيد من المعلومات وإعدادات إضافيّة راجع التوثيق الرّسمي لـPostgreSQL حول ملفّ pg_hba.conf. بعد الانتهاء من التّعديلات، احفظ وأغلق الملف. الخطوة الرّابعة – إعداد عنوان الإنصات (Listening Address) سنقوم الآن بضبط عنوان الإنصات في ملفّ postgresql.conf (تأكّد من تصحيح رقم النّسخة): sudo nano /etc/postgresql/9.5/main/postgresql.conf أضف عناوين الإنصات تحت سطر listen_addresses، تأكّد من استبدال server_ip_address بعنوان IP أو اسم مُضيف قاعدة البيانات الخاصّة بك وليس عنوان العميل الذي سيقوم بالاتصال: #listen_addresses = 'localhost' # what IP address(es) to listen on; listen_addresses = 'localhost,server_ip_address' احفظ وأغلق الملفّ عند الانتهاء من إجراء التّعديلات. الخطوة الخامسة – إعادة تشغيل PostgreSQL لن تُطبَّق التعديلات حتى نُعيد تشغيل عفريت (daemon) PostgreSQL، لذا سنقوم بهذا قبل أن نبدأ بالتجربة: sudo systemctl restart postgresql وبما أنّ systemctl لا يوفّر تغذيّة راجعة (feedback)، فسنتحقّق من نجاح إعادة تشغيل العفريت: sudo systemctl status postgresql إن احتوى المُخرج على Active: active وانتهى بمقطع مُشابه لما يلي، فهذا يعني بأنّ عفريتPostgreSQL مُفعّل. ... Jan 10 23:02:20 PostgreSQL systemd[1]: Started PostgreSQL RDBMS. بعد إعادة تشغيل العفريت، يُمكننا الآن التّجربة. الخطوة السّادسة – تجربة الاتّصال لنتحقّق من أنّنا نستطيع الاتّصال من جهاز العميل الخاص بنا. للقيام بهذا، سنستعمل الأمر psql مع الخيّار -U لتحديد المُستخدم، الخيار -h لتحديد عنوان IP الخاصّ بالعميل و -d لتحديد قاعدة البيانات، وذلك لأنّنا ضيّقنا الحماية لكي يتمكّن sammy فقط من الاتّصال بقاعدة بيانات واحدة فقط. psql -U sammy -h postgres_host_ip -d sammydb استبدل postgres_host_ip بعنوان IP الخاصّ بمُضيف PostgreSQL. إن تمّ إعداد كل شيء بشكل صحيح، فيجب أن تستقبل المحثَّ (prompt) التّالي: Password for user sammy: أدخل كلمة المرور التّي حدّدتها مسبقا عندما أضفت المُستخدم sammy في مرقاب (monitor) PostgreSQL. إن حصلت على المحثّ التّالي، فهذا يعني بأنّ الاتصال قد تمّ بنجاح: sammydb=> هذا يُؤكّد على أنّنا نستطيع تجاوز الجدار النّاري وأن نتّصل بقاعدة البيانات. سنقوم الآن بالخروج من المحثّ: \q بعد التّحقّق من أنّ الإعدادات قد ضُبِطت بنجاح، سنقوم بتنظيف مُخلّفات التّجربة. الخطوة السّابعة – حذف قاعدة البيانات والمُستخدم التّجريبيّين بعد اختبار الاتّصال، يُمكننا الآن العودة إلى المُضيف واستخدام الأمر التّالي لحذف قاعدة البيانات والمُستخدم. sudo -i -u postgres psql لحذف قاعدة البيانات: DROP DATABASE sammydb; عند نجاح العمليّة، ستستقبل المُخرج التّالي: DROP DATABASE لحذف المُستخدم: DROP USER sammy; المُخرج عند نجاح العمليّة: DROP ROLE سنقوم بإنهاء عمليّة التّنظيف بحذف خانة المُضيف الخاصّة بقاعدة البيانات sammydb من ملفّ pg_hba.conf لأنّنا لم نعد نحتاج إليها: sudo nano /etc/postgresql/9.5/main/pg_hba.conf استبدل 9.5 برقم النّسخة الخاصّة بك. السّطر الذي يجب عليك حذفه: host sammydb sammy client_ip_address/32 md5 ليُطبَّقَ التّعديل، سنقوم بحفظ وإغلاق الملفّ ومن ثمّ نُعيد تشغيل خادوم قاعدة البيانات: sudo systemctl restart postgresl للتحقّق من أنّ إعادة التّشغيل قد تمّت بنجاح، سنطّلع على الحالة: sudo systemctl status postgres إن كان المُخرج يحتوي على Active: active فهذا يعني بأنّ إعادة التّشغيل قد تمّت بنجاح. يُمكنك الآن ضبط التّطبيق أو الخدمة على العميل التي تحتاج إلى إمكانيّة الاتصال عن بعد. خاتمة اتّخذنا في هذا الدّرس الخطوات الأساسيّة لحماية PostgreSQL عبر إعداد الجدار النّاريّ الخاصّ بالخادوم ليسمح فقط للاتصالات من المُضيفات التي تحتاج إلى صلاحيّات الوصول وعبر ضبط PostgreSQL لتقبل الاتصالات من هذه المُضيفات فقط. هذا يُخفّف من خطر بعض من أنواع الهجمات. تعتبر هذه الإجراءات الخطوة الأولى فقط لحماية البيانات، وننصح بمراجعة واتّخاذ الإجراءات الأمنية الإضافيّة المذكورة أعلاه. ترجمة -بتصرّف- للمقال How To Secure PostgreSQL Against Automated Attacks لصاحبته Melissa Anderson.

تحدثنا في السابق عن بضع خطوات يمكنك تطبيقها لزيادة أمان وحماية موقعك العامل بسكربت ووردبريس الشهير. صحيحٌ أنّ نواة ووردبريس آمنة للغاية، ولكن يجب عليك تثبيت عدّة إضافات وملحقات إضافية لزيادة مستوى أمان موقعك. سنتحدّث في هذا الدرس عن أهم إضافات الأمان والنسخ الاحتياطي التي يمكنك تثبيتها وتفعيلها على سكربت ووردبريس الشهير. لماذا قد أحتاج إضافة للحماية؟ بشكلٍ عام، تقوم إضافات الحماية والأمان بتوفير طبقة إضافية من الحماية ضدّ هجمات Bruteforce والهجمات الأخرى والبرمجيات الخبيثة التي قد تصيب موقعك، يمكنها أيضًا أن توفّر لك عدّة أدوات يمكنك استخدامها لتقليل المخاطر الأمنية المحيطة بك، كما توفّر بعض الأدوات للمراجعات اليدوية الدورية أيضًا. هناك إضافات أخرى للنسخ الاحتياطي تمكّنك من استرجاع موقعك بسرعة في حال ما إذا تمّ اختراقه. لهذا، سنتطرّق الآن إلى أهم الإضافات للحماية والأمان والنسخ الاحتياطي التي يمكنك استخدامها. iThemes Security تعتبر هذه الإضافة شهيرةً جدًا عندما يتعلّق الأمر بمجال أمان ووردبريس. كانت هذه الإضافة تدعى بالسابق "WP Security" ولكن تمّ تغيير اسمها. توفّر لك هذه الإضافة عدّة طرق لحماية موقعك. في الواقع، تقوم إضافة iThemes Security بالعديد من الأمور التي ذكرناها بالدروس السابقة تلقائيًا، مثل تغيير اسم المستخدم الرئيسي ورابط صفحة تسجيل الدخول، إزالة وسم generator والمزيد. كما تعرض عدّة أدوات للحماية مثل فحوصاتٍ دورية لملفّات موقعك للبحث عن الثغرات الأمنية والملفّات الخبيثة إن وجدت، مما يحسّن من أمان موقعك، كما أنّها تقوم بحظر المستخدمين الذين يفشلون بتسجيل الدخول لأكثر من مرّة عن طريق الـIP، وتحظر ربوتات الاختراق الشهيرة، وتفرض على المستخدمين اختيار كلمات مرورٍ قويّة.. والمزيد. توفّر إضافة iThemes Security ميزات التنبيه، حيث يمكنها أن تقوم بتنبيهك عندما يتم إجراء تغييراتٍ ما دون صلاحيات. يمكنها أن تلتقط الروبوتات التي تحاول اختراقك ويمكنها أن ترسل رسالة بريدٍ إلكتروني في حال التقطت أيًّا منها. توفّر الإضافة ميّزة النسخ الاحتياطي كذلك، حيث أنّها قادرة على أخذ نسخة احتياطية من جميع ملفّات موقعك وتدويناتك التي نشرتها، ويمكنها استعادتها في أيّ وقتٍ تريده. هناك إصدارٌ مدفوع من الإضافة كذلك ويوفّر ميّزاتٍ أكثر. All in One WP Security & Firewall خيارٌ آخر متوفّر أمامك هو إضافة All in One WP Security & Firewall، تتميز هذه الإضافة بسهولة تثبيتها وإعدادها مما يجعلها خيارًا جيَدًا للمدونين الجدد. تتضمن أيضًا نظام تقييم للحماية يحدد لك مدى أمان موقعك بوضعه الحالي. يمكنك من هناك تفعيل أو تعطيل مميزاتٍ معيّنة للأمان والحماية في موقعك حسبما تريده. تسمح لك هذه الإضافة المجانية كذلك بإعداد العديد من إجراءات الحماية بمجرّد بضع ضغطات، مثل تغيير اسم المستخدم "admin"، التعرّف على المستخدمين الذين يمتلكون أكثر من حساب وتفعيل أداة تقوية كلمات المرور. كما تحتوي الإضافة على ميزة تمنع هجمات Bruteforce على موقعك عبر حظر محاولات تسجيل الدخول الفاشلة لأكثر من مرّة. يمكنك أيضًا فرض تسجيل الخروج على حسابٍ معيّن، تتبع سجل النشاط الخاصّ به والمزيد. تتضمن الإضافة أيضًا مزايا حماية قواعد البيانات والملفّات، بالإضافة إلى إمكانية إنشاء ملفّ htaccess. عبرها وعمل النسخ الاحتياطية لملفّ wp-config.php. هناك ميزة أخرى مهمّة بهذه الإضافة وهي ميّزة الجدار الناري، حيث تسمح لك بتعديل ملفّ htaccess. لتمنع المخترقين حتّى من الوصول إلى الشفرة الخاصّة بموقعك. كما أنّها تحتوي على فاحص ملفّات، الحماية من نسخ النصوص، حماية ضد هجمات السخام (Spam)، تحديثات تلقائية والمزيد. Sucuri Security Sucuri Security هي إضافة أخرى شائعة لحماية ووردبريس. تسمح لك ميزة SiteCheck المُضمّنة بالتحقق من حالة موقعك الحالية وفحصه لإيجاد الثغرات الموجودة به بالإضافة للبحث عن البرمجيات الخبيثة إن وجدت. تمكّنك الميزة كذلك من البحث عن جميع أنواع الثغرات، مثل ثغرات حقن قواعد البيانات، محاولات التصيّد الاحتيالي، إعادة التوجيه المشبوهة.. إلخ، كما يمكنها أن تلتقط أكواد جافاسكربت وPHP الخبيثة إن وجدت. تستخدم الإضافة أكثر من واجهة تطبيق برمجية واحدة (API) لفحص موقعك، أيّ أنّها تستخدم أكثر من قاعدة بيانات للشفرات الضارّة والخبيثة الموجودة على الإنترنت للتأكد من أنّ موقعك لا يحتوي على أحدها، مما يوفّر فحصًا شاملًا لموقعك، تتضمن هذه المصادر الخارجية أسماءً عريقة مثل Norton, McAfee.. إلخ. هناك بعض المزايا الموجودة بالإضافة والتي توفّر الحماية لمسار رفع ملفّات الوسائط الخاصّ بموقعك، حيث تقيّد الوصول إلى مجلّديّ wp-content وwp-includes، تتحقق من إصدارات PHP ووردبريس وتعطّل محرر الإضافات والقوالب من لوحة التحكم. Wordfence Security تحدّثنا من قبل عن إضافة Wordfence Security، وقلنا أنّها من أهم إضافات الحماية لسكربت ووردبريس. بمجرّد تثبيتها على موقعك فإنّها ستقوم بعملية فحصٍ شامل للشفرة المصدرية للتأكّد من أنّها مطابقة للشفرة المصدرية الخامّة المنشورة من موقع ووردبريس الرئيسي، إذا اكتمل الفحص بنجاح، فإنّ الإضافة تقوم بعدها تلقائيا بتفعيل خيارات الحماية لزيادة أمان موقعك. هناك إصدار مدفوع ومجاني من الإضافة، كلاهما يعتمدان على منصّة "Wordfence Cloud"، مما يعني أنّ عملية الفحص وتفعيل الجدار الناري بالواقع تجريان على خواديم الشركة المطوّرة للاستضافة وليس على خادومك مما يقلل من الحمل الموجود عليه. توفّر هذه الإضافة دعمًا لأكثر من موقع ووردبريس في آنٍ واحد، تسجيل الدخول عبر الهاتف المحمول، دعم للإضافات الشهيرة مثل WooCommerce، الاستيثاق الثنائي، فرض كلمات المرور القوية، فحص الملفّات والمزيد. تتضمن الإضافة أيضًا جدارًا ناريًا لحماية موقعك من الروبوتات، البرمجيات الخبيثة وهجمات Bruteforce. بمجرّد تثبيتها فإنك ستكون قادرًا على حظر المهاجمين واتصالات الشبكات المشبوهة، وكلّه في الوقت الحقيقي (Real time). BruteProtect تمّ شراؤها مؤخرًا من قبل شركة Automattic (الشركة المطوّرة لووردبريس)، إضافة BruteProtect هي أحد الحلول الأمنية التي يمكنك استخدامها لصدّ هجمات Bruteforce بالتحديد. توفّر الإضافة أدواتٍ لمراقبة الهجمات الحالية على موقعك في حال حصولها بالوقت الحقيقي بالإضافة إلى التحديث التلقائي لنواة ووردبريس في موقعك. الإضافة ليست مجهّزة لحمايتك ضد الهجمات الأخرى، بل فقط ضدّ هجمات Bruteforce فلا تعتمد عليها لوحدها. Acunetix WP Security Acunetix WP Security هي إضافةٌ أخرى مجانية لفحص موقعك بسهولةٍ ويسر. تمكّنك من إعداد صلاحيات الملفّات، تأمين قاعدة البيانات، إخفاء إصدار ووردبريس الحالي الذي تستخدمه عن أعين المخترقين، تغيير اسم المستخدم admin والمزيد. تتوافق الإضافة مع مواقع ووردبريس المتعددة (multisite) وعمليات النسخ الاحتياطي، كما تتضمّن أداةً تعمل بالوقت الحقيقي لعرض من يتصفّح موقعك حاليًا وماذا يتصفّحون. Bulletproof Security آخر إضافة ووردبريس سنتحدث عنها هي إضافة Bulletproof Security. توفّر هذه الإضافة العديد من المزايا التي توفّرها الإضافات الأخرى مثل ملفّات htaccess. ، حفظ نسخة احتياطية من قاعدة البيانات، سمات مختلفة لواجهة الإضافة والمزيد. يتضمّن الإصدار المدفوع منها المزيد من المميزات مثل التثبيت بنقرة واحدة، الاستعادة التلقائية، جدار ناري يتعامل مع عناوين الـIP للمستخدمين، مسجّل للأخطاء، حامٍ من هجمات Bruteforce، حظر عناوين IP معيّنة والمزيد. أهمّية إضافات النسخ الاحتياطي بجانب إضافة قويّة للحماية والأمان، فإنّه يجب عليك استخدام إضافةٍ أخرى لعمليات النسخ الاحتياطي، معظم هذه الإضافات السابق ذكرها يتضمّن الميّزتين بالواقع مما يسهّل عليك الأمر، ولكن لا تنسى بتاتًا استخدام النسخ الاحتياطي. القيام دوريًا بعمل نُسخ احتياطية من موقعك هو أمرٌ مهم لخطّة أمان كاملة، وإلّا فكيف تتوقع أن تقوم باسترجاع موقعك في حال تمّ اختراقه مثلًا؟ هناك العديد من الإضافات الجيّدة للنسخ الاحتياطي مثل VaultPress ،WordPress Backup to Dropbox و BackupBuddy. تتنوّع هذه الإضافات ما بين المدفوعة والمجانية، ولكنّها مفيدة لضمان عدم فقدان أيّ شيء مهم يتعلّق بموقعك. الخاتمة صحيحٌ أنّه يمكنك القيام بالعديد من الأمور يدويًا لتحسين حماية ووردبريس، ولكن استخدام الإضافات قد يوفّر عليك الكثير من الوقت ويوفّر لك الكثير من المميزات، خاصةً لو كنتَ تمتلك أكثر من موقع ووردبريس واحد. الإضافات السابق ذكرها يجب أن تؤدّي المهمّة المطلوبة بالنسبة لك ويمكنك تجريبها جميعًا لتصل إلى أفضلٍ واحدةٍ منها بالنسبة لك. في الدرس الأخير من هذه السلسلة سنتحدث عن أهمية تحديث ووردبريس وإضافاته لزيادة أمان موقعك. ترجمة -وبتصرف- للمقال The WordPress Developer’s Guide to Security: Security & Backup Plugins لصاحبته Brenda Barron.

في الدرس السابق تحدثنا عن طرق تثبيت ووردبريس لأول مرة بأمان. في هذا الدرس، سنتحدّث عن كيفية تأمين موقع ووردبريس بعد تثبيته، سنتحدّث عن أساليب أفضل للحماية فوق مستوى نصائح "اختر كلمة مرور أكثر تعقيدًا" وسنحاول الغوص قليلًا في موضوع أمان ووردبريس. تقييد عمليات تسجيل الدخول واحدٌ من أول الأشياء التي يجب عليك فعلها لتأمين موقع ووردبريس الخاصّ بك هو تقييد عدد المرّات التي يمكن لشخصٍ ما أن يحاول تسجيل الدخول بها إلى الموقع. يحاول العديد من المخترقين القيام بهجمات التخمين أو ما يعرف بـ Bruteforce لمحاولة كسر اسم المستخدم / كلمة المرور الخاصّيَن بك، وحتّى لو لم تنجح هذه الهجمات في اختراق موقعك، فإنّه ستقوم باستهلاك جزء كبير من موارد خادومك وستقوم بوضع حملٍ عليه. عبر تقييد عمليات تسجيل الدخول، يمكنك منع المخترقين من محاولة القيام بهجمات Bruteforce. بمجرّد أن يقوم بمحاولة تخمين كلمة المرور مرتين أو ثلاث، فسيتم حظر عنوان الـIP الخاصّ به. يمكنك القيام بهذا الأمر بسهولة عبر تثبيت إصافة Limit Login Attempts، صحيحٌ أنّه لم يتم تحديثها منذ سنتين ولكنّها تمتلك مميزاتٍ رائعة، ولكن ربّما تودّ تجاهلها حاليًا بسبب انقطاع دعمها عن التحديثات الأمنية. عوضًا عن هذا، فإننا ننصح بإضافة Login Lockdown، تسمح لك هذه الإضافة أيضًا بتقييد عدد مرّات تسجيل الدخول الفاشلة قبل أن يتم حظر عنوان الـIP الخاصّ بالمستخدم الذي يحاول الدخول، كما يمكنك اختيار المدّة التي تريد حظر عنوان الـIP خلالها، ستصبح هجمات Bruteforce أصعب بكثير بعد تثبيت هذه الإضافة وضبطها، لأنّه سيجب على المخترقين استخدام وسيط (Proxy) بعد كلّ 3 محاولات فاشلة لتسجيل الدخول، وسيجب عليهم تغيير ذلك الوسيط آلاف المرّات ليتمكّنوا من تحقيق الهجوم، وهو الأمر الذي لا يتوفّر لديهم غالبًا. حظر المستخدمين الذين يحاولون تسجيل الدخول باسم Admin من المهم ألّا تستخدم اسم "admin" كاسم مدير الموقع على موقعك، ومن المهم أيضًا أن تقوم بحظر كلّ من يحاول الدخول إلى ذلك المستخدم (طالما أنتَ لستَ المدير، والحساب غير موجود، فلماذا تحاول الدخول؟ إذن فأنتَ مُخترِق)، يمكنك القيام بهذا عن طريق إضافة Wordfence. تسمح لك هذه الإضافة بإعداد ميزة الحظر التلقائي هذه، بالطبع، هناك العديد من المميزات الأخرى في هذه الإضافة التي يمكنك استخدامها من أجل الحماية، مثل الاستيثاق الثنائي (two-factor authentication)، حظر الهجمات الشائعة والمزيد. ضبط صلاحيات الملفّات الصحيحة شيءٌ آخر يمكنك فعله هو ضبط صلاحياتٍ مناسبة للملفّات على موقعك. وفقًا لـ WordPress.org، فإنّ استخدام صلاحيات 777 للملفّات / المجلّدات هو أمرٌ خطير للغاية ويسمح للجميع أن يقوموا بتعديل ملفّات موقعك وإضافة أكواد خبيثة أو حتّى حذف الموقع بالكامل. يجب عليك أن تقوم بوضع صلاحيات 600 لملفّ wp-config.php، بينما يجب عليك أن تقوم بتعيين ملفّاتك الأخرى إلى وضع صلاحيات 640 أو 644، كما يجب أن تكون المجلّدات الموجودة على موقعك بالصلاحيات 750 أو 755. يمكنك تعلّم المزيد عن الصلاحيات عبر دليل ووردبريس الرسمي لتغيير الصلاحيات. إنشاء ملف htaccess. إذا كنتَ تريد تركيبة روابط دائمة (permalinks) جميلة لموقعك فإنّك ستحتاج ملفّ htaccess. عبر إضافة واحدٍ إلى موقعك فإنّك ستقوم بتحسين مستوى الحماية قليلًا، صحيحٌ أنّه ليس حلًا كاملًا ولا يمكنه فعل شيء جوهري لوحده ولكنّه إضافة جيّدة. هناك شرح شامل منشور على الويب حول إنشاء ملفّ htaccess. ، لن نقوم بشرح تلك العملية بالكامل هنا لأنّ العملية مشروحة بذاك الدليل بشكلٍ شامل. بمجرّد أن تقوم باتّباع ذاك الشرح فإنّه سيصبح بإمكانك منع الوصول إلى ملفّات معيّنة على موقع ووردبريس الخاصّ بك. إذا لم يكن الناس قادرين على الوصول إلى تلك الملفّات التي تريدها فلن يكونوا قادرين على العبث بها. لزيادة صعوبة اختراق موقع ووردبريس الخاصّ بك ستحتاج إلى إضافة بضع سطور من الأكواد لحظر الوصول إلى ملفّات معينة مثل: wp-config.php readme.html license.txt wp-includes directory يمكنك أيضًا منع الوصول إلى امتدادات معيّنة للملفّات، مثل ملفّات النسخ الاحتياطي، الإعدادات، السجلات المحفوظة على الخادوم.. إلخ. بشكلٍ عام، يجب حظر الوصول إلى أيّ شيء يتعلّق بالتصميم والتطوير والتوثيق الخاصّ بخلفيّة الموقع (back-end). إذا كنتَ تريد حظر الوصول إلى مجلّد إضافة أو قالب معيّن أو مسارٍ آخر على موقعك، فيمكنك حظر المجلّد بأكمله إن أردت. هذه حركة جيّدة للقيام بها في كلّ مجلّد لا يمتلك بداخله ملفّ index. حيث أنّ المجلّدات التي لا تحتوي على ملفّات index ستقوم بعرض كلّ الملفّات الموجودة بداخل ذاك المجلّد، مما يعطي معلوماتٍ هامّة يمكن استغلالها من طرف المخترقين، لذا يجب عليك إخفاؤها. إخفاء صفحة تسجيل الدخول هذا تعديلٌ آخر يمكن القيام به عن طريق htaccess. ولكن مختلف قليلًا عن التعديلات الأخرى ولذلك سنذكره هنا. يمكنك حظر وصول أيّ شخص إلى صفحة تسجيل الدخول الخاصّة بموقعك ومنح حقّ الوصول فقط إلى عنوان الـIP الخاصّ بك، وطبعًا، يجب أن يكون هناك مستخدمٌ واحد فقط للموقع بأكمله، وبالتالي فتلك ليست طريقة عملية حقًا لاستخدامها. إذا كنتَ تريد إبقاء خيارٍ مفتوح لإضافة كتّابٍ ومستخدمين آخرين إلى موقعك لاحقًا، فيمكنك استخدام إضافة Secure Hidden Login. تسمح لك هذه الإضافة بإخفاء حقول الإدخال من صفحة تسجيل الدخول الخاصّة بموقعك، ويتم إظهار حقول الإدخال لاسم المستخدم وكلمة المرور فقط عند الضغط على اختصاراتٍ معيّنة على لوحة المفاتيح، فإن حاول أحدهم فتح صفحة تسجيل الدخول، فلن يتمكّن من ذلك دون أن يعرف ما هي اختصارات لوحة المفاتيح التي تقوم بعرض صفحة تسجيل الدخول. إزالة وسم Generator يقوم المخترقون بكلّ شيءٍ قد يمكّنهم من اختراق موقعك، واحدٌ من هذه الأشياء هو سكربتٌ شهير يستخدمه المخترقون لالتقاط المواقع التي تعمل بإصدارات معيّنة من ووردبريس عبر بصمات الأقدام (Footprints)، بصمات الأقدام هي عبارة عن سطور متعددة من الأكواد يمكن استخدامها للتعرّف على هوية موقع ويب ما، لسوء الحظّ فإن ووردبريس يستخدم هذه البصمات مما يجعل مواقع ووردبريس الموجودة على الشبكة قابلة للاكتشاف بسهولة. قد تبدو بصمة القدم الخاصّة بموقع ووردبريس كشيءٍ مثل: <meta name="generator" content="WordPress 3.8.4" /> يمكنك إزالة هذا الوسم إن أردت من الشفرة المصدرية الخاصّة بموقعك، ولكن ما يزال عليك إضافة الشفرة التالية إلى ملفّ functions.php الخاصّ بقالبك: remove_action('wp_head', 'wp_generator'); بعد هذا، لن يقوم موقع ووردبريس الخاصّ بك بتعريف نفسه على أنّه موقعٌ يعمل بسكربت ووردبريس، مما يصعّب المهمّة على المُخترقِين. تفعيل الاستيثاق الثنائي Two-Step Authentication شيءٌ آخر يمكنك فعله لتأمين موقعك هو تفعيل الاستيثاق الثنائي أو ما يدعى بـ Two-Step Authentication. عندما تقوم بطلب خطوتين للاستيثاق من مستخدمي موقعك عوضًا عن خطوة واحدة فإنّك تصعّب الأمر جدًا على المُخترقِين. هناك عدّة إضافات موجودة لتفعيل الاستيثاق الثنائي على ووردبريس ومن بينها: Clef: بمجرّد تثبيت هذه الإضافة، فإنّ كل ما سيجب عليك فعله هو فتح تطبيق Clef على هاتفك المحمول وتركيز كاميرا الهاتف على شاشة الحاسوب الخاصّة بك، بعدها سيتم فتح القفل الموجود على موقعك وتتمكن من الدخول. Duo Two-Factor Authentication: بعد أن تقوم بإدخال كلمة المرور الخاصّة بك في مربّع الإدخال التقليدي، سيجب عليك إكمال خطوةٍ أخرى لإتمام عملية تسجيل الدخول، مثل تأكيد تسجيل الدخول من على هاتفك الذكي عبر رسالة SMS وغيرها من الطرق. الخاتمة إدارة الحماية على موقع ووردبريس الخاصّ وإعداد عمليات تسجيل الدخول ليتم تقييدها قدر المستطاع هو أمرٌ قد يستغرق منك بعض الوقت، ولكن بمجرّد أن تكتمل هذه الأمور، فإنّ موقعك سيكون أكثر أمانًا لمستخدميه. ترجمة -وبتصرف- للمقال The WordPress Developer’s Guide to Security: Management & Logins لصاحبته Brenda Barron.

سنناقش في هذا الدرس أهمّية تحديث كلّ شيءٍ متعلّق بموقع ووردبريس الخاصّ بك إلى آخر الإصدارات المتوفّرة وأهميّة التحديثات بشكلٍ عام، وهو من أهمّ الأمور التي يمكنك القيام بها لزيادة حماية وأمان موقعك. لماذا نقوم بالتحديث؟ السؤال الحقيقي يجب أن يكون "ولما لا"؟ يقوم مطوروا ووردبريس بإرسال التحديثات إلى المستخدمين لسببٍ معيّن في النهاية، حيث أنّ هذه التحديثات تحتوي على إصلاحاتٍ لثغراتٍ خطيرة يمكن أن يستغلها المهاجمون لمهاجمة موقعك، مما يجعل التحديث ضرورة لا مفرّ منها. أنواع التحديثات قبل أن نتابع، من المهمّ أن نفهم أنواع التحديثات المختلفة المتوفّرة في سكربت ووردبريس. يشير 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.

يُستخدم برنامج وورد لتحرير أنواع كثيرة من النصوص وحفظها بشكل مستندات. وفي بعض الأحيان تكون هذه المستندات سريّة أو تحتوي على معلومات حساسة من ناحية الخصوصية ونرغب في حمايتها بطريقة أو بأخرى. ولهذا الغرض يوفّر وورد عدد من مستويات الحماية للمستندات مثل الحماية بكلمة مرور، تقييد عملية التحرير والتنسيق، أو غيرها. في هذا الدرس سنغطي كيفية حماية المستندات بجعلها للقراءة فقط، تقييد عمليات التحرير والتنسيق من قبل الآخرين، تشفير المستند بكلمة مرور، وحذف البيانات الوصفية metadata في المستند. كيفية جعل المستند للقراءة فقط Read Only يمكنك استخدام هذا الخيار إذا كنت ترغب في مشاركة المستند مع الآخرين وتريد تنبيههم إلى أنّ النسخة الحالية هي للقراءة فقط ولا تريد منهم تعديلها. لتحويل المستند إلى النسخة نهائية، أي نسخة القراءة فقط، اذهب إلى ملف File> معلومات Info> حماية المستند Protect Document> وضع علامة كنهائي Mark as Final: انقر على موافق OK> OK في مربعي الحوار التاليين: سيتم تعليم المستند كـ "نهائي"، أي أنّ تحرير وتنقيح المستند مكتمل وأنّ هذه هي النسخة النهائية منه. عند فتح المستند في المرّة القادمة، سواء من قبلك أو من قبل المستخدمين الآخرين، ستظهر أيقونة في شريط الحالة بالإضافة إلى شريط أصفر الجزء العلوي من الصفحة يشيران إلى أنّ المستند بنسخته النهائية: بالرغم من أنّك قمت بتحويل المستند إلى نسخة القراءة فقط، إلّا أنّ المستخدمين الآخرين يمكنهم تحرير المستند وتنسيقه عند تجاهلهم للرسالة في الشريط العلوي والنقر على زر تحرير على أيّة حال Edit Anyway. فإذا رغبت في تقييد المستخدمين أكثر استخدم الخيار التالي. تقييد التنسيق والتحرير يتيح لك هذا الخيار إمكانية التحكم في نوع التغييرات التي تسمح بإجرائها على المستند من قبل المستخدمين الذي ستشاركه معهم. وهذه الطريقة أكثر تقييدًا من الطريقة السابقة. لتخصيص خيارات تقييد التنسيق والتحرير اذهب إلى ملف File> معلومات Info> حماية المستند Protect Document> تقييد التحرير Restrict Editing: سيُفتح جزء Restrict Editing الذي يحتوي على خيارات تقييد التنسيق وتقييد التحرير كل منهما بشكل منفصل. لمنع المستخدمين الآخرين من إجراء التعديلات على تنسيق النص، قم بتأشير الخيار Limit formatting to a selection of styles ثم انقر على Settings: من مربّع الحوار Formatting Restrictions، أبقِ على الخيار Limit formatting to a selection of styles مؤشرًا ثم انتقل إلى قسم Checked styles are currently allowed. من هذا القسم يمكنك إلغاء تأشير الأنماط التي لا تريد السماح باستخدامها في المستند، وبذلك تحدّ من قدرة المستخدمين الآخرين على تعديل الأنماط أو تعديل تنسيقات النصوص بشكل مباشر بواسطة خيارات التنسيق في تبويب الصفحة الرئيسية Home: إذا كنت تريد تقييد التنسيق فقط اكتف بهذه الخطوة ثم انقر على زر Yes, Start Enforcing Protection. أمّا إذا رغبت في تقييد التحرير أيضًا فقم بتأشير الخيار Allow only this type of editing in the document: من القائمة المنسدلة حدّد نوع الترخيص الذي تريد منحه للمستخدمين: Tracked Changes: للسماح بالتغييرات بشرط تعقّبها. Comments: لمنع التغييرات لكن السماح بإضافة تعليقات على المستند. Filling in forms: للسماح بتعبئة النماذج التي تم إنشاؤها في المستند لكن منع أيّة تعديلات أخرى. No Changes (Read Only): لجعل المستند للقراءة فقط ومنع إجراء أي تعديل عليه. بإمكانك استثناء بعض المستخدمين من التقييد والسماح لهم بتحرير المستند بحرية وذلك بالنقر على More Users: بإمكانك استثناء مستخدم آخر على الجهاز الحالي أو على جهاز ثانٍ تابع لنفس النطاق domain، أو أي مستخدم آخر (بإدخال عنوان بريده الإلكتروني) مع الفصل بين أسماء المستخدمين بفاصلة منقوطة: ستتم إضافة عناوين المستخدمين التي قمت بإدخالها في قسم Individuals، قم بتأشير المستخدم الذي تريد استثناءه، أو تجاهل هذه الخطوة وانتقل إلى الخطوة التالية إذا كنت ترغب في تعميم التقييد. الخطوة الأخيرة هي تطبيق الإعدادات والبدء بفرض الحماية بالنقر على زر Yes, Start Enforcing Protection: سيظهر لك مربّع حوار جديد يمكنك من خلال إدخال كلمة مرور لتفعيل الحماية (أو استخدامها لاحقًا إذا رغبت في إلغاء الحماية). أدخل كلمة المرور مرّتين ثم انقر على OK: سيتم تطبيق التقييد على المستخدمين حسب الإعدادات التي اخترتها. ويمكنك دائمًا إلغاء تقييد التنسيق والتحرير للمستند بالذهاب إلى File> Info> Protect Document> Restrict Editing> Stop Protection: ثم قم بإدخال كلمة المرور نفسها التي أدخلتها عند تفعيل الحماية. تشفير المستند (حمايته بكلمة مرور) التشفير هو أقصى مستويات الأمان التي يمكنك تطبيقها على المستند. ويتم بوضع كلمة مرور للمستند بحيث لا يمكن فتحه وقراءته دون إدخالها. ويمكنك استخدام هذا الخيار إذا كان المستند مهم جدًا أو سرّي ولا تريد من المستخدمين الآخرين فتحه وقراءته. لتشفير المستند اذهب إلى ملف File> معلومات Info> حماية المستند Protect Document> التشفير باستخدام كلمة مرور Encrypt with Password: قم بإدخال كلمة المرور مرّتين، وانتبه إلى أنّه لا يمكن استعادتها مجددًا في حال نسيانها، لذا يُفضّل تدوينها في مكان آمن: في المرّة القادمة التي يحاول فيها أحدهم فتح المستند سيُطلب منه إدخال كلمة المرور أولًا لكي يتمكّن من قراءته: حذف البيانات الوصفية Metadata حذف البيانات الوصفية هو أيضًا من الخيارات المفيدة لحماية معلوماتك الخاصّة عند مشاركة المستندات مع الآخرين. وتشتمل هذه البيانات على المعلومات المخفية في المستند أو معلوماتك الشخصية التي يمكن أن تكون مخزونة في المستند نفسه مثل التعليقات والملفات المضمّنة أو في خصائص المستند مثل اسم الكاتب، اسم آخر مستخدم قام بتعديل المستند، أو غيرها. لحذف هذا النوع من البيانات اذهب إلى ملف File> معلومات Info> البحث عن مشاكل Check for Issues> فحص المستند Inspect Document: بعد ذلك قم بتأشير نوع البيانات التي تريد البحث عنها وانقر على زر Inspect: بعد انتهاء الفحص ستظهر أيقونة علامة تعجّب حمراء أمام البيانات التي تم العثور عليها، ويمكنك إزالة البيانات التي لا تريد الكشف عنها عند مشاركة المستند بالنقر على زر Remove All: خاتمة استعرضنا في هذا الدرس طرق حماية مستندات وورد بعدّة مستويات. ويمكنك اختيار الطريقة المناسبة لمستنداتك التي تريد مشاركتها حسب درجة خصوصية أو سرّية المعلومات التي تحتويها. إذا كان لديك أي سؤال حول حماية مستندات وورد تفضّل بطرحه في التعليقات، وسنكون سعداء بمساعدتك

تُسهِّل برمجية ووردبريس إنشاءَ صفحاتٍ ومنشوراتٍ محميةٍ بكلمة مرور، وهذه ميزةٌ رائعة إذا أردتَ تقييد الوصول إلى محتوى معيّن، لكن المشكلة الوحيدة هي أنَّ أيّة صور أومقاطع فيديو تَعرِضُها في تلك الصفحات ستبقى متاحةً للوصول من صفحات الوسائط المرفقة. يمكن أن يتحول الأمر إلى إشكالية رئيسية إذا كانت تحتوي ملفات الوسائط على معلومات مهمة التي تريد أن تبقى محميةً بكلمة مرور. أحدحلول هذه المشكلة هو إلغاء دعم صفحات الوسائط (attachment pages) في ووردبريس كليًّا، مما يعني أنَّ على زوار موقعك الوصول إلى المنشور (أوالصفحة) المحمي بكلمة مرور لرؤية المحتوى. سننظر في هذا الدرس إلى طريقتين لحل هذه المشكلة.فأولًا سنحلّ المشكلة بإنشاء «قالب ابن» (child theme) وكتابة بعض الشيفرات؛ ثم سنشرح كيف نستخدم إضافةً مجانيةً لفعل ذلك تلقائيًا. متى نخفي صفحات الوسائط؟ لنقل أنك كتبتَ درسًا تعليميًا رائعًا، وكان معروضًا في صفحةٍ وحيدةٍ، وبلغ طوله بضعة آلاف من الكلمات، إضافةً إلى مقطع فيديو أو أكثر، وعدد لا بأس به من الصور التوضيحية. سنفترض أنَّك لا تريد إنشاء متجر لبيع الدورات التعليمية وإنما توفِّر في بعض الأحيان محتوى مدفوع، لذا لن تكون مهتمًا بتثبيت نظام إدارة دورات تعليمية كامل مثلCoursePressPro. حيث اخترتَ حماية الصفحة بكلمة مرور التي ستُرسِلها بطريقةٍ مؤتمتة إلى البريد الإلكتروني للشخص الذي سيدفع لقاء الوصول إلى الدرس. سأفترض أنَّك وجدتَ حلًّا بسيطًا الذي يساعدك في ما سبق دون أن يتطلب جهدًا أو وقتًا طويلًا منك. لكن بعد عدِّة أسابيع أدركتَ وجود مشكلة، حيث شارك أحدهم صورةً من مقالتك على وسائل التواصل الاجتماعي مستعملًا رابط URL لصفحة الوسائط المرفقة، وتلك الصفحة يمكن الوصول إليها مباشرةً دون إدخال كلمة مرور. وما يزيد الطين بلّةً أنَّ القالب الذي تستعمله يُضيف روابط (للصورالتالية والسابقة) إلى صفحة المرفقات مما يسمح للزوار بالتنقل بسهولة بين جميع الصور التي أرفقتها بالمنشور المخفي! حسنًا، دعني أخبرك أنَّ هذه المشكلة سهلة الحل جدًا… إخفاء صفحات المرفقات باستخدام الشيفرات إذا توفر لديك عميل FTP ومحرر نصي، فيمكنك حلّ هذه المشكلة بسرعة عبر إنشاء «قالب ابن». كل ما عليك فعله هو إضافة سطرٌ واحدٌ إلى ملف image.php ويمكنك–اختياريًّا– إضافته إلى ملف video.php. إذا ألقيتَ نظرةً إلى البنية الهيكلية لقوالب ووردبريس فستلاحظ أنَّ أكثر ملف تخصيصًا يمكن إنشاؤه لصفحة المرفقات هو ملفٌ باسم MIME_type.php وهذا يعني أنَّه لو كانت لديك صورٌ ومقاطع فيديو في صفحةٍ محميةٍ بكلمة مرور، فستحتاج إلى إخفاء صفحة المرفقات لكلا النوعين، وستحتاج إلى تعديل ملفٍ مختلفٍ لكل نوع من الوسائط. لنبدأ بملف image.php،لكن قبل أن تبدأ بتعديل أيّة ملفات، فتأكد أنَّك تستعمل «قالب ابن». بعد إنشاء وتفعيل القالب الابن، أنشِئ ملفًا باسم image.php على حاسوبك، وافتحه باستخدام المحرر النصي المفضَّل لديك، وأضف إليه السطر البرمجي الآتي: <?php wp_redirect(get_permalink($post->post_parent)) ; ?> احفظ الملف وأغلقه، ثم ارفعه إلى مجلد الجذر للقالب الابن الذي أنشأتَه منذ قليل. عندما يحاول أحدهم الوصول إلى صفحة المرفقات للصور، فسيتم تحميل ملف image.php وسيؤدي إلى إعادة توجيه المتصفح إلى المنشور المرتبط بتلك الصورة، وهذا هو السلوك الذي نرغب به؛ فأيُّ شخصٍ يحاول الوصول إلى صفحة المرفقات الخاصة بالصور التابعة للمنشور المحمي بكلمة المرور سيُعاد توجيهه إلى الصفحة المحمية بكملة المرور، وعليه عندئذٍ إدخال كلمة المرور للوصول إلى تلك الصفحة. لإضافة حماية إلى صفحات المرفقات الخاصة بمقاطع الفيديو، أنشِئ ملفًا باسم video.php وأضف إليه نفس السطر السابق. هذاحلٌ بسيطٌ جدًا لإخفاء صفحات المرفقات باستخدام الشيفرات؛ لكن إذا كنتَ تُفضِّل إتمام الأمر دون استعمال محرر نصي وعميلFTP، فأود أن أبشِّرَك بوجود حلٍ آخر… إخفاء صفحات المرفقات باستخدام إضافة إذا أردتَ تفادي إنشاء قالب ابن وكتابة (أونسخ ولصق) السطر البرمجي السابق، فيمكنك استخدام إضافة لإعادة توجيه كل صفحات المرفقات. إضافة AttachmentPages Redirect هي إضافةٌ مجانيةٌ متاحةٌ على WordPress.org التي تؤدي الغرض الواضح من اسمها: إعادة توجيه جميع صفحات المرفقات إلى صفحة المنشور الأصلي الموجودةُ فيه (إعادة توجيه دائمة 301)،أو إلى الصفحة الرئيسية (إعادة توجيه مؤقتة 302) إذا لم تكن تلك الوسائط مرفقةً إلى أحد المنشورات. هنالك أكثر من 10000 موقع يستعمل هذه الإضافة، ولها تقييم 4.7 من 5 نجوم. للبدء باستخدام إضافة Attachment Pages Redirect اذهب إلى«Plugins > Add New» (الإضافات> أضف جديد) في لوحة تحكم ووردبريس وابحث عن العبارة «Attachment Pages Redirect»، ثم اضغط Install (تثبيت) ثم Activate (تفعيل). لا تحتاج إلى ضبط أيّ شيءٍ آخر. افتح متصفحك وحاول عرض صفحة أحد المرفقات،وستجد أنَّه قد تمت إعادة توجيهك إلى صفحة المنشور الأصلي أو إلى الصفحة الرئيسية للموقع. لا تظن أنَّ هنالك حماية كاملة لمرفقاتك لا تضمن الطريقتان اللتان شرحناهما في هذا الدرس أنَّ الزوار يجب أن يستعملوا كلمة مرور للوصول إلى الصور أو مقاطع الفيديو التي تُضيفها إلى منشوراتك المحمية؛ لكن دعني أوضِّح لك أنَّه لا توجد أيّة طريقة لحماية المرفقات حمايةً تامةً. فمثلًا، يستطيع المستخدمون الذين يملكون وصولًا إلى المرفقات (عبر إدخالهم لكلمة مرور صحيحة) أن ينسخوا محتواك بكل سهولة عبر: تفحص شيفرة الصفحة المصدرية والعثور على روابط URL مباشرة لملفات الوسائط أو عبر استخدام برمجيات لأخذ لقطات شاشة للصور أو تسجيل محتوى الفيديو عند تشغيله. هنالك خطواتٌ إضافية يمكنها التصدي لهذه المحاولات مثل إعادة التوجيه من طرف الخادوم (sever-level redirects) مما يمنع الوصول المباشر إلى ملفات الوسائط،وعبر استخدام JavaScript لمنع نسخ محتواك. لكن إذا كان المستخدم عاكفًا على نسخ مقالتك والوصول إلى ملفات الوسائط، فسيجد طريقةً للالتفاف على وسائل الوقاية التي استعملتها. في النهاية، أريد أن أُذكِّرك أنَّه لا توجد طريقةٌ لحماية ملفات الوسائط، ففي اللحظة التي تسمح بها لأيّ شخص بالوصول إليها،فلن تستطيع الاحتفاظ بالقدرة على التحكم بالمحتوى، لذا أبقِ هذا في بالك في كل مرة تُضيف فيها المحتوى في موقعك، حتى لو كنتَ «تحمي»المنشورات عبر كلمة مرور (يجب أن تكون مدركًا بعد قراءتك لما سبق أنَّه لا توجد حماية مطلقة للمحتوى). إذا لم تكن تريد رؤية الصور أو مقاطع الفيديو التي ترفعها إلى موقعك مسروقةً ومنشورةً في أحد المنتديات، فلا ترفعها إلى موقعك من الأساس. الخلاصة الميزة المُضمَّنة في ووردبريس لحماية المنشورات بكلمة مرور تُسهِّل من إنشاء محتوى خاص ومحمي، لكنها لا تحمي المرفقات والوسائط المُضافة إلى الصفحات والمنشورات التي لا تستطيع الوصول إليها إلا بكلمة مرور. الحل بسيطٌ جدًا. إذ يمكنك إعادة توجيه صفحات المرفقات إلى المنشور الأصلي الذي أُرفِقَت الوسائط به عبر سطرٍ برمجيٍ وحيد، وإذا لم تكن تريد أن تُضيع وقتك بكتابة ذاك السطر، فإضافة Attachment Pages Redirect ستساعدك في ذلك. ترجمة-وبتصرّف-للمقال [Howto Hide Media Attachment Pages in WordPress] لصاحبهJon Penland

إحدى أبسط الطرق لزيادة حماية موقعك هي عن طريق اختيار اسم مخصص لحساب مدير ووردبريس (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

يُعدّ Nginx خادوم ويب مفتوح المصدر يتسّم بالسرعة والاعتمادية، كسب شعبيّته نتيجة حجم الذاكرة القليل الذي يستهلكه، وقابليته الكبيرة للتوسعة، وسهولة إعداده، ودعمه لمعظم البروتوكولات المختلفة. ويعتبر بروتوكول HTTP/2 الجديد نسبيًا أحد البروتوكولات التي يدعمها خادوم Nginx، الأمر الذي تم منذ أقل من عام مضى، وتعتبر الميّزة الرئيسية في HTTP/2 هي سرعة نقله العالية للمحتويات الغنيّة بالمعلومات في مواقع الويب. سيساعد المقال على تثبيت وإعداد خادوم Nginx سريع وآمن مع دعم لبروتوكول HTTP/2. المتطلبات الأولية قبل أن نبدأ، سنحتاج للأمور التالية: نظام تشغيل Ubuntu 14.04، مستخدم عادي بدون صلاحيات مدير نظام، لكنّه يملك صلاحية تنفيذ أمر sudo. يمكن مراجعة الإعداد الابتدائي لخادوم أوبونتو 14.04 لمزيد من المعلومات، نطاق موقع، ويمكن شراء واحد من موقع Namecheap أو الحصول على واحد مجانًا من موقع Freenom، تأكّد من أنّ النطاق يشير إلى عنوان نظام التشغيل الذي ستستخدمه عبر الإنترنت، وستساعدك مقالة إعداد اسم مضيف مع DigitalOcean إن احتجت لمساعدة، شهادة SSL رقميّة، ويمكن إنشاء واحدة بشكل يدوي، أو الحصول على واحدة مجانًا من Let’s Encrypt، أو شراء واحدة من مزوّد آخر. هذا كل شيء، فإن كانت لديك جميع المتطلبات المذكورة، فأنت جاهز للبدء. الفرق ما بين HTTP 1.1 و HTTP/2 إن HTTP/2 هو الإصدار الجديد من بروتوكول نقل النصوص الفائقة HTTP، الذي يستخدم على الشبكة العنكبوتية لإيصال محتويات صفحات الويب من الخوادم إلى المتصفّحات، وهو أول تحديث ضخم طرأ على HTTPمنذ حوالي عقدين، حيث تم إطلاق الإصدار HTTP 1.1 عام 1999 حينما كانت الصفحات عبارة عن ملف HTML مستقل مع أنماط CSS ضمنيّة (أي مكتوبة ضمن مستند HTML وليست مستوردة من ملف خارجي). لقد تغيّرت شبكة الإنترنت بشكل متسارع في السنوات الستة عشر الأخيرة، وأصبحنا الآن نواجه صعوبة مع المحدودية التي يفرضها HTTP 1.1، حيث يَحُدّ البروتوكول من سرعة النقل الممكنة لمعظم مواقع الويب الحديثة لأنه يقوم بتحميل أجزاء الصفحة وفق مبدأ الطابور queue (بمعنى أنه يجب أن ينتهي تحميل كل جزء قبل أن يبدأ تحميل الجزء التالي له)، ويحتاج موقع ويب حديث وسطيًّا حوالي 100 طلب ليتم تحميل الصفحة(كل طلب يمثّل صورة، ملف js، ملف css، إلخ). يقوم بروتوكول HTTP/2 بحل هذه المشكلة لأنّه يقوم بتقديم تغييرات جذرية تتمثل في: تحميل جميع الطلبات على التوازي، وليس على التسلسل كما في مبدأ الطابور، ضغط ترويسة HTTP، نقل الصفحات عبر الشبكة بصيغة ثنائية binary، وليس كنصوص text، وهذا أكثر فعالية، قدرة الخادوم الآن على "دفع" البيانات قبل أن يطلبها المستخدم، مما سيحسّن من السرعة للمستخدمين الذين يعانون من بطء في الإرسال. وعلى الرغم من أن بروتوكول HTTP/2 لا يتطلب التشفير، إلا أن مطوّري أشهر متصفّحين، Google Chrome و Mozilla Firefox، صرّحوا بأنه -لدواع أمنيّة- سيتم دعم بروتوكول HTTP/2 في اتصالات HTTPS الآمنة فقط، ولهذا السبب إن قررت تثبيت خواديم تدعم HTTP/2 فيجب عليك الانتقال إلى استخدام HTTPS. الخطوة الأولى: تثبيت الإصدار الأخير من Nginx تم طرح دعم HTTP/2 في إصدار Nginx 1.9.5، ولسوء الحظ فإنّ المستودع الافتراضي في نظام Ubuntu متأخر عن إدراج آخر إصدار ويقوم حاليًّا بتوفير الإصدار 1.4.6. لكن لحسن الحظ فإن مطوّري Nginx لديهم مستودع apt خاص على نظام Ubuntu، حيث بالإمكان الحصول دومًا على آخر إصدار متوفّر. لإضافة المستودع الخاص إلى قائمة مستودعات apt لدينا، نحتاج أولًا للحصول على مفتاح التوقيع الرقمي الخاص بالمستودع، وهذا إجراء أمني يضمن بأن الحزم البرمجية التي سنحصل عليها من هذا المستودع صادرة عن المطوّرين الحقيقين وموقّعة منهم. سنقوم بتنفيذ الأمر التالي في سطر الأوامر: $ wget -qO - http://nginx.org/keys/nginx_signing.key | sudo apt-key add - بعد ذلك، سنقوم بإضافة المستودع إلى قائمة مصادر الحزم البرمجية، بتنفيذ الأمر التالي: $ sudo echo -e "deb http://nginx.org/packages/mainline/ubuntu/ `lsb_release -cs` nginx\ndeb-src http://nginx.org/packages/mainline/ubuntu/ `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list الآن وبعد أن أصبح نظام الحزم (الذي يدعى apt في نظامي Ubuntu و Debian) يعلم عن توفّر المستودع الجديد، سنقوم بتحديث قائمة الحزم البرمجية المتوفّرة وأخيرًا سنقوم بتثبيت الإصدار الأخير من Nginx: $ sudo apt-get update $ sudo apt-get install nginx ويمكن التحقق من رقم الإصدار بتنفيذ الأمر: $ sudo nginx -v حيث ينبغي أن يكون الخرج مشابهًا لـ nginx version: nginx/1.9.x. سنقوم في الخطوات التالية بتغيير الإعدادات الافتراضية في Nginx ليقوم بتخديم موقع الويب الخاص بنا. الخطوة الثانية: تغيير منفذ التنصّت الافتراضي سنقوم أولًا بتغيير رقم المنفذ من 80 إلى 443، وذلك بفتح ملف الإعدادات: $ sudo nano /etc/nginx/conf.d/default.conf ملاحظة: في حال ظهر خطأ يخبرك بأنه لم يتم التعرّف على الأمر nano، فتأكّد من تثبيت محرر النصوص nano وحاول مجدّدًا. ينبغي أن نخبر Nginx برقم المنفذ الذي يجب عليه تلقّي الاتصالات عبره، وهو المنفذ 80 افتراضيًا، المنفذ القياسي في بروتوكول HTTP. سنبحث في ملف الإعدادات عن السطر التالي: listen 80; سنقوم بتغيير المنفذ إلى 443 لأن HTTP/2 لن يعمل مع معظم المستخدمين إذا بقي يقوم بإرسال البيانات عبر المنفذ 80، كما أشرنا سابقًا إلى أنه مدعوم فقط عبر المنفذ 443 على متصفحات Chrome و Firefox.سنستبدل السطر السابق بـ: listen 443 ssl http2; لاحظ أننا أضفنا كلمة ssl و http2 في نهاية السطر، وتخبر هذه المتغيّرات Nginx بأن يستخدم بروتوكول HTTP/2 مع المتصفحات التي تدعم البروتوكول الجديد. الخطوة الثالثة: تغيير اسم الخادوم يأتي اسم الخادوم server_name بعد السطر السابق الذي يحوي على listen، وسنقوم بإعلام Nginx أيّ نطاق سيرتبط مع ملف الإعدادات. سنستبدل الاسم الافتراضي localhost الذي يعني بأن ملف الإعدادات مسؤول عن جميع الطلبات الواردة، وسنضع مكانه اسم النطاق الحقيقي، كـ example.com على سبيل المثال: server_name example.com; سنقوم الآن بحفظ التغييرات بالضغط على CTRL+O ومن ثم نضغط CTRL+X للخروج من محرر nano. الخطوة الرابعة: إضافة المسار إلى شهادات SSL الأمنية سنقوم بإعداد Nginx الآن ليستخدم الشهادات الأمنية اللازمة لـ HTTPS، وإن لم تكن تعلم ما هي الشهادة الأمنية أو لم تكن تملك واحدة فيرجى مراجعة المقالات المذكورة في قسم المتطلبّات الأولية في بداية المقال. لنقم أولًا بإنشاء مجلّد لحفظ الشهادات الأمنية فيه داخل مجلد إعدادات Nginx: $ sudo mkdir /etc/nginx/ssl سنقوم الآن بنسخ ملف الشهادة وملف المفتاح الخاص private key إلى داخل المجلد الجديد، وبعد ذلك سنقوم بتغيير أسماء الملفات لتظهر بوضوح أي نطاق ترتبط معه (تساعد هذه الخطوة في المستقبل على توفير الوقت والجهد إن امتلكت أكثر من نطاق واحد). لا تنسى استبدال example.com باسم النطاق الخاص بك. $ sudo cp /path/to/your/certificate.crt /etc/nginx/ssl/example.com.crt $ sudo cp /path/to/your/private.key /etc/nginx/ssl/example.com.key سنقوم بإضافة سطر جديد الآن إلى ملف الإعدادات ضمن كتلة server لتعريف مسارات الشهادة الرقمية مع مفتاحها الخاص ssl_certificate /etc/nginx/ssl/example.com.crt; ssl_certificate_key /etc/nginx/ssl/example.com.key; الخطوة الخامسة: تحويل جميع طلبات HTTP إلى HTTPS ينبغي الآن أن نخبر Nginx بأننا نرغب بتوفير المحتوى عبر HTTPS فقط إن استلم طلب HTTP عوضًا عن ذلك. سنقوم في نهاية ملف الإعدادات بإنشاء كتلة server جديدة لتحويل جميع طلبات HTTP إلى HTTPS، ومرة أخرى لا تنس استبدال النطاق باسم النطاق الخاص بك، ستكون الكتلة الجديدة على الشكل التالي: server { listen 80; listen [::]:80; server_name example.com; return 301 https://$server_name$request_uri; } لاحظ في الكتلة السابقة كيف أنّ Nginx عند استلامه لطلبات HTTP تخص النطاق example.com عبر المنفذ 80، فإنّه سيقوم بتحويل الطلب إلى HTTPS على نفس المسار المطلوب، مستخدمّا التحويل من النمط301 (moved permanently). سيصبح شكل ملف الإعدادات (إن تجاهلنا الأسطر الخاصة بالتعليقات) على النحو التالي: server { listen 443 ssl http2 default_server; listen [::]:443 ssl http2 default_server; root /var/www/html; index index.html index.htm index.nginx-debian.html; server_name example.com; location / { try_files $uri $uri/ =404; } ssl_certificate /etc/nginx/ssl/example.com.crt; ssl_certificate_key /etc/nginx/ssl/example.com.key; ssl_dhparam /etc/nginx/ssl/dhparam.pem; } server { listen 80; listen [::]:80; server_name example.com; return 301 https://$server_name$request_uri; } سنقوم الآن بحفظ ملف الإعدادات بالضغط على CTRL+O ومن ثم الخروج من محرر nano بالضغط على CTRL+X. الخطوة السادسة: تحميل ملف الإعدادات الجديد في ذاكرة Nginx لتطبيق التغييرات التي قمنا بها، سنحتاج لإعادة تشغيل خادوم Nginx: $ sudo service nginx restart وللتحقق من أن كل شيء سار على ما يرام، سنقوم بفتح المتصفح واستعراض النطاق الذي أعددناه مع Nginx، فإن كانت الإعدادات صحيحة، يجب أن يتم تحويل الطلب إلى HTTPS بشكل تلقائي، وللتأكد مما إذا تم استخدام البروتوكول الجديد فسنقوم بفتح أدوات المطوّر (في متصفح كروم يمكن فتحها من خلال قائمة View > Developer > Developer Tools)، ومن ثم نعيد تحميل الصفحة من جديد (View > Reload This Page)، ثم من خلال لسان Network، سنضغط بالزر الأيمن للفأرة على سطر رأس الجدول ونختار Protocol. يجب الآن أن يظهر عمود جديد عنوانه Protocol ستتمكن من خلاله من رؤية أن البروتوكول المستخدم هو h2 (الذي يرمز إلى بروتوكول HTTP/2) في حال تم الإعداد بشكل صحيح. إلى هنا سيكون Nginx قد أصبح قادرًا على تخديم المحتوى باستخدام بروتوكول HTTP/2، ولكن تبقى هناك بعض الأمور التي ينبغي إعدادها قبل استخدام الخادوم في بيئة التشغيل. الخطوة السابعة: تحسين Nginx لتقديم أداء أفضل سنقوم الآن بفتح ملف الإعدادات مجدّدًا لضبط إعدادات Nginx لتقديم أفضل أداء وحماية. تفعيل Connection Credentials Caching بالمقارنة مع HTTP، فإن HTTPS يتطلب وقتًا أطول نسبيًا لإنشاء اتصال ما بين الخادوم والمستخدم، ولتقليل الفرق في سرعة تحميل الصفحة، سنقوم بتفعيل ميّزة Connection Credentials Caching وهذا يعني بأنه عوضًا عن إنشاء جلسة عمل جديدة عند طلب كل صفحة، سيقوم الخادوم باستخدام نسخة خبء cache لمعلومات المصادقة. لتفعيل الميّزة، سنقوم بإضافة السطرين التاليين إلى نهاية كتلة http في ملف الإعدادات: ssl_session_cache shared:SSL:5m; ssl_session_timeout 1h; يقوم المتغيّر ssl_session_cache بتحديد حجم الخبء الذي سيحتوي على معلومات الجلسة، حيث يمكن لـ 1MB أن يقوم بتخزين معلومات 4000 جلسة عمل، وبالتالي ستكون القيمة الافتراضية 5MB أكثر من كافية لمعظم الحالات، ولكن إن كنت تتوقع أن يكون هناك حركة مرور كثيفة على الموقع، فيمكنك زيادة القيمة وفقًا لذلك. يحدّد المتغير ssl_session_timeout من الوقت الذي تكون ضمنه جلسة العمل فعّالة داخل الخبء، ولا ينبغي أن تكون هذه القيمة كبيرة (أكثر من ساعة)، وإلى جانب ذلك فإن تخفيضها كثيرًا سيخفض من الفائدة المرجوّة أيضًا. تحسين باقات التشفير Cipher Suites باقات التشفير هي مجموعة من خوارزميات التشفير التي تصف كيف ينبغي أن يتم تشفير البيانات المنقولة. يملك بروتوكول HTTP/2 قائمة كبيرة من خوارزميات التشفير القديمة وغير الآمنة التي يجب تجنّب استخدامها. سنقوم باستخدام مجموعة تشفير معتمدة من قبل جهات عملاقة مثل CloudFlare. لا تسمح هذه المجموعات باستخدام خوارزمية MD5 في التشفير (التي تم إثبات أنها غير آمنة في عام 1996، وبالرغم من ذلك، فما تزال منتشرة حتى يومنا هذا). سنقوم بإضافة السطرين التاليين بعد ssl_session_timeout: ssl_prefer_server_ciphers on; ssl_ciphers EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5; تفعيل ميزة (Strict Transport Security (HSTS على الرغم من أنّا قمنا بتحويل جميع طلبات HTTP إلى HTTPS في إعدادات Nginx، فينبغي علينا أيضًا أن نقوم بتفعيل ميّزة Strict Transport Security لتجنّب الحاجة لإخبار Nginx بعملية التحويل بأنفسنا أساسًا. عندما يصادف المتصفح ترويسة HSTS، فلن يحاول الاتصال بالخادوم عبر HTTP التقليدي مجدّدًا قبل مضي فترة من الوقت، ومهما حصل، سيعمل على تبادل البيانات عبر اتصالات HTTPS مشفّرة. تساعد هذه الترويسة على حمايتنا من هجمات تخفيض البروتوكول. كل ما نحتاجه هو إضافة السطر التالي في ملف الإعدادات: add_header Strict-Transport-Security "max-age=15768000" always; يحدّد المتغير max-age القيمة التي يجب على المتصفح خلالها ألا يحاول التواصل مع الخادوم إلا عبر بروتوكول HTTPS، وهذه القيمة ممثّلة بالثواني وبالتالي فإن القيمة 15768000 تساوي 6 أشهر. وبشكل افتراضي فإن هذه الترويسة لن يتم إضافتها إلى الطلبات الموجّهة للنطاقات الفرعية، فإن كنت تملك نطاقات فرعية وترغب أن يتم تطبيق HSTS عليها جميعًا فيجب إضافة المتغير includeSubDomains حينها إلى نهاية السطر على الشكل التالي: add_header Strict-Transport-Security "max-age=15768000; includeSubDomains: always;"; لا تنس حفظ الملف الآن بالضغط على CTRL+O ومن ثم إغلاقه بالضغط على CTRL+X إن كنت تستخدم محرر nano. الخطوة الثامنة: رفع حماية تبادل المفاتيح الأمنية إن الخطوة الأولى في إنشاء اتصال آمن هو تبادل المفاتيح الخاصة بين الخادوم والعميل، وتكمن المشكلة في هذه العملية في أنّه حتى تلك اللحظة فالاتصال غير مشفّر بينهما وبالتالي فالبيانات المتبادلة يمكن التنصّت عليها من طرف ثالث. لهذا السبب، سنحتاج لاستخدام خوارزمية Diffie-Hellman-Merkle في تبادل المفاتيح. يستخدم Nginx بشكل افتراضي مفتاح DHE) Ephemeral Diffie-Hellman) بطول 1024 بت، والذي يمكن فك تشفيره بسهولة نسبيًا، وللحصول على أمان أعلى فينبغي علينا إنشاء مفتاح DHE خاص أكثر أمنًا. للقيام بذلك سنقوم بتنفيذ الأمر التالي في سطر الأوامر: $ sudo openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048 تنبيه: يجب أن يتم إنشاء مُعاملات DH في المجلد الذي قمنا بتخزين الشهادات الأمنية فيه، وفي المقال قمنا بتخزين الشهادات في المسار /etc/nginx/ssl/. إن السبب وراء هذا هو أن Nginx يقوم دومًا بالبحث عن مفتاح DHE الخاص بالمستخدم في مجلد الشهادات الأمنية ويستخدمه إن وُجد. تحدّد القيمة 2048 في الأمر السابق طول المفتاح الذي نرغب بإنشائه، حيث سيكون مفتاح بطول 2048 بت أكثر أمنًا وينصح به من قبل مؤسسة موزيلّا، ولكن إن كنت تسعى خلف أقصى درجة أمان، فيمكنك استخدام مفتاح بطول 4096 بت. ستأخذ عملية إنشاء المفتاح حوالي 5 دقائق، ويمكنك أثناء ذلك الاسترخاء وارتشاف بعض القهوة. لتطبيق التغييرات التي قمنا بها على ملف الإعدادات، لا تنسى أن تقوم بإيقاف وإعادة تشغيل خادوم Nginx: $ sudo service nginx restart الخلاصة أصبح اتصال SSL الخاص بك أكثر أمنًا وقابلًا للاستخدام لنقل المعلومات الحساسة، ولكن إن أردت اختبار قوته الأمنية فقم بزيارة Qualys SSL Lab وبتشغيل اختبار على خادومك، حيث ينبغي أن تحصل على نتيجة A+إن كان كلّ شيء معدّ بشكل صحيح. هذا كلّ شيء، أصبح خادوم Nginx الخاص بك جاهزًا للاستخدام، وكما ترى فإن بروتوكول HTTP/2 هو حل رائع لتحسين سرعات نقل البيانات ومن السهل استخدامه كما أظهرنا في المقال. ترجمة -وبتصرّف- للمقال How To Set Up Nginx with HTTP/2 Support on Ubuntu 14.04 لصاحبه Sergey Zhukaev.

تحدد صلاحيّات الملفّات من يستطيع قراءة، إنشاء، تحرير ملف و/أو فتحه، وهذه العملية مهمّة في ووردبريس، لأنها قد تحتاج إلى إمكانية إنشاء ملفات جديدة في مجلد wp-content الّلازمة لعمل بعض الوظائف. إن عدم امتلاك ملفات الموقع للصلاحيات الضرورية والكافية يفتح المجال للآخرين للتطفّل على ملفّات موقعك، وقد لا يحميك تعيين الصلاحيات بشكل صحيح من جميع الهجمات الإلكترونية، لكنه سيساعدك في جعل موقعك أكثر أمانًا، حيث سيكون إجراءً أمنيًّا آخر يضاف إلى إجراءاتك الأمنية الحالية. يحتوي توثيق ووردبريس على بعض المعلومات حول صلاحيات الملفات الضرورية لـ ووردبريس، لكن قد يكون من الصعب متابعته لأنّه لا يشرح التفاصيل، لذا يهدف المقال إلى شرح تفاصيل صلاحيات الملفات والمجلّدات وكيفية تغييرها بغرض رفع أمان الموقع. كيف تبدو صلاحيات الملفات؟ توجد فئتان يجب أخذهما بعين الاعتبار عند التحدّث عن صلاحيات الملفّات: العمليّات ومستخدمو العمليّات. العمليّات وهي العمليات التي من الممكن تنفيذها على الملفّات: القراءة Read: تسمح بقراءة محتوى ملف فقط، ويتم تمثيلها بالحرف r كما سنرى لاحقًا. الكتابة Write: تسمح بإنشاء ملف جديد و/أو تعديل محتوى ملف موجود مسبقًا، ويتم تمثيلها بالحرف w. التنفيذ Execute: تعطي إمكانية تنفيذ الملف بغرض تشغيله كبرنامج أو سكربت، ويتم تمثيلها بالحرف x. ملاحظة: يجب الانتباه إلى عدم الخلط ما بين عمليّتي القراءة والتنفيذ، فالأولى تسمح بقراءة محتوى ملف (سواء كان ملف نصّي، أو صورة، أو برنامج حتّى) ولكنّها لازمة وغير كافية لتنفيذ محتوى الملف إن كان برنامجًا، فحينها يجب أن يمتلك ملف البرنامج إمكانيّتي القراءة والتنفيذ كي يكون بالإمكان تشغيله كبرنامج. أما مستخدمو العمليات فهم: المستخدم User: وهو مالك الملف owner، المجموعة Group: ويمكن أن تضم مستخدمين آخرين لهم صلاحية الوصول إلى الملفات التي تختارها والتي لهذه المجموعة صلاحية الوصول إليها; الطرف الثالث World: أي مستخدم آخر عدا ما ذُكر. ويمكن تمثيل صلاحيات الملفّات كمجموعات متتالية من الأرقام على الشكل rwxrwxrwx-: الرقم الأول rwx: صلاحيات الوصول الخاصة بمالك الملف user (أو owner). الرقم الثاني rwx: صلاحيات الوصول الخاصة بالمجموعة group. الرقم الثالث rwx: صلاحيات الوصول الخاصة بالطرف الثالث world. وللحصول على قيمة الرقم الخاص بِكلّ مجموعة سنقوم اعتمادًا على النظام الثنائيّ binary باستنباط الجدول التالي: نظام rwx الثُنائي binary القيمة بالنظام العُشري decimal إمكانيّة Read/Write/Execute 000 0 001 1 تنفيذ فقط 010 2 كتابة فقط 011 3 كتابة + تنفيذ 100 4 قراءة فقط 101 5 قراءة + تنفيذ 110 6 قراءة + كتابة 111 7 قراءة + كتابة + تنفيذ فاستنادًا للجدول السابق فإن أعلى صلاحية rwxrwxrwx- يمكن منحها بالنظام العُشريّ هي 777 حيث يكون لكلٍّ من المالك، المجموعة والطرف الثالث جميعهم، إمكانية القراءة والكتابة والتنفيذ، وبنفس الشكل يمكن القول بأنّ أقلّ صلاحية rwxrwxrwx- يمكن منحها (إلى جانب عدم وجود أيّ صلاحية على الإطلاق) هي 444، حيث يملك الجميع إمكانية القراءة فقط. لا تخف فهناك طريقة سهلة لتذكر الصلاحيات، فعلى سبيل المثال لو أردنا إعطاء مالك الملف كامل الصلاحيات والحدّ من صلاحيات باقي المستخدمين، فنقوم بما يلي: المستخدم User – سيملك إمكانية القراءة (4)، الكتابة (2) والتنفيذ (1)، فتكون قيمة الصلاحية النهائية (1+2+4=7) المجموعة Group – ستملك إمكانية القراءة (4) والكتابة (2)، فتكون قيمة الصلاحية النهائية (4+2=6) الطرف الثالث World – سيملك إمكانية القراءة فقط (4). إذًا، تصبح صلاحية الملف النهائيّة 764 أو rwxrw-r-- في هذا المثال، ولكنّ هذه الصلاحية غير مثاليّة لملفات مدوّنات ووردبريس، فقد تلاحظ بأن صلاحيات الملفّات تبدو مختلفة قليلًا عند التحقق منها عبر SSH أو FTP، كما في الصورة: تذكّر بأن الـ - (hyphen) في صيغة صلاحيّات الملفّات تمثّل غياب إمكانية ما، عدا أوّل - إلى أقصى اليسار والتي تبيّن فيما إذا كانت الصلاحية لملف أو مجلّد، فإن كانت لمجلّد حلّ محلّها الحرف d، الحرف الأول من كلمة directory. تجدر الإشارة إلى أنّ المحرف الأول إلى اليسار قد يملك قيمًا مختلفة عن الحرف d ولكن يندر أن تصادف هذا في ووردبريس. وكما ذكرنا سابقًا فإنّ كلّ مجموعة تمثّل الإمكانيات المسموحة لكل مجموعة مستخدمين، فإن أخذنا الصلاحية التالية rwxr-xr-x- فإنّ الـ - في أقصى اليسار تخبرنا بأنّ هذه صلاحية ملف، أما الـ rwx التي تليها فتخبرنا بأنّ المستخدم مالك الملف يملك إمكانية القراءة والكتابة والتنفيذ، بينما تملك مجموعة المستخدمين المالكة للملف إمكانية القراءة والتنفيذ، وأخيرًا يكون لباقي المستخدمين إمكانية القراءة والتنفيذ أيضًا، فإن قُمنا بتحويل نمط الصلاحية هذا إلى الشكل الرقمي لحصلنا على القيمة 755. من الجدير بالذكر بعد هذا الشرح المطوّل بأنّ الصلاحية 777 تعطي جميع المستخدمين كامل الصلاحيات وهذا غير مناسب أمنيًّا ويجب عدم استخدامه لمواقع ووردبريس على الأقل، وفي الوقت ذاته فإنّ الصلاحية 444 لن تكفي ليعمل موقع يستخدم ووردبريس. ما الصلاحيات اللازمة لمواقع ووردبريس؟ إن قمت بتنصيب ووردبريس بنفسك فإنّ الصلاحيات ستكون معدّة بشكل صحيح غالبًا، ولكن إن كنت تحصل على رسائل خطأ بصلاحيات الوصول أو كان موقعك معدًّا من قبل شخص آخر، فإنّ الوقت مناسب لمراجعة صلاحيات الملفّات. تختلف الصلاحيات المطلوبة باختلاف الإضافات plugins التي قد تستخدمها في موقعك والتي تتبع لطبيعة عمل الـ plugin، وستعتمد صلاحية الملفات والمجلّدات على إعدادات استضافتك، فإن كنت تستخدم خادومًا خاصًا بك بالكامل (dedicated server) فإنّ بالإمكان استخدام الصلاحيات التالية بشكل آمن تبعًا لما يذكره توثيق ووردبريس: للمجلّدات – 755 للملفّات – 644 أمّا الملفّات الأكثر خصوصية كملف الإعدادات الخاصة بـ ووردبريس والذي يتضمن معلومات حسّاسة wp-config.php، فيمكن استخدام الصلاحية 600 معه، ويستثنى من ذلك ملف htaccess. والذي يحتاج موقع ووردبريس للوصول إليه ليتم تحديث محتواه بشكل اوتوماتيكي، فينصح باستخدام الصلاحية 644 معه أو الصلاحية الأكثر أمنًا 604 في معظم الحالات. كيف يمكن التحكم بصلاحيات الملفات؟ يمكن إيجاد صلاحيات الملفات المذكورة على أنظمة لينكس/يونكس فقط، فإن فرضنا أنّ الاستضافة مزوّدة بلوحة تحكّم cPanel فعندها للوصول إلى صلاحيات الملفات نتوجّه بعد تسجيل الدخول إلى: Files > File Manager وعند ظهور نافذة اختيار المجلّد الرئيسي، نضغط زر Go أسفل النافذة. بعد ظهور صفحة إدارة الملفات، نختار أيّ ملف ثم نضغط على أيقونة Change Permissions في أعلى الصفحة. ستظهر الآن نافذة منبثقة تحوي على صلاحيات الملف أو المجلّد الذي قمنا باختياره، والتي يمكن من خلالها التعديل عليها: إضافة لما سبق فإنّ بالإمكان التعديل على الصلاحيات عبر برنامج إدارة الملفّات باستخدام FTP، فمثلًا باستخدام FileZilla بعد إتمام الاتصال، يمكن الوصول إلى صلاحيات الملف بالضغط بالزر الأيمن على الملف أو المجلّد المطلوب واختيار File permissions: حيث ستظهر نافذة يمكن خلالها التعديل على الصلاحيات كالمعتاد أيضًا: وأخيرًا يمكن التعديل أيضًا على الصلاحيات عبر سطر الأوامر من خلال SSH بعد تسجيل الدخول، باستخدام الأمر التالي: للمجلّدات find /path/to/your/wordpress/install/ -type d -exec chmod 755 {} \; للملفّات find /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \; سيقوم الأمر السابق بإعادة ضبط صلاحيات جميع المجلّدات في المسار المحدّد لتأخذ الصلاحية 755 وجميع الملفّات لتأخذ الصلاحية 644، وبالطبع لا تنس التأكّد من إدخال مسار تثبيت ووردبريس بشكل صحيح قبل التنفيذ. الخلاصة قمنا بتغطية الأساسيات الخاصّة بصلاحيات الملفات الّلازمة لعمل ووردبريس وكيفية تغييرها من خلال لوحة تحكم cPanel أو من خلال بروتوكوليّ FTP و SSH، لكن يبقى تحديث إصدار ووردبريس أمرًا ضروريًّا من الناحية الأمنيّة، فإنّ هذا يضمن بأنّ صلاحيات الملفات سيتم ضبطها بشكل تلقائيّ إلى الوضع الأمثل. إن كنت تفضّل استخدام الإضافات، فهناك 3 منها يمكنك تجربتها: Triagis® WordPress Security Evaluation SECURE BulletProof Security حيث تقوم هذه الإضافات بالتحقّق من صلاحيات الملفات وتخبرك إن كان هناك إعدادات غير مقبولة. هل احتجت من قبل لإصلاح صلاحيات الملفات لديك؟ شاركنا تجربتك عبر التعليقات في الأسفل. ترجمة -وبتصرّف- للمقال Understanding File Permissions and Using Them to Secure Your Site لصاحبته Jenni McKinnon.

يُوفّر التّحكّم بخادوم لينكس الخاصّ بك فرصةً لتجربة أشياء جديدة والاستفادة من صلابة ومرونة هذه المنصّة الرّائعة. مع ذلك يجب على مسؤولي خواديم لينكس الانتباه إلى أنّ ميزات المنصّة لا تُغني عن التّدابير اللّازم اتّخاذها عند التّعامل مع حاسوب متّصل بالشّبكة، من أجل تأمينه وحمايته. تندرج العديدُ من الموضوعات الأمنيّة في الفئة العامة المسمّاة “أمان لينكس”، كما توجد العديد من الآراء حول مستوى الأمان المناسِب لخاودم لينكس. الفكرة الأساسيّة الّتي يجب العمل عليها هي تقرير نوعيّة الإجراءات الأمنيّة المطلوبة لحماية نظامك. قبل ذلك، ولكي تتّخذ القرارات المناسبة؛ يجب أن تعيَ الأخطار الموجودة والمقايضات الممكنة ثمّ تحدّد نقطة التّوازن بين قابليّة الاستخدام والأمان. يهدف هذا المقال إلى مساعدتك في اتّخاذ قراراتك عبر عرض بعض الإجراءات الأمنيّة الأكثر شيوعًا في البيئات الّتي تستخدم خواديم لينكس. يُرجى الانتباه إلى أنّ هذه القائمة غير شاملة ولا تتطرّق للإعدادات المنصوح بها؛ لكنّها ستُحيل إلى روابط توفّر موارد أكثر وتناقش مدى أهميّة بعض العناصر في نُظُم مختلفة. استخدام الجدران النّاريّة Firewalls لمنع الوصول ضبط وإعداد جدار ناريّ إحدى الخطوات الأسهل الّتي ينبغي تطبيقها في عمليّة تأمين الخادوم. تعمل الجدارن النّارية كحاجز بين شبكة الإنترنت وخادومك الخاصّ؛ حيثُ تُراقب حركة البيانات من وإلى الخادوم، ثمّ تقرّر السّماح لها بالمرور أو منعها. تعتمد الجدران النّاريّة في قراراتها (السّماح بمرور بيانات أو منعها) على قواعد يضبطها مدير النّظام. في العادة، يستعمل الخادوم بضع منافذ Ports للخدمات المُرخَّصة بينما تبقى بقيّة المنافِذ غير مستعملة ويجب أن توضع وراء جدار ناريّ يمنع جميع الطّلبات الموّجهة عبر هذه المنافذ من الوصول. تسمح لك الجدران النّاريّة بتجاهل البيانات الّتي لا تنتظر توجيهها إليك، وفي بعض الحالات تقييد الوصول إلى الخدمات الفعليّة الموجودة في النّظام. تُوفّر قواعد الجدران النّاريّة المعدّة بطريقة صحيحة أساسًا جيّدًا لتأمين الشّبكة. نستعرض في الفقرات التّاليّة بعض برامج الجدران النّاريّة. 1- UFW يهدف UFW (اختصار ل Uncomplicated FireWall، أي جدار ناريّ غير معقّد) إلى توفير حماية جيّدة دون الاعتماد على صيّاغة معقَّدة للقواعد كما تفعل بقيّة الحلول. UFW هو في الواقع، مثله مثل أغلب الجدران النّاريّة على لينكس، برنامج للتّحكّم في الجدار النّاري المُضمَّن في نواة لينكس، والمسمَّى Netfilter. يُعدّ UFW حلًّا سهلًا لغير المعتادين على استخدام الجدران النّاريّة على لينكس؛ وهو عمومًا حلّ جيّد. يُمكن الحصول على معلومات أكثر عن UFW، ومعرفة كيفيّة تفعيله وضبطه عبر اتّباع هذا الرّابط. 2- IPTables ربّما يكون IPTables الجدار النّاري الأكثر شهرة في لينكس. IPTables هو الآخر وسيلة لإدارة Netfilter. يتوفّر برنامج IPTables منذ زمن بعيد، وتعرَّض للكثير من التّدقيق خلال هذه الفترة للتّأكّد من أمانه. توجد نسخة مخصّصة للإصدار 6 من عناوين IP، تُسمّى IP6Tables. ستلاقي على الأرجح إعدادات تتضمّن IPTables أثناء إدارة خواديم لينكس. قد تكون صيّاغة القواعد صعبة الفهم من الوهلة الأولى، إلّا أنّ IPTables يبقى أداةً قويّة يُمكن إعدادها عن طريق مجموعة قواعد مرنة جدًّا. يشرح هذا الدّرس إعداد بعض قواعد IPTables على توزيعتيْ أوبنتو ودبيان؛ في ما تجد في الرّابط التّالي شرحًا لاستخدام IPTables على توزيعات CentOS، وFedora و RHEL. 3- IP6Tables يُستخدَم IPTables للتّعامل مع قواعد تتضمّن عناوين IP من الإصدار الرّابع IPv4؛ إذا كان الإصدار السّادس IPv6 مفعّلًا على خادومك فيجب أن تنتبه أيضًا إلى إصدار IPTables المكافئ: IP6Tables. يحتفظ الجدار النّاري المضمَّن في نواة لينكس، Netfilter، بجداول منفصلة لكلّ من البيانات المنقولة عبر IPv6 وIPv4. من هذا المنطلق، تتحدّد القواعد المطبَّقة على حزمة بيانات بإصدار IP المستخدَم. يعني هذا، بالنّسبة لمدير النّظام، أنّه يتوجّب إعداد مجموعة قواعد جديدة خاصّة بالإصدار 6 من عناوين IP، عندما يكون مفعَّلًا. تتشارك قواعد IP6Tables نفس الصّيّاغة مع قواعد IPTables؛ وهو ما يعني أنّ إضافتها لين يُشكّل مشكلًا كبيرًا. ينبغي فقط الانتباه إلى أنّ القواعد يجب أن تُطابق البيانات المُمرَّرة عبر IPv6 حتى تعمل بالطّريقة المطلوبة. 4- NFTables يُعدّ IPTables المعيار Standard في عالم الجدران النّاريّة على بيئات لينكس منذ بعض الوقت، على الرّغم من ذلك أُضيف مؤخَّرًا جدار ناريّ جديد يُدعى NFTables إلى نواة لينكس. يقف خلف الجدار الجديد نفس الفريق الّذي يُطوِّر IPTables. ويهدف - على الأمد الطّويل - إلى الحلول محلّ IPTables. يُحاول جدار NFTables مراعاة صيّاغة أكثر قابليّة للقراءة من صيّاغة IPTables، ويدعم قواعد تتعامل مع كلا الإصداريْن IPv4 وIPv6 في نفس الأداة. يُتوقَّع أن يكون NFTables حاضرًا على معظم أو كلّ توزيعات لينكس في الأمد القريب، لذا يُستحسَن محاولة التّعوّد على استخدامه. استخدام SSH للولوج الآمن عن بعد ستحتاج لطريقة للدّخول عن بعد، إن لم تكن لديك فرصة الوصول المباشر إلى الخادوم. الإجراء المتبَّع في هذه الحالة للدّخول بشكل آمن هو استخدام بروتكول معروف يُسمَّى SSH (اختصار لSecure SHell). يُوفّر SSH التّعميّة من طرف إلى طرف End-to-end encryption، إمكانيّة تمرير بيانات غير مؤمَّتة عبر اتّصال آمن، إعادة توجيه الخادوم X (واجهة المستخدِم الرّسوميّة عبر الشّبكة)، وأكثر. بالمختصر إذا أردت الاتّصال عن بعد بخادومك فيجب أن يكون SSH خيّارك الأوّل. على الرّغم من أنّ بروتوكول SSH نفسه آمن جدًّا وتعرَّض للكثير من التّدقيقات الأمنيّة، إلّا أنّ خيّارات الإعداد يُمكن أن تُعزّز أو - على العكس - تقوِّض أمان الخدمة. سنناقش هذا الأمر أدناه. 1- كلمة السّرّ في مقابل مفاتيح SSH لتسجيل الدّخول يُتيح SSH العديد من طرق الاستيثاق Authentication؛ أشهر طريقتيْن هما كلمة السّرّ ومفتاح SSH. كلمة السّرّ، من بين الخيّارين أعلاه، هي الأيسَر للمستخدم ولكنّها في نفس الوقت الأقلّ أمانًا. يسمح الاستيثاق عن طريق كلمة السّرّ لمحاولي التّسلّل باستمرار تخمين كلمة السّر إلى أن يُعثَر على الكلمة المُناسبة. تُسمّى آليّة الاختراق هذه بهجمات القوّة القاسيّة Brute force attack ويُمكن تشغيلها آليًّا بيُسر عن طريق بعض الأدوات البرمجيّة. على الجانب الآخر، تعمل مفاتيح SSH على توليد زوج من المفاتيح، عموميّ وسرّي. يُنشَأ مفتاح عموميّ Public key ليُستعمَل في تحديد هويّة المستخدِم، ويُمكن تشاركه دون مشاكل. لا يُمكن استعمال المفتاح العموميّ لأغراض أخرى غير تعريف مستخدِم، والسّماح بالولوج بمفتاح سرّي Private key موافق للمفتاح العموميّ المستعمَل. ينبغي أن لا يُنشَر المفتاح السّريّ، حيث يُستخدَم في التحقّق من المفتاح العموميّ المُصاحِب له. المبدأ هوّ أن تُضيف مفتاح SSH العموميّ الخاصّ بك إلى الخادوم وسيُسمح لك بالولوج باستعمال المفتاح السّري المُصاحِب للمفتاح العموميّ المُضاف إلى الخادوم. هذه المفاتيح على درجة من التّعقيد تجعل استخدام هجمات القوّة القاسيّة لتخمينها غير عمليّ. إضافةً لذلك، يمكن تحديد عبارة سرّ Passphrase طويلة إلى المفتاح السّرّيّ وهو ما يعني أمانًا أكبر. راجع هذا الدّرس لمعرفة المزيد حول الاتّصال عن طريق على خادوم أوبنتو SSH. الرّابط التّالي يشرح كيفيّة توليد مفاتيح SSH على خادومك. 2- إعداد fail2ban لحظر عناوين IP الخبيثة تُساعد أداة fail2ban في تأمين إعدادات SSH، ومن ثَمَّ الأمان العامّ للخادوم. تعمل fail2ban على مراقبة السّجلّات Logs لتحديد إمكانيّة أن يكون من يُحاول الاتّصال عبر SSH غيرَ مصرَّح له بالدّخول؛ في هذه الحالة يعمل fail2ban على حظر حركة البيانات القادمة من عنوان IP المُستخدَم. يسمح إعداد إستراتيجيّة صحيحة لاستخدام fail2ban بتحديد الأجهزة الّتي تحاول باستمرار - دون نجاح - الولوج إلى الخادوم، وإضافة قواعد للجدار النّاريّ لتجاهل حركة البيانات القادمة من هذه الأجهزة لفترة من الوقت. تُستعمل هذه الطّريقة دائمًا لعرقلة هجمات القوّة القاسيّة، إذ أنّ المهاجِم سيحتاج عندما يُحظَر، للانتظار بعض الوقت قبل معاودة الكرّة. يكفي هذا الأمر عادةً لإحباط من يحاول الدّخول عبر هذه الهجمات. يُمكن التّعرّف في الرّابط على كيفيّة ضبط fail2ban على أوبنتو. توجد أيضًا أدلّة مشابهة لكل من Debian وCentOS. ضبط نظام للكشف عن التّطفّل Intrusion Detection System لكشف عمليّات الدّخول غير المرخَّصة يجب الانتباه إلى وجوب إعداد آليّة لكشف الاستخدام غير المرخَّص. يُمكن أن تعدّ تدابير وقائيّة لكنك تحتاج أيضًا إلى معرفة هل نجحت هذه التّدابير أم لا. تعمل أنظمة الكشف عن التّطفّل، IDS، على تجميع معطيات عن الإعدادات والملفّات عندما يكون النّظام في وضعيّة يُعرف بأنّها جيّدة؛ ثمّ يُجري النّظام مقارنات بالمعطيات المُسجّلة لرصد تغييرات على الملفّات أو الإعدادات. سنرصد في ما يلي بعض أنظمة الكشف عن التّطفّل. 1- Tripwire يُعدّ Tripwire أحد أنظمة الكشف عن التّطفّل الأكثر شهرة. يُنشئ Tripwire قاعدة بيانات بملفّات النّظام ويحمي ملفّات الإعداد والملفّات التّنفيذيّة بمجموعة من المفاتيح. تُشعِر عمليّاتُ تشغيل Tripwire التّاليّةُ لتعيين تفاصيل الإعداد وتحديد الاستثناءات بأيّ تحريف يحصُل للملفّات الّتي يُراقبها. يُقدّم Tripwire نموذجًا مرِنًا لإعداد السّيّاسات يسمح بتشكيل خواصّه لتتلاءم مع بيئة العمل. يُمكن بعدها ضبط Cron ليُشغّل Tripwire دوريًّا؛ بل ويُمكن إعداد إشعارات تُرسَل عبر البريد الإلكترونيّ عند وجود أنشطة غير طبيعيّة. اقرأ المزيد عن إعداد Tripwire. 2- Aide برنامج Aide هو خيّار آخر لأنظمة الكشف عن التّطفّل. يُشبه Aide في عمله Tripwire؛ حيثُ ينشئ قاعدة بيانات ثمّ يقارن الوضعيّة الحاليّة للنّظام مع قيّم محفوظة أثناء وجود النّظام في وضعيّة جيّدة. عند ملاحظة أي اختلاف يُمكن للبرنامج إشعار مسؤول النّظام. يوفّر كلّ من Aide وTripwire حلولًا متشابهة لنفس المشكل. راجع التّوثيق Documentation وجرّب الاثنين ثم اختر ما يُناسبك. اقرأ الدّليل التّالي لمعرفة كيف تستخدم Aide لكشف التّطفّل. ### 3- Psad يختلف برنامج Psad عن البرنامجيْن السّابقيْن من حيث إنّه يهتمّ بجزء مختلف من النّظام. بدلًا من مراقبة ملفّات النّظام، فإن Psad يُراقب سجلّات الجدار النّاريّ لمحاولة رصد النّشاطات غير الطّبيعيّة. على سبيل المثال، إذا وُجد من يبحث عن ثغرات Vulnerabilities في النّظام عن طريق فحص المنافذ Ports فإنّ Psad يُمكن أن يرصُد هذا النّشاط ويغيّر قواعد الجدار النّاريّ ديناميكيًّا لحظر المستخدِم المعنيّ. يُمكن لهذا البرنامج تسجيل مستويات عديدة للتّهديدات ثمّ يعتمد في تجاوبه مع التّهديدات على خطورة المشكل الّذي يواجهه. توجد أيضًا إمكانيّة إرسال بريد لمدير النّظام. اقرأ الدّرس التّالي للمزيد حول استخدام برنامج Psad. ### 4- Bro برنامج Bro هو وسلة أخرى لضبط نظام كشف عن التّطفّل يعتمد على حركة البيانات في الشّبكة. Bro هو في الأصل إطار عمل Framework لمراقبة الشّبكة؛ يُمكن استخدامه كنظام للكشف عن التّطفّل أو لأغراض أخرى مثل تجميع إحصائيّات عن الاستخدام، التّحرّي عن المشاكل أو التّعرّف على أنماط Patterns معيَّنة. يُقسًّم نظام Bro إلى طبقتيْن. الطّبقة الأولى تُراقب النّشاطات وتُولّد أحداثا Events. أمّا الطّبقة الثّانيّة فتشغّل الأحداث المُولَّدة تبعًا لسيّاسات تُملي ما يتوجّب عمله. يُمكن لهذه الطّبقة إرسال تحذيرات، تنفيذ أوامر، مجرّد تسجيل الحالة أو إجراءات أخرى. يشرح الدّليل التّالي كيفيّة استخدام Bro لكشف التّطفّل. ### 5- RKHunter لا يعدّ برنامج RKHunter - تقنيًّا - برنامجًا للكشف عن التّطفّل، إلّا أنّه يعمل بنفس المبادئ الّتي تستخدمها أنظمة الكشف عن التّطفّل المعتمدة على مراقبة ملفّات النّظام، مثل Tripwire وAide. يهدف RKHunter في الأساس إلى كشف برامج Rootkits (برامج تُساعد المهاجمين في إخفاء ما ينفّذونه من عمليّات على النّظام) والبرمجيّات الخبيثة Malwares المعروفة. على الرّغم من ندرة الفيروسات على لينكس إلّا أنّ البرمجيّات الخبيثة وبرامج Rootkits موجودة ويُمكن أن تُصيب الخادوم وتُعطي إمكانيّة ولوج مستمرّ لمستغلّي الثّغرات. يُنزّل RKHunter قائمة بالثّغرات المعروفة ويتأكّد من عدم وجودها على النّظام؛ كما أنّه يحذّر مدير النّظام في حال كشف إعدادات غير آمنة في بعض التّطبيقات الشّائعة. يوجد في الرّابط التّالي دليل لاستخدام RKHunter على أوبنتو. General Security Advice تُساعد الأدوات المذكورة أعلاه في تأمين أجزاء من نظامك، إلّا أنّ الأمان لا يأتي فقط من إعداد أداة ثمّ نسيانها. يظهر الأمان في بعض العقليّات؛ ويمكن أن يتحقّق عبر الاجتهاد، التّدقيق والانخراط في عمليّة التّأمين. توجد بعض القواعد الّتي يُساعد اتّباعها في وضعك على الطّريق الصّحيح للاستخدام الآمن لنظامك. 1- انتبه إلى التّحديثات وحدّث الخادوم بانتظام يُعثر على الثّغرات طول الوقت وفي كلّ أنواع البرامج الّتي يمكن أن تكون لديك على الخادوم. يؤدّي مطوّرو التّوزيعات على العموم عملًا جيّدًا في الاطّلاع على آخر الثّغرات الأمنيّة والحرص على إرسال تحديثاتها إلى المستودعات Repositories؛ إلّا أنّ توفّر التّحديثات الأمنيّة في المستودَع لا يعني أنّ الخادوم آمن ما لم تُنزّلها وتثبّتها عليه. على الرّغم من أن الخواديم تستفيد من إصدارات مجرَّبَة جيّدًا، إلّا أنّ التّرقيعات الأمنيّة يجب أن تُعدَّ حرِجة ويجب تثبيتها فور صدورها. تُوفّر العديد من التّوزيعات قوائم بريديّة خاصّة بالأخبار الأمنيّة ومستودعات أمنيّة منفصِلة لتنزيل التّرقيعات الأمنيّة. 2- كن حذِرًا عند تنزيل برامج من خارج القنوات الرّسميّة يلتصق الكثير من المستخدمين بالبرامج المتوفّرة في المستودعات الرّسميّة لتوزيعاتهم، كما أنّ أغلب التّوزيعات تُوفّر حزمًا Packages موَقَّعة Signed. يُمكن عمومًا للمستخدمين الوثوق في مطوّري التّوزيعات والتّركيز على التّهديدات الأمنيّة في البرامج المُتحصَّل عليها من خارج المستودعات الرّسميّة للتّوزيعة. يُمكن أن تثق في الحزم القادمة من التّوزيعة الّتي تستخدمها أو من مواقع ويب رسميّة، لكن انتبه إلى إمكانيّة وجود خطر أمنيّ، إلّا إذا كنت تدقّق كل جزء من البرامج بنفسك. يرى الكثيرون أنّ مستوى الخطر هذا مقبول. على العكس من ذلك، يمكن للبرامج المتحصَّل عليها من مستودعات عشوائيّة أو من مستودعات PPA (اختصار لPersonal Package Archives، أرشيف حزم شخصية) يُشرف عليها أشخاص أو منظَّمات غير معروفة، يمكن أن تكون خطرًا محدِقا. لا توجد قاعدة عامّة، ولكن يمكن عدّ أغلب البرامج المتوفّرة في المستودعات غير الرّسميّة آمنة؛ لكن يجب الحذر والانتباه إلى وجود خطر في كلّ مرة تثق في طرف ثالث. تأكّد من قدرتك على شرح السّبب الّذي يجعلك تثق في مصدر البرنامج. في النّهاية الخطر على أمان نظامك مشكل أكبر من عدم توفّر بعض وسائل الرّاحة في التّعامل مع النّظام. 3- اعرف خدماتك وعرّف حدود استخدامها على الرّغم من أنّ الهدف الأساسيّ من تشغيل خادوم هو توفير خدمات، إلّا أنّه يجب تحديد الخدمات المُشغّلة على الجهاز وعدم تشغيل خدمات لا تحتاجها. انظُر إلى كلّ خدمة مُفَعَّلة على أنّها ناقل للخطر؛ وحاول التّخلّص من كلّ ناقل خطر حسب استطاعتك بحيث لا تؤثّر على الوظائف الّتي تُريد توفيرها عبر الخادوم. يعني هذا أنّك يجب أن تُعطّل خادوم العرض X إذا لم توجد شاشة متّصلة بالخادوم ولم تكن تشغِّل أي برامج رسوميّة (برامج الويب لا تدخل في هذا التّصنيف). يُمكن اتّخاذ إجراءات مشابهة في مجالات أخرى؛ لا تستخدمُ طابعة؟ عطِّل خدمة lp. لا تشارك الملفّات مع وندوز؟ عطِّل خدمة samba. توجد طرق عديدة لمعرفة الخدمات المُشغَّلة على جهازك. يعرض المقال التّالي لطريقة إنشاء قائمة بالخدمات المُفَعَّلة. 4- لا تستخدم FTP، استعِض عنه بSFTP. قد تكون هذه النّقطة من أكثر الأمور صعوبة للتّطبيق على كثير من المستخدمين؛ لكن بروتوكول FTP غير آمن منذ بداياته. كلّ معلومات الاستيثاق تُرسل في نصوص صِرفة (غير معمّاة) Plain-text، وهو ما يعني أنّ باستطاعة كلّ من يراقب الاتّصال بين الجهاز المحلّي وبين الخادوم معرفة بيانات الاستيثاق. توجد حالات قليلة يُمكن أن يكون فيها استخدام FTP مبرَّرا. إذا كنت تشغّل مرآة تنزيل عموميّة، مجهولة وللقراءة فقط؛ فFTP ربّما يكون خيّارًا مناسِبا. يُمكن أيضًا استخدام FTP عند نقل ملفّات بين حاسوبيْن موجوديْن في شبكتيْن محميتْن بجدار ناريّ، وتثق في أن الشّبكتيْن آمنتان. يجب أن تستخدم في أغلب الحالات الأخرى بديلًا آمنًا. تأتي حزمة SSH ببروتكول بديل يُسمَّى SFTP، يُستخدَم بنفس طريقة استخدام FTP ويوفّر نفس درجة الأمان الّتي يُوفّرها بروتوكول SSH. يشرح درس كيف تستخدِم SFTP لنقل الملفّات بأمان إلى خادوم بعيد طريقة التّعامل مع SFTP. 5- اضبُط سيّاسات حسّاسة لأمان المستخدمين توجد عدّة خطوات يُمكن تطبيقها لتأمين النّظام عند إدارة المستخدِمين. الاقتراح الأوّل هو تعطيل دخول المستخدِم الجذر Root user. يُعدّ حساب المستخدِم الجذر مقصِدًا جذّابًا لمحاولات التّسلّل نظرًا لوجوده على كلّ الأنظمة المتوافقة مع معيار POSIX، وللامتيّازات اللّامحدودة الّتي يتمتّع بها في النّظام. تبدو فكرة تعطيل دخول المستخدم Root، بعد إعداد الوصول عن طريق sudo أو إذا كنت مرتاحًا مع أمر su، تبدو فكرةً جيّدة. لا يوافق الكثيرون على هذه الفكرة؛ جرّب جدوائيّتها بالنّسبة لك. توجد إمكانيّة تعطيل الدّخول عن بعد لحساب root ضمن إعدادات SSH، كما يُمكن تعطيل الدخول للحساب الجذر محلّيًا. يُمكن أيضًا إضافة تقييدات على الحساب ضمن ملف الإعداد etc/securetty/، أو ضبط برنامج Shell للمستخدم الجذر بحيث يُشير إلى برنامج آخر ممّا ينتج عنه تعطيل وصول root إلى Shell. خيّار آخر يتمثّل في إعداد قواعد PAM (أو Pluggable Authentication Modules، وهي طبقة لتمكين الاستيثاق بين خدمات مختلفة على الأنظمة الشّبيهة بيونكس) لتقييد ولوج المستخدم الجذر. توفّر RedHat مقالًا رائعًا حول كيفيّة تعطيل دخول المستخدم الجذر. يتوجّب أيضًا العمل على تنفيذ سيّاسة أمنيّة يُنشَأ بموجبها حساب وحيد لكلّ مستخدم أو خدمة، ثمّ يُعطى الأذون Permissions الدّنيا اللّازمة لعمله. امنع الوصول إلى كلّ ما لا تحتاج الوصول إليه ولا تعطِ للمستخدمين امتيّازات لا يحتاجون إليها. هذه السّيّاسة مهمّة جدًّا، ففي حالة اختراق مستخدِم أو خِدمة فلن يؤدّي ذلك إلى تأثير الدومينو الّذي يسمح لمهاجمٍ بالحصول على صلاحيّات واسعة في النّظام. تُساعد طريقة التّقسيم هذه في عزل المشاكل الأمنيّة، بحيث لا يتسبّب مشكل أمنيّ لدى حساب واحد في تعريض كامل النّظام للخطر. يجب كذلك التّأكّد من تعطيل حسابات المستخدمين عندما تنقضي الحاجة إليها؛ مثلًا، عند إلغاء تثبيت برنامج. 6- انتبِه لإعداد الأذون تمثّل صلاحيّات الملفّات مصدرًا كبيرًا للجزع لدى كثير من المستخدمين؛ فقد يكون من الصّعب العثور على نقطة توازن بحيث يُمكن للمستخدِم أداء عمله دون أن يعرّض نفسه أو النّظام للخطر. يحتاج هذا الأمر إلى الانتباه والتّفكير في كلّ سيناريو ممكن. يجب التّفكير في سيّاسة أمنيّة تضبُط umask (الخاصّيّة الّتي تحدّد الأذون الافتراضيّة للملفّات والمجلّدات الجديدة) بما يُناسِب؛ الأمر الّذي يُشكّل خطوة كبيرة على الطّريق الصّحيح. المقال التّالي يتطرّق لكيفيّة ضبط umask. القاعدة العامّة هي ألّا تضبط إذن الكتابة على أي ملفّ إلّا إذا كان ذلك ضروريًّا، خصوصًا إذا أمكن الوصول للملفّ عبر الإنترنت، لما قد ينتُج عنه من عواقب. إضافةً لذلك، يجب ألّا تُعدّل على بت SGID أو SUID، إلّا إذا كنت تدرك جيّدًا ما تفعل. تحقّق أيضًا من أنّ كلّ الملفّات لديها مالِك ومجموعة. يتغيّر إعداد الأذون كثيرًا حسب الحاجة، ولكن يجب دائمًا محاولة العثور على طريقة لتلبيّة الحاجة بأقل أذون ممكن. ينبغي الانتباه إلى سهولة الخطأ في إعداد الأذون، ووجود العديد من النّصائح الخاطئة حولها على الإنترنت. كيف تؤمِّن برنامجًا تستخدمه لا يكفي حجم هذا المقال للتّطرّق لخصوصيّات تأمين كلّ نوع من البرامج أو الخدمات، إلّا أنّه توجد العديد من الدّروس والأدلّة المتاحة على الشّبكة. يجب أن تقرأ النّصائح الأمنيّة لكلّ برنامج تريد إعداده للعمل على جهازك. بالنّسبة لبرامج الخادوم الشّهيرة مثل خواديم الويب ونُظُم إدارة قواعد البيانات، توجد مواقع ويب وقواعد بيانات كاملة مخصَّصة للأمان. على العموم، يجب أن تقرأ حول تأمين كلّ خدمة قبل إعدادها وتشغيلها. خاتمة يجب أن تكون لديك الآن معرفة جيّدة بالإجراءات الأمنيّة الممكن إعدادها على خادوم لينكس. حاولنا في هذا الدّليل التّعرّض للعديد من المجالات ذات الأهميّة الكبيرة، ولكن في نهاية المطاف ستحتاج اتّخاذ قرارات بنفسك. يتوجب عليك، بوصفك مديرًا للنّظام؛ تحمّل مسؤوليّاتك في تأمين الخادوم. تأمين الخادوم ليس إجراءً يُؤدّى مرةً واحدة، لكنّه عملّية مستمرّة تتضمّن فحص النّظام باستمرار، إعداد الحلول، التحقّق من السّجلاّت والتّنبيهات، إعادة تعريف الاحتيّاجات، …إلخ. اليقظة واستمرار تقويم ومراقبة الإجراءات المتَّبعة أمور ضروريّة للحفاظ على الأمن. ترجمة بتصرّف لمقال An Introduction to Securing your Linux VPS لصاحبه Justin Ellingwood.

NAT، أو نقل عنوان الشبكة network address translation، عبارة عن مصطلح عام لإدارة الرُّزَم packets من أجل إعادة توجيهها إلى عنوان بديل، وهو يُستخدم عادةً للسماح لحركة مرور البيانات traffic بتجاوز حدود الشبكة، يمتلك المُضيف host الذي يُطبِّق NAT نفاذًا إلى شبكتين أو أكثر بشكل نموذجي وهو مُعَد لنقل حركة مرور البيانات بينها. إعادة توجيه المنافذ Port forwarding هو عمليّة إعادة توجيه الطلبات لمنفذ مُعيَّن إلى مُضيف آخر، شبكة، أو منفذ. وبينما تقوم هذه العمليّة بتعديل وجهة الرُّزَم أثناء نقلها، فهي تُعتبَر نوع من عمليّات NAT. سنشرح في هذا الدرس كيفيّة استخدام iptables لإعادة توجيه المنافذ إلى مضيفين خلف جدار ناري باستخدام تقنيات NAT، يكون هذا مفيدًا في حال قمنا بإعداد شبكة خاصّة Private Network ولا زلنا نريد السماح لبعض حركة مرور البيانات بالمرور عبر جهاز مُحدّد كبوّابة gateway، سنستخدم مُضيفين اثنين يعملان على نظام Ubuntu لتوضيح هذا. المتطلبات الأساسية والأهداف لمتابعة هذا الدّرس تحتاج إلى مُضيفين اثنين يعملان على نظام Ubuntu في نفس مركز البيانات مع تمكين الشبكات الخاصّة private networking، نحتاج إلى إعداد حساب مُستخدِم غير جذري non-root مع صلاحيّات sudo على كل من هذين الجهازين، تستطيع معرفة كيفيّة إعداد مُستخدِم مع صلاحيّات sudo باتّباع درس الإعداد الأولي لخادوم Ubuntu. سيعمل المُضيف الأول كجدار ناري ومُوجِّه router لأجل الشبكة الخاصّة، ولأغراض توضيحيّة سيكون المُضيف الثاني مُعدًّا مع خادوم ويب قابل للوصول فقط باستخدام واجهته الخاصّة، سنقوم بإعداد جهاز الجدار الناري ليُعيد توجيه الطلبات التي يتلقّاها على واجهته العامّة إلى خادوم الويب حيث ستصل إلى واجهته الخاصّة. تفاصيل المضيف نحتاج قبل البدء أن نعرف الواجهات والعناوين التي يتم استخدامها من قِبَل كلا الخادمين لدينا. العثور على تفاصيل شبكتنا للحصول على تفاصيل أنظمتنا نبدأ بإيجاد واجهات شبكاتنا Network Interfaces، نستطيع العثور على الواجهات والعناوين المرتبطة بها على أجهزتنا بكتابة: 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 198.51.100.45/18 brd 45.55.191.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.168.1.5/16 brd 10.132.255.255 scope global eth1 valid_lft forever preferred_lft forever يُظهِر الخَرْج output السّابق واجهتين (eth0 و eth1) والعناوين المُخصّصة لكل منهما (192.51.100.45 و 192.168.1.5 على الترتيب)، ولمعرفة أيّ الواجهتين هي الواجهة العامّة نكتب: ip route show | grep default default via 111.111.111.111 dev eth0 تكون الواجهة الظاهرة أمامنا (eth0 في هذا المثال) هي الواجهة المُتصلة إلى بوّابتنا الافتراضيّة، وهي بكل تأكيد واجهتنا العامّة. قم بإيجاد هذه القيم على كل جهاز لديك واستخدمها للمتابعة مع هذا الدّرس بشكل صحيح. عينة بيانات من أجل هذا الدرس لكي نجعل متابعة هذا الدّرس أسهل سنستخدم العناوين الوهميّة وتعيينات الواجهة التالية، قم بوضع القيم الخاص بك بدلًا من هذه القيم: تفاصيل شبكة خادوم الويب: عنوان IP العام Public IP Address: 203.0.113.2 عنوان IP الخاص Private IP Address: 192.0.2.2 الواجهة العامّة Public Interface: eth0 الواجهة الخاصّة Private Interface: eth1 تفاصيل شبكة الجدار الناري: عنوان IP العام Public IP Address: 203.0.113.15 عنوان IP الخاص Private IP Address: 192.0.2.15 الواجهة العامّة Public Interface: eth0 الواجهة الخاصّة Private Interface: eth1 إعداد خادوم الويب سنبدأ بإعداد مُضيف خادوم الويب، نقوم بتسجيل الدخول كمستخدم sudo للبدء. تثبيت Nginx الخطوة الأولى التي سنقوم بها هي تثبيت Nginx على مُضيف خادوم الويب لدينا وقفله بحيث يستمع فقط إلى واجهته الخاصّة، يجعلنا هذا متأكدين من أنّ خادوم الويب لن يكون متوفّرًا إلّا إذا ضبطنا إعادة توجيه المنافذ بشكل صحيح. نبدأ بتحديث الذاكرة المؤقتة للحزم المحليّة local package cache باستخدام الأمر apt لتنزيل وتثبيت Nginx: webserver $ sudo apt-get update webserver $ sudo apt-get install nginx تقييد Nginx إلى الشبكة الخاصة بعد تثبيت Nginx نقوم بفتح ملف إعدادات كتلة block الخادوم الافتراضيّة للتأكد من أنّه يستمع فقط إلى واجهته الخاصّة، نفتح الملف عن طريق الأمر التالي: webserver $ sudo nano /etc/nginx/sites-enabled/default نبحث بداخله عن الأمر التوجيهي listen، ينبغي أن نجده في سطرين متتاليين في أعلى ملف الإعدادات: etc/nginx/sites-enabled/default/ server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; . . . } نقوم عند الأمر التوجيهي listen الأول بإضافة عنوان IP الخاص لخادوم الويب لدينا مع نقطتين قبل 80 لنُخبِر Nginx أن يستمع فقط إلى واجهته الخاصّة، سنوضّح في هذا الدّرس إعادة توجيه IPv4 فقط، لذا نستطيع إزالة الأمر التوجيهي listen الثاني المُعَد من أجل IPv6. سنقوم في مثالنا بتعديل الأمر التوجيهي listen بحيث يبدو كما يلي: etc/nginx/sites-enabled/default/ server { listen 192.0.2.2:80 default_server; . . . } عند الانتهاء نحفظ الملف ونغلقه، نختبر الملف بحثًا عن أخطاء الصياغة syntax بكتابة ما يلي: webserver $ sudo nginx -t إن لم تظهر أيّة أخطاء نُعيد تشغيل خادوم Nginx لتمكين الإعدادات الجديدة: webserver $ sudo service nginx restart التحقق من تقييد الشبكة Network Restriction من المُفيد عند هذه النقطة التحقّق من مستوى النفاذ الذي نملكه لخادوم الويب لدينا. إن قمنا بمحاولة النفاذ لخادوم الويب عبر واجهته الخاصّة من خلال خادوم الجدار الناري firewall ينبغي أن ينجح هذا: firewall $ curl --connect-timeout 5 192.0.2.2 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> . . . أمّا إن قمنا باستخدام الواجهة العامّة سنجد أنّنا لن نستطيع الاتصال: firewall $ curl --connect-timeout 5 203.0.113.2 curl: (7) Failed to connect to 203.0.113.2 port 80: Connection refused وهو بالضبط ما نتوقّع حدوثه. إعداد الجدار الناري لإعادة توجيه المنفذ 80 نستطيع الآن العمل على تنفيذ إعادة توجيه المنافذ على جهاز الجدار الناري. تمكين إعادة التوجيه في النواة Kernel الأمر الأول الذي يجب فعله هو تمكين إعادة التوجيه على مستوى النّواة، تكون إعادة التوجيه غير مُشغَّلة في مُعظم الأنظمة. ولتشغيل إعادة توجيه المنافذ لأجل هذه الجلسة فقط نكتب: firewall $ echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward ولتشغيل إعادة توجيه المنافذ بشكل دائم ينبغي علينا تحرير الملف etc/sysctl.conf/، نفتح الملف بصلاحيّات sudo بكتابة: firewall $ sudo nano /etc/sysctl.conf نبحث بداخله عن السطر التالي ونقوم بإزالة التعليق uncomment عنه: etc/sysctl.conf/ net.ipv4.ip_forward=1 عند الانتهاء نحفظ الملف ونغلقه، نقوم بتطبيق الإعدادات في هذا الملف بكتابة ما يلي: firewall $ sudo sysctl -p firewall $ sudo sysctl --system إعداد الجدار الناري الأساسي سنستخدم الجدار الناري الموجود في هذا الدّرس كإطار عمل أساسي من أجل القواعد، قم بتنفيذ التعليمات في درس كيفية إعداد جدارٍ ناريّ باستخدام iptables، وبعد الانتهاء يجب أن تكون قد: قمت بتثبيت iptables-persistent حفظت مجموعة القواعد الافتراضيّة في etc/iptables/rules.v4/ تعلّمت كيفيّة إضافة أو ضبط القواعد عن طريق تحرير ملف القواعد أو باستخدام الأمر iptables بعد أن تقوم بإعداد الجدار الناري الأساسي أكمل الخطوات التالية لكي تستطيع ضبطه من أجل إعادة توجيه المنافذ. إضافة قواعد إعادة التوجيه نريد أن نضبط جدارنا الناري بحيث تتم إعادة توجيه حركة مرور البيانات traffic المُتدفّقة لواجهتنا العامّة (eth0) إلى واجهتنا الخاصّة (eth1). يمتلك جدارنا الناري الأساسي السلسلة FORWARD مُعدّة افتراضيًّا لكي تستبعد DROP حركة مرور البيانات، نحتاج لإضافة قواعد تسمح لنا بإعادة توجيه الاتصالات لخادوم الويب لدينا، ولأغراض أمنية سنقوم بتحديد هذا بشكل مُحكَم بحيث يتم فقط السماح للاتصالات التي نرغب بإعادة توجيهها. سنقبل في السلسلة FORWARD الاتصالات الجديدة المتجهة للمنفذ 80 والقادمة من واجهتنا العامة مُغادرةً إلى واجهتنا الخاصة، يتم تحديد الاتصالات الجديدة بواسطة اللاحقة conntrack ويتم تمثيلها بشكل خاص بواسطة رُزمة TCP SYN: firewall $ sudo iptables -A FORWARD -i eth0 -o eth1 -p tcp --syn --dport 80 -m conntrack --ctstate NEW -j ACCEPT سيسمح هذا للرزمة الأولى المعنيّة بإنشاء الاتصال بالعبور من خلال الجدار الناري، نحتاج أيضًا للسماح بأي حركة مرور بيانات لاحقة في كلا الاتجاهين والتي تنتج عن هذا الاتصال، نكتب ما يلي للسماح بحركة مرور البيانات التي تُنشئ هذا الاتصال ESTABLISHED والمتعلّقة به RLEATED بين واجهاتنا الخاصّة والعامة: firewall $ iptables -A FORWARD -i eth0 -o eth1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT firewall $ iptables -A FORWARD -i eth1 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT بإمكاننا إعادة التحقّق من أنّ سياساتنا على السلسلة FORWARD هي الاستبعاد DROP بكتابة ما يلي: firewall $ sudo iptables -P FORWARD DROP عند هذه النقطة سمحنا بحركة مرور بيانات مُحدّدة بين واجهاتنا الخاصّة والعامّة بالمرور من خلال الجدار الناري لدينا، ومع ذلك لم نقم بضبط القواعد التي تُخبِر iptables فعليًّا كيف يقوم بنقل وتوجيه حركة مرور البيانات. إضافة قواعد NAT لتوجيه الرزم بشكل صحيح سنضيف الآن القواعد التي تُخبِر iptables كيف يقوم بتوجيه حركة مرور بياناتنا، نحتاج لتنفيذ عمليتين منفصلتين من أجل أن يقوم iptables بتغيير الرُّزَم بشكل صحيح بحيث يتمكّن العملاء من التواصل مع خادوم الويب. تحدث العمليّة الأولى التي تُدعى DNAT في السلسلة PREROUTING من جدول nat، وهي عمليّة تقوم بتبديل عنوان وجهة الرُّزَم لتمكينها من التوجه بشكل صحيح عندما تمر بين الشبكات، سيتصل العملاء على الشبكة العامّة إلى خادوم الجدار الناري لدينا بدون أن يعلموا عن بُنية الشبكة الخاصّة لدينا، نحتاج لتبديل عنوان الوجهة لكل رُزمة بحيث تعلم عند إرسالها خارج شبكتنا الخاصّة كيف تصل بشكل صحيح إلى خادوم الويب. بما أنّنا نقوم فقط بإعداد إعادة توجيه المنافذ ولا نقوم بعمل NAT على كل رُزمة تصطدم بجدارنا الناري فيجب علينا أن نُطابِق المنفذ 80 في قاعدتنا، سنقوم بمطابقة الرُّزَم التي تستهدف المنفذ 80 إلى عنوان IP الخاص لخادوم الويب لدينا (192.0.2.2 في مثالنا): firewall $ sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.0.2.2 يهتم هذا بنصف الحل، فينبغي الآن أن يتم توجيه الرُّزَم بشكل صحيح إلى خادوم الويب لدينا، ومع ذلك فإنّ الرُّزَم لا تزال تملك العنوان الأصلي للعميل كعنوان مصدر، وسيحاول الخادوم إرسال الرد مباشرة إلى ذلك العنوان، ممّا يجعل من المستحيل تأسيس اتصال TCP قانوني. نحتاج من أجل ضبط التوجيه المناسب أن نقوم بتعديل عنوان المصدر للرُزَم عندما تغادر الجدار الناري في طريقها إلى خادوم الويب، يجب علينا تعديل عنوان المصدر وتغييره إلى عنوان IP الخاص لخادوم الجدار الناري لدينا (في مثالنا 192.0.2.15)، سيتم عندها إرسال الرّد إلى الجدار الناري والذي يستطيع إعادة توجيهه إلى العميل كما هو متوقّع. ولتمكين هذه الوظيفة سنضيف قاعدة إلى سلسلة POSTROUTING من جدول nat، والتي يتم تقييمها مباشرة قبل إرسال الرُّزَم على الشبكة، سنطابق الرُّزَم الموجّهة إلى خادوم الويب عن طريق عنوان IP والمنفذ: firewall $ sudo iptables -t nat -A POSTROUTING -o eth1 -p tcp --dport 80 -d 192.0.2.2 -j SNAT --to-source 192.0.2.15 حالما يتم إعداد هذه القاعدة ينبغي أن يصبح خادوم الويب لدينا قابل للنفاذ عن طريق توجيه متصفّح الويب لدينا إلى العنوان العام لجهاز الخادوم الناري: curl 203.0.113.15 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> . . . اكتمل هنا إعداد إعادة توجيه المنافذ. ضبط مجموعة القواعد الدائمة نستطيع الآن بعد أن قمنا بإعداد إعادة توجيه المنافذ أن نحفظه في مجموعة قواعد دائمة. إن لم تكن تهتم بفقدان التعليقات الموجودة في مجموعة القواعد الحالية لديك فاستخدم الخدمة iptables-persistent لحفظ قواعدك: firewall $ sudo service iptables-persistent save إن كنت ترغب بالحفاظ على التعليقات في ملفّك، فقم بفتحه وتحريره يدويًّا: firewall $ sudo nano /etc/iptables/rules.v4 سنحتاج إلى ضبط الإعدادات في الجدول filter من أجل قواعد السلسلة FORWARD التي تمّت إضافتها، يجب علينا أيضًا ضبط القسم الذي يقوم بإعداد الجدول nat كي نستطيع إضافة القواعد PREROUTING و POSTROUTING، سيبدو هذا في مثالنا مُشابِهًا لما يلي: 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 # Rules to forward port 80 to our web server # Web server network details: # * Public IP Address: 203.0.113.2 # * Private IP Address: 192.0.2.2 # * Public Interface: eth0 # * Private Interface: eth1 # # Firewall network details: # # * Public IP Address: 203.0.113.15 # * Private IP Address: 192.0.2.15 # * Public Interface: eth0 # * Private Interface: eth1 -A FORWARD -i eth0 -o eth1 -p tcp --syn --dport 80 -m conntrack --ctstate NEW -j ACCEPT -A FORWARD -i eth0 -o eth1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT -A FORWARD -i eth1 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # End of Forward filtering rules # 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] # Rules to translate requests for port 80 of the public interface # so that we can forward correctly to the web server using the # private interface. # Web server network details: # * Public IP Address: 203.0.113.2 # * Private IP Address: 192.0.2.2 # * Public Interface: eth0 # * Private Interface: eth1 # # Firewall network details: # # * Public IP Address: 203.0.113.15 # * Private IP Address: 192.0.2.15 # * Public Interface: eth0 # * Private Interface: eth1 -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.0.2.2 -A POSTROUTING -d 192.0.2.2 -o eth1 -p tcp --dport 80 -j SNAT --to-source 192.0.2.15 # End of NAT translations for web server traffic 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 قم بحفظ الملف وأغلقه بعد إضافة ما سبق وضبط القيم لكي تنطبق على بيئة شبكتك الخاصّة. نختبر صياغة ملف القواعد لدينا بكتابة: firewall $ sudo iptables-restore -t < /etc/iptables/rules.v4 إن لم يتم اكتشاف أيّة أخطاء نقوم بتحميل مجموعة القواعد: firewall $ sudo service iptables-persistent reload نختبر أنّ خادوم الويب لدينا لا يزال قابل للنفاذ من خلال عنوان IP العالم للجدار النّاري: firewall $ curl 203.0.113.15 ينبغي لهذا أن يعمل كما عمل سابقًا. الخاتمة ينبغي الآن أن نكون متآلفين مع إعادة توجيه المنافذ على خادوم لينِكس باستخدام iptables، تتضمّن العملية السماح بإعادة التوجيه على مستوى النّواة، إعداد النفاذ للسماح بإعادة التوجيه لحركة مرور البيانات لمنافذ مُحدّدة بين واجهتين على نظام الجدار النّاري، وضبط قواعد NAT بحيث يُمكِن توجيه الرُّزَم بشكل صحيح، ربّما تبدو هذه عمليّة صعبة، ولكنّها تُوضّح أيضًا مرونة إطار عمل ترشيح الرُّزَم netfilter وجدار iptables النّاري، يُمكِن استخدام هذا لتمويه بُنية الشبكة الخاصّة لدينا مع السمّاح بحركة مرور البيانات للخدمات بالمرور بشكل حر عبر بوّابة جهاز الجدار النّاري. ترجمة -وبتصرّف- لـ How To Forward Ports through a Linux Gateway with Iptables لصاحبه Justin Ellingwood.

تنفيذ جدار الحماية هو خطوة هامة في تأمين الخادوم الخاص بك. جزء كبير من عملية التنفيذ هو اتخاذ قرارات بشأن القواعد والسياسات التي تفرض قيودا على حركة مرور البيانات. يسمح لك الجدار الناري أن يكون لك دور في بنية إطار العمل الذي يتم فيه تطبيق القواعد الخاصة بك. في هذا الدليل سوف نبني جدار حماية ليكون أساسا للمزيد من القواعد المعقدة. وسيركز هذا الجدار الناري في المقام الأول على تقديم افتراضات معقولة ووضع إطار سهل التمدد. سيكون تطبيق هذا الدليل على أوبنتو 14.04. المتطلبات الأساسية قبل أن تبدأ يجب أن تكون لك فكرة قاعدية حول سياسات جدار الحماية التي ترغب في تنفيذها. يمكنك اتباع هذا الدليل للحصول على فكرة أفضل عن بعض الأشياء التي يجب أن تنظر فيها. سوف تحتاج إلى أن يكون لك حق الوصول إلى خادوم أوبنتو 14.04 بمستخدم عادٍ يكون له صلاحيات الجذر. تثبيت خدمة جدار الحماية الثابتة لكي نبدأ نحتاج إلى تثبيت الحزمة iptables-persistent إذا لم تكن قد فعلت ذلك من قبل. سيسمح هذا لنا بحفظ مجموعات القواعد ويجعل تنفيذها تلقائيا عند تشغيل النظام: sudo apt-get update sudo apt-get install iptables-persistent أثناء التثبيت سوف تُسأل عما إذا كنت تريد حفظ القواعد الحالية الخاصة بك، أجب بنعم. سوف نقوم بتحرير ملفات القواعد المولدة لاحقا. ملاحظة حول IPv6 قبل أن نبدأ يجب أن نتحدث بإيجاز عن عناوين IPv4 و IPv6. تعالج أوامر iptables فقط المرور عبر IPv4. وأما حركة المرور عبر IPv6 فيتم باستخدام أداة منفصلة تسمى ip6tables. يتم تخزين القواعد في جداول وسلاسل منفصلة. بالنسبة لـ iptables-persistent فتتم كتابة قواعد IPv4 في الملف etc/iptables/rules.v4/ وقواعد IPv6 في الملف etc/iptables/rules.v6/. يفترض هذا المقال أنك لا تستخدم البروتوكول IPv6 على الخادوم الخاص بك. إذا كان الأمر كذلك فالأكثر أمانا هو منع الوصول عبره تماما، وذلك ما سنقوم به في هذه الدليل. تنفيذ السياسات الأساسية لجدار الحماية (الطريق الأسرع) من أجل تنفيذ تلك السياسات على جدار الحماية في أسرع وقت ممكن سوف ندلك على ملف إعدادات يحتوي تلك السياسات، ثم ما عليك بعدُ إلا بالنسخ واللصق. بعد ذلك سوف نشرح الاستراتيجية العامة ونبين لك كيف يمكن تنفيذ هذه القواعد باستخدام أوامر iptables بدلا من تعديل الملف. لتنفيذ سياسات جدار الحماية وإطار العمل الخاص به سوف نقوم بتحرير الملفين etc/iptables/rules.v4/ و etc/iptables/rules.v6/. افتح أولا الملف rules.v4 في محرر النص المفضل لديك بصلاحيات الجذر: sudo nano /etc/iptables/rules.v4 سترى داخل هذا الملف مثل هذه الأسطر: # Generated by iptables-save v1.4.21 on Tue Jul 28 13:29:56 2015 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT # Completed on Tue Jul 28 13:29:56 2015 اُمحُ هذا المحتوى واستبدله بالمحتوى التالي: *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 احفظ ثم أغلق الملف. يمكنك اختبار الملف من أجل اكتشاف الأخطاء التي يمكن أن تكون في التركيب بالأمر التالي: sudo iptables-restore -t /etc/iptables/rules.v4 يجب عليك إصلاح أي خطأ يظهر لك قبل المتابعة. بعد ذلك افتح الملف etc/iptables/rules.v6/ من أجل تعديل قواعد IPv6: sudo nano /etc/iptables/rules.v6 يمكننا أن نمنع كل الحزم التي تستخدم البروتوكول IPv6 باستبدال محتوى الملف بالإعدادات التالية: *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] COMMIT *raw :PREROUTING DROP [0:0] :OUTPUT DROP [0:0] COMMIT *nat :PREROUTING DROP [0:0] :INPUT DROP [0:0] :OUTPUT DROP [0:0] :POSTROUTING DROP [0:0] COMMIT *security :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] COMMIT *mangle :PREROUTING DROP [0:0] :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] :POSTROUTING DROP [0:0] COMMIT احفظ ثم أغلق الملف. من أجل اختبار الملف ومعرفة إن كان فيه أخطاء نستعمل الأمر ip6tables-restore مع الخاصية t-: sudo ip6tables-restore -t /etc/iptables/rules.v6 إذا لم نجد أي خطأ في الملفين السابقين فلْنطبق تلك القواعد بتنفيذ الأمر: sudo service iptables-persistent reload سيقوم هذا الأمر بتنفيذ السياسات التي يتضمنها الملفان فورا. يمكنك التأكد من ذلك بسرد قواعد iptables الحالية بالأمرين: sudo iptables -S sudo ip6tables -S سوف يعاد تطبيق هذه القواعد في كل إقلاعٍ للنظام. تأكد أنه يمكنك الولوج عبر المنفذ 22 وأن كل المنافذ الأخرى محجوبة. شرح لاستراتيجيتنا العامة في الجدار الناري لقد أنشانا في جدار الحماية القاعدي الذي قمنا ببنائه مع القواعد السابقة أنشأنا إطارَ عمل قابلا للتمدد يمكّنك من إضافة قواعد جديدة أو حذفها بسهولة. أما حركة المرور التي تستخدم العنوان IPv4 فقد عالجناها في السلسلة INPUT داخل الجدول filter table ( تعالج هذه السلسلة كل الحزم التي تصل إلى خادومنا) فسمحنا بخروج الحزم من خادومنا ومنعنا إعادة توجيهها -إذ كان ذلك مناسبا فقط في حال كان الخادوم يعمل موجها router لخوادم أخرى- وقبِلنا الحزم على الجداول الأخرى بما أن نظرنا محصور في filter table في هذا الدليل. عموما تقوم القواعد التي طبقناها على الجدار الناري بمنع الحزم من الوصول إلى خادومنا افتراضيا ، سيكون علينا أن نضع استثناءات من أجل الحزم التي نريدها أن لا تدخل في سياسة الحجب. في السلسلة INPUT الرئيسة أضفنا بعض القواعد العامة لحركة المرور التي نثق بها. ما نريده الآن هو حجب كل الحزم التي نعتبرها غير صالحة ونسمح للحزم على واجهة الاسترجاع المحلية local loopback interface والبيانات المرتبطة باتصال مؤسس established connection. بعد ذلك نقوم بمسك البيانات حسب البروتوكول الذي تستخدمه ونمزجها بسلاسل البروتوكول المخصص protocol-specific. تهدف هذه السلاسل إلى التعامل مع القواعد المتعلقة بها والسماح لحركة المرور الصادرة والقادمة إلى الخدمات المعينة. في هذا المثال الخدمة الوحيدة التي قمنا بربطها في سلسلتنا ذات البروتوكول TCP هي SSH. إذا كنا نعرض خدمة أخرى كخادوم (HTTP(S يمكننا إضافة استثناءات لها أيضا. كل حركةٍ للمرور لا تتناسب مع القواعد العامة أو قواعد الخدمات في البروتوكول المحدد protocol-specific سوف تتم معالجتها بالقواعد الموجودة في آخر سلسلة INPUT. لقد جعلنا السياسة الافتراضية للجدار الناري هي الإسقاط DROP، وذلك سيحجب الحزم التي لا تتصف بمعايير السماح حسب قواعدنا. تمنع هذه القواعد في نهاية السلسلة INPUT الحزم وترسل رسالة إلى العميل تحاكي ما يرسله الخادوم في حالِ لم تكن الخدمة متوفرة على ذلك المنفذ. وأما العنوان IPv6 فإن حركة المرور سوف تُحجَب كلها لأن خادومنا لا يستخدمه، ولأنه من الآمن فعل ذلك لكي لا نتورط في حركة المرور بشكل عام. تحديث nameservers (اختياري) يمكن لحركة المرور المحجوبة على العنوان IPv6 أن تتداخل وطريقةُ تعامل الخادوم مع الأشياء في الأنترنت. مثلا يمكن لذلك أن يؤثر في استخدام الأمر APT. إذا ظهر لك خطأ مثل هذا في حال نفذت الأمر apt-get update: Err http://security.ubuntu.com trusty-security InRelease Err http://security.ubuntu.com trusty-security Release.gpg Could not resolve 'security.ubuntu.com' . . . فينبغي عليك أن تتبع هذه الطريقة لكي تجعل APT يعمل مرة أخرى. أولا اضبط nameservers الخاصة بخادومك إلى nameservers الخارجية، سنستخدم في حالتنا nameservers الخاصة بغوغل. افتح الملف etc/network/interfaces/ من أجل تعديله بالأمر: sudo nano /etc/network/interfaces ثم عدل السطر الذي أوله dns-nameservers على الطريقة التالية: . . . iface eth0 inet6 static address 2604:A880:0800:0010:0000:0000:00B2:0001 netmask 64 gateway 2604:A880:0800:0010:0000:0000:0000:0001 autoconf 0 dns-nameservers 8.8.8.8 8.8.4.4 حدّث إعدادات الشبكة بالأمر: sudo ifdown eth0 && sudo ifup eth0 الناتج المتوقع هو: RTNETLINK answers: No such process Waiting for DAD... Done بعد ذلك أنشئ قاعدة جديدة من أجل إرغام حركة المرور أن تستخدم العنوان IPv4 متى كان ذلك ممكنا. أنشئ هذا الملف الجديد: sudo nano /etc/apt/apt.conf.d/99force-ipv4 ثم أضف هذا السطر إليه: Acquire::ForceIPv4 "true"; احفظ ثم أغلق، ينبغي أن تكون الآن قادرا على استخدام ATP. تنفيذ الجدار الناري باستخدام أوامر IPTables لقد تبين لك كيف قمنا بتنفيذ الجدار الناري وسياساته وعرفت كيف تعمل، في المرحلة القادمة سنقوم بتطبيق تلك السياسات باستخدام أوامر iptables وسنحصل في الأخير على ما حصلنا عليه فيما سبق. ولكن سيكون إضافة تلك السياسات واحدة تلو الأخرى لأن iptables يطبق كل قاعدة في وقت تنفيذ الأمر ، لذلك فإن ترتيب القواعد مهم جدا (سوف ندع القواعد التي تحجب إلى النهاية). إعادة ضبط الجدار الناري سنبدأ بإعادة ضبط الجدار الناري لكي نستطيع بناء السياسات من سطر الأوامر . يمكنك إلغاء القواعد السابقة بالأمر: sudo service iptables-persistent flush تأكد أن الجدار الناري أعيد ضبطه بالأمر: sudo iptables -S سترى أن القواعد في الجدول filter table قد اختفت وأن السياسات الافتراضية قد أُعدت للوضع ACCEPT في كل السلاسل: -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT إنشاء سلاسل البروتوكول المخصص سنبدأ بإنشاء سلاسل البروتوكول المخصص protocol-specific. ستُستعمل هذه السلاسل للتحكم في القواعد التي تُنشِئ استثناءات في سياسات الحجب فتجعل خدماتنا ظاهرة في الشبكة. سوف ننشئ واحدة من أجل البروتوكول UDP ، واحدة للبروتوكول TCP وواحدة للبروتوكول ICMP: sudo iptables -N UDP sudo iptables -N TCP sudo iptables -N ICMP يمكننا الذهاب قدما فنضيف استثناء للخدمة SSH التي تستخدم البروتوكول TCP. سيكون ذلك بقبول حركة المرور على المنفذ 22 الخاص بالخدمة SSH: sudo iptables -A TCP -p tcp --dport 22 -j ACCEPT إذا كنت تريد إضافة استثناءات لخدمات أخرى تستخدم البروتوكول TCP فما عليك سوى تكرار الأمر السابق مع تغيير رقم المنفذ الذي تستخدمه الخدمة. إنشاء قواعد للأغراض العامة للحجب والقبول في السلسلة INPUT -حيث تفلتر كل الحزم القادمة- نحتاج إلى إضافة قواعد للأغراض العامة. تشكل تلك القواعد حجر الأساس للجدار الناري وتتبع المنطق السليم إذ تقبل حركة المرور الأقل خطورة (حركة المرور المحلية أو التي تأكدنا من موثوقية مصدرها) وتحجب تلك الموصوفة بأنها غير صالحة. أولا سننشئ استثناء لكي نقبل كل الحزم التي هي جزء من اتصال مؤسَّس established connection أو لها علاقة باتصال مؤسس: sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT تستخدم هذه القاعدة الملحق conntrack الذي يقدم سياقا يحتاج إليه iptables لمعالجة حزم الاتصالات الكبيرة بدل استخدامه للبيانات المنفصلة. TCP هو بروتوكول اتصال ، لذلك فإن كونه اتصالا مؤسَّسا لا غبار عليه. وأما UDP والبروتوكولات عديمة الاتصال فالاتصال المؤسس يشير إلى الحزم التي ترى جوابها (مصدر الحزمة هو نفسه الهدف المقصود والعكس بالعكس ). وأما الاتصالات ذات الصلة فتشير إلى اتصال جديد يُربط مع اتصال مؤسس. المثال الكلاسيكي هنا هو اتصال نقل البيانات ftp، حيث يربط هذا الاتصال الجديد بالاتصال المؤسس سابقا وهو FTP control connection. نريد أيضا أن نسمح لحركة المرور التي نشأت على واجهة الاسترجاع المحلية local loopback interface. هذه الحزم وُلّدت من قبل الخادوم ومتجهة إلى الخادوم نفسه. يتم استخدامها من قبل الخدمات على جهاز النظام للتواصل مع بعضها البعض: sudo iptables -A INPUT -i lo -j ACCEPT وأخيرا نريد حجب كل الحزم غير الصالحة. تكون الحزم غير صالحة للعديد من الأسباب. منها التي تكون وجهتها اتصالات أو عناوين أو منافذ غير موجودة، أو ببساطة لم يَحسُن تهيئتها. في كل الأحوال سوف نمنع أمثال هذه الحزم لأنه لا سبيل إلى معالجتها أو لأنها مغلفة لشيفرات خبيثة: sudo iptables -A INPUT -m conntrack --ctstate INVALID -j DROP إنشاء الانتقال السريع إلى سلاسل البروتوكول المخصص حتى الآن لقد أنشأنا بعض القواعد العامة في سلسلة INPUT وبعض القواعد للخدمات المقبولة في سلاسل البروتوكول المخصص. ومع ذلك فالبيانات القادمة إلى السلسلة INPUT ليس لديها وسيلة للوصول إلى تلك السلاسل. نحن بحاجة إلى توجيه حركة البيانات في سلسلة INPUT إلى سلاسل البروتوكول المخصص التي تناسبها. يمكننا البحث عن نوع البروتوكول لكي نعرف أي سلسلة تناسب هذه الحزمة. ويجب التأكد من أن الحزمة تمثل اتصالا جديدا (يفترض أنه تم بالفعل التعامل مع أي اتصال مؤسس أو له علاقة به). بالنسبة لحزم TCP سوف نقوم بإضافة شرط إضافي وهو أن تكون الحزمة SYN، والذي هو النوع الوحيد الصالح لبدء اتصال TCP: sudo iptables -A INPUT -p udp -m conntrack --ctstate NEW -j UDP sudo iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP sudo iptables -A INPUT -p icmp -m conntrack --ctstate NEW -j ICMP رفض كل حركة المرور الأخرى إذا كانت الحزمة التي تم تمريرها الى سلسلة البروتوكول المخصص لم تعثر على أية قواعد فسيتم إعادة التحكم بها إلى السلسة INPUT. ما يصل إلى هذا النقطة ينبغي أن لا يسمح به جدار الحماية. سوف نحجب حركة المرور باستخدام الهدف REJECT الذي يرسل رسالة رد إلى العميل. و يتيح هذا لنا تحديد الرسائل الصادرة حتى نتمكن من محاكاة الرد كما لو كان العميل حاول إرسال الحزم إلى المنافذ المغلقة. يكون الرد حسب البروتوكول الذي يتم استخدامه من قبل العميل. محاولة الوصول إلى منفذ UDP المغلق يؤدي إلى رسالة ICMP مضمونها "لا يمكن الوصول إلى المنفذ” ، يمكننا محاكاة ذلك بتنفيذ الأمر: sudo iptables -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable محاولة إنشاء اتصال TCP على منفذ مغلق سيؤدي إلى جواب TCP RST: sudo iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset وأما جميع الحزم الأخرى فيمكننا إرسال رسالة ICMP "تعذر الوصول إلى البروتوكول" للإشارة إلى أن الخادوم لا يرد على حزم من هذا النوع: sudo iptables -A INPUT -j REJECT --reject-with icmp-proto-unreachable ضبط السياسات الافتراضية آخر ثلاث قواعد أضفناها ينبغي أن تتعامل مع جميع ما تبقى من حركة البيانات في السلسلة INPUT. ومع ذلك ينبغي لنا أن ننشئ السياسات الافتراضية للإسقاطـ DROP كإجراء احترازي. وينبغي أيضا أن تُحدد هذه السياسة في سلسلة FORWARD إذا لم يتم استخدام هذا الخادوم جهازَ توجيه إلى أجهرة أخرى: sudo iptables -P INPUT DROP sudo iptables -P FORWARD DROP تحذير مع إعدادك لسياسات الجدار الناري إلى DROP يكون استعمالك للأمر sudo iptables -F لغرض مسح iptables مسقطا لاتصال SSH الحالي ، الأحسن من ذلك أن تقوم بمسحه بالأمر sudo iptables-persistent flush، لأن ذلك سيعيد ضبط الجدار النار إلى الحال الفتراضي. ولكى نجعل سياسة IPv6 هي إسقاط كل حركةٍ للمرور يمكننا تنفيذ الأوامر التالية: sudo ip6tables -P INPUT DROP sudo ip6tables -P FORWARD DROP sudo ip6tables -P OUTPUT DROP ينبغي لهذه الأوامر أن تكرر القواعد التي أعددناها سابقا بشكل موثوق. حفظ قواعد IPTables في هذه المرحلة يجب فحص قواعد جدار الحماية للتأكد من أنها تمنع حركة المرور التي تريد منعها وتسمح لما تريد السماح له. عندما تكون متأكدا من أن الجدار الناري والقواعد يعملان بشكل صحيح يمكنك حفظ تلك القواعد ليتم تطبيقها عند كل إقلاع للنظام. يمكنك حفظ قواعد كل من IPv4 و IPv6 بتنفيذ الأمر: sudo service iptables-persistent save سيقوم هذا الأمر بالكاتبة فوق الملفين etc/iptables/rules.v4/ و etc/iptables/rules.v6/ بالسياسات التي نفذتها من خلال سطر الأوامر. الخلاصة باتباعك هذا الدليل -سواء من خلال وضع قواعد جدار الحماية مباشرة في ملفات الإعدادات أو يدويا باستخدام سطر الأوامر - قمتَ بإنشاء منطلق جيد لإعدادات الجدار الناري. يبقى عليك أن تضيف قواعد خاصة بك لتسمح بالوصول إلى خدماتك الأخرى على الخادوم. يسمح لك إطار العمل الذي أسسناه في هذا الدليل بأن تعدل كيفما تشاء ، وأيضا يجعل السياسات الموجودة أكثر وضوحا. ترجمة -وبتصرّف- للمقال How To Implement a Basic Firewall Template with Iptables on Ubuntu 14.04 لصاحبه Justin Ellingwood.

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

إعداد جدارٍ ناريّ قوي هو خطوةٌ أساسية يجب فعلها بهدف تأمين أيّ نظام تشغيلٍ حديث. تأتي معظم توزيعات لينكس بأدواتٍ مختلفة يمكننا استخدامها لضبط جداراتنا الناريّة. في هذا الدرس، سنتحدّث عن جدار iptables الناريّ. Iptables هو عبارة عن جدارٍ ناريّ عادي موجود في معظم توزيعات لينكس افتراضيًا (برنامجٌ آخر يدعى nftables سيبدأ قريبًا باستبداله). هو في الواقع عبارة عن واجهةٍ أمامية لخطّافات netfilter على مستوى النواة (kernel-level netfilter hooks) يمكنه التعامل مع مكدّس شبكة لينكس (Linux network stack). يعمل iptables عن طريق مطابقة كلّ حزمة (packet) تمرّ عبر الشبكة بمجموعة من القواعد (rules) التي تجعله يقرر ما يجب فعله. ملاحظة: يغطّي هذا الدرس أساسيات الحماية لـIPv4. في نظام لينكس، هناك فرق بين طرق الحماية لـIPv4 و IPv6. كمثال فإنّ iptables يقوم فقط بالتحكّم في قواعد جدار الحماية لعناوين IPv4 إلّا أنّه يمتلك برنامجًا خارجيًا يدعى ip6tables يمكن استخدامه للتحكّم في قواعد جدار الحماية لعناوين IPv6. إذا كان خادومك الافتراضي الخاصّ مُعدًّا ليستخدم IPv6، فرجاءً تذكّر حماية كلّ من واجهتيّ الشبكة IPv4 و IPv6 باستخدام الأدوات المناسبة. للمزيد من المعلومات عن أدوات IPv6، راجع هذا الدرس: كيفية ضبط بعض الأدوات لاستخدام IPv6 على نظام لينكس. أوامر iptables الأساسية الآن وبعد أن صار لديك المفاهيم الأساسية حول iptables، فإنّه يجب علينا تغطية الأوامر الأساسية التي سيتم استعمالها لتشكيل مجموعات قواعد iptables أكبر بالإضافة إلى إدارة واجهة iptables بشكلٍ عام. أولًا، يجب عليك أن تنتبه إلى أنّ أوامر iptables يجب أن يتم تشغيلها بصلاحيات الجذر (root privileges). هذا يعني أنّه يجب عليك الولوج إلى النظام باسم المستخدم root، استخدم su أو sudo -i للولوج إلى صدفة المستخدم الجذر، أو يمكنك ببساطة وضع sudo قبل جميع الأوامر التي ستطبّقها. سنستخدم sudo في هذا الدرس بما أنّها طريقة شائعة الاستخدام على نظام Ubuntu. نقطة جيدة للبداية بها هي كيفية سرد قواعد iptables المُستخدمة حاليًا. يمكنك فعل هذا باستخدام الخيار -L : $ sudo iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination كما يمكنك أن ترى، لدينا ثلاث سلاسل (chains) هنا. يمكننا أيضًا أن نرى السياسة المتّبعة في كلّ سلسلة (كل سلسلة افتراضيًا تمتلك سياسة ACCEPT للاتصالات المارّة منها). يمكننا أيضًا رؤية بعض ترويسات العواميد في ناتج الأمر السابق، إلّا أنّنا فعليًا لا نرى أيّ قواعد مطبّقة. هذا بسبب أنّ Ubuntu لا تأتي مع مجموعةٍ افتراضية من قواعد iptables. يمكننا رؤية الخرج بصيغةٍ تعكس الأوامر الضرورية لتفعيل كلّ قاعدة وسياستها عبر استخدام الخيار -S : $ sudo iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT لإعادة إنتاج الإعدادات وتطبيقها من جديد، سيجب علينا فقط كتابة الأمر sudo iptables متبوعًا بكلّ واحدٍ من السطور الظاهرة في الخرج. (اعتمادًا على الإعدادات، قد يكون الأمر أكثر تعقيدًا في حال كنّا متّصلين عن بعد إلى الخادوم حيث أننا لا نريد إضافة قواعد iptables معيّنة تمنع جميع الاتصالات الواردة إليها مثلًا دون استثناء اتّصالنا الحالي لكي لا ينقطع فجأة ولكي يبقى متّصلًا). إذا كان لديك قواعد بالفعل لديك في iptables وكنتَ ترغب بإتلافها والبدء من جديد، فيمكنك فعل ذلك عبر تطبيق: $ sudo iptables -F مرةً أخرى، سياسة قبول الاتصالات أو رفضها مهمّة هنا، لأنّه وبينما يتم حذف جميع القواعد الأخرى من السلاسل الخاصّة بك، فإنّ السياسة الافتراضية لن تتغيّر باستخدام هذا الأمر. هذا يعني أنّه في حال كنت متّصلًا عن بعد بخادومك، فإنّه يجب عليك التأكّد من أنّ السياسة الافتراضية لسلسلتيّ INPUT و OUTPUT هي ACCEPT بالتزامن مع قيامك بإتلاف قواعدك السابقة. يمكنك فعل ذلك عبر تطبيق الأوامر التاليّة: $ sudo iptables -P INPUT ACCEPT $ sudo iptables -P OUTPUT ACCEPT $ sudo iptables -F يمكنك تغيير سياسة الحظر أو الترك (drop) مجددًا إلى DROP بعد أن تقوم بإعداد القواعد التي تسمح ببقاء اتّصالك الحالي. سنفصّل كيفيّة ذلك بعد قليل. إنشاء قاعدتك الأولى سنبدأ ببناء سياسة جدار الحماية الخاصّ بن حول قبول أو رفض الاتصالات. كما قلنا أعلاه، فإنّنا سنعمل مع سلسلة INPUT بما أنّها المصدر الرئيسي لتدفّق الزوار القادم إلى خادومنا. سنبدأ مع القاعدة التي تحدّثنا عنها مسبقًا من قبل بالأعلى: القاعدة التي تسمح لنا بشكل خاص بمتابعة اتّصال SSH الحالي. القاعدة الكاملة التي نحتاج إليها هي هذه: $ sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT قد يبدو هذا معقّدا للغاية لك في الوهلة الأولى، إلّا أنّ معظم مكوّنات الأمر السابق ستكون ذات معنى بالنسبة لك عندما تفهمها: -A INPUT: يقوم الخيار -A بإضافة قاعدةٍ ما إلى نهاية السلسلة المطلوبة. هذا هو الجزء الذي يقوم بإخبار iptables بأنّنا نريد إضافة قاعدةٍ جديدة إلى سلسلة معيّنة، والسلسلة التي نريدها في مثالنا حاليًا هي سلسلة INPUT. -m conntrack: يمتلك iptables عدّة وظائف داخليّة، ولكنّه أيضًا يمتلك مجموعةً من الامتدادات والوحدات التي تقوم بتوفير مزايا إضافيّة. إنّنا نقوم في هذا الجزء من الأمر بإخبار iptables بأنّنا نريد الحصول على إذن بالوصول إلى الوظيفة التي يتم توفيرها عبر الوحدة المسماة "conntrack”. تعطينا هذه الوحدة وصولًا إلى الأوامر التي يمكن أن يتم استخدامها بناءً على علاقة حزمة البيانات الداخلة بالاتّصال السابق. --ctstate: هذا واحدٌ من الأوامر التي أصبحت متوفّرة بعد أن تم استدعاء وحدة "conntrack”. يسمح لنا هذا الأمر بمطابقة حزم البيانات بناءً على ماهيّة ارتباطها بحزم البيانات التي رأيناها من قبل. إننا نقوم بتمرير قيمة ESTABLISHED للسماح بمرور حزم البيانات الداخلة التي هي جزء من اتّصالٍ عاملٍ حاليًا فقط. ونقوم بتمرير قيمة RELATED للسماح بمرور حزم البيانات المرتبطة باتّصالٍ مُنشَئٍ بالفعل. هذا الجزء من القاعدة هو الجزء الذي يتطابق مع جلسة SSH الحالية الخاصّة بنا. -j ACCEPT: يقوم هذا الخيار بتحديد هدف مطابقة حزم البيانات. هنا، نقوم بإخبار iptables أنّ حزم البيانات التي تطابق القاعدة السابقة يجب أن يتم السماح لها بالمرور. قمنا بوضع هذه القاعدة في البداية لأننا أردنا أن نتأكّد أنّ اتصالنا الحالي مطابق، مقبول وخارج إطار السلسلة قبل تنفيذ أيّ قواعد DROP. يمكننا الآن رؤية حالة التغييرات التي قمنا بها عن طريق: $ sudo iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination الآن وبعد أن صرتَ تعرف الصياغة العامّة لقواعد iptables، فلنتابع عبر استعراض المزيد من الحالات التي سنحتاج فيها إلى قبول الاتّصالات. قبول الاتّصالات المهمّة الأخرى أخبرنا iptables أن يبقي أيّ اتصالاتٍ مفتوحة على وضعها الحالي بالإضافة إلى السماح بالاتصالات الجديدة المرتبطة بتلك الاتصالات. على كلّ حال، نحتاج إلى إنشاء بعض القواعد الضرورية لتحديد متى نريد قبول اتّصالاتٍ جديدة لا تطابق هذه المعايير التي طبّقناها. نريد إبقاء منفذين اثنين مفتوحين بالتحديد. نريد إبقاء منفذ اتّصال SSH الخاصّ بنا مفتوحًا (سنفترض في هذا الدرس أنّ المنفذ الافتراضي له هو المنفذ 22. إذا كنتَ غيّرت هذا المنفذ على خادومك من إعدادات SSH فقم بتعديل قيمته هنا). سنقوم أيضًا بافتراض أنّ هذا الحاسوب يقوم أيضًا بتشغيل خادوم ويب يعمل على المنفذ 80. إذا لم يكن هذا هو نفس الوضع بالنسبة لك فلن تحتاج تطبيق القاعدة التالية. السطران اللذان سنستعملهما لتطبيق هذه القواعد هما: sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT كما يمكنك أن ترى، هذه القواعد مشابهة جدًا لقاعدتنا الأولى التي كتبناها، ولكنها ربما تكون أكثر بساطةً. الخيارات الجديدة هي: -p tcp: يقوم هذا الخيار بمطابقة حزم البيانات في حال كان البروتوكول المستخدم هو TCP. هذا البروتوكول هو بروتوكولٌ مستخدم بواسطة معظم التطبيقات لأنّه يسمح بتواصلٌ مرن وقوي بين المستخدم والتطبيق. --dport: يكون هذا الخيار متوفّرًا للاستخدام فقط في حال كان الخيار -p tcp موجودًا في الأمر. إنّه يقوم أيضًا بتحديد رقم المنفذ الذي يجب مطابقة حزم البيانات عبره. تقوم القاعدة الأولى بمطابقة حزم البيانات المارّة عبر بروتوكول TCP بالمنفذ 22، بينما تقوم الثانية بمطابقتها عبر المنفذ 80. هناك قاعدة ACCEPT أخرى يجب علينا التأكّد من أنّ خادومنا يقبلها بشكل صحيح. غالبًا، تتواصل الخدمات (services) مع بعضها البعض على الحاسوب عبر إرسال حزم بياناتٍ فيما بينها، وهي تقوم بذلك عبر الاستفادة من واجهة شبكةٍ زائفة تدعى loopback device ، والتي تقوم بتوجيه التدفّق إلى نفسها عوضًا عن الأجهزة الأخرى. لذا إذا كانت واحدة من الخدمات تريد التواصل مع خدمةٍ أخرى تستمع إلى المنفذ 4555، فإنّه بمقدورها إرسال حزمة بيانات إلى المنفذ 4555 على الشبكة الزائفة loopback device. نريد أن يتم السماح بهذا النوع من السلوك بين الخدمات لأنّه ضروري للعديد من برامج نظام التشغيل. القاعدة التي نحتاج تطبيقها هي هذه: $ sudo iptables -I INPUT 1 -i lo -j ACCEPT يبدو هذا الأمر مختلفًا قليلًا عن الأوامر السابقة. فلنشرح ما يفعله: -I INPUT 1: يقوم الخيار -I بإخبار iptables بإدراج قاعدةٍ جديدة. هذا الخيار مختلف عن الخيار -A والذي يقوم بإضافة القاعدة الجديدة إلى نهاية قواعد iptables. يحتاج الخيار -I إلى اسم السلسلة والمكان الذي تريد إدراج القاعدة الجديدة فيه. في حالتنا، فإننا نقوم بإضافة هذه القاعدة كأول قاعدة في سلسلة INPUT. هذا سيدفع بقية القواعد إلى الأسفل بدرجةٍ واحدة تلقائيًا. نحتاج لهذه القاعدة أن تكون بالأعلى لأنّها أساسية ولا يجب أن يتم التأثير عليها عبر قواعد فرعيّة أخرى. -i lo: يقوم هذا المكوّن من القاعدة بمطابقة ما إذا كانت الواجهة التي تستخدمها حزمة البيانات هي واجهة "lo”. واجهة "lo” هي عبارة عن اسمٍ آخر لـloopback device. هذا يعني أنّ أيّ حزمةِ بياناتٍ تستعمل تلك الواجهة الشبكيّة للتواصل (حزم البيانات الناتجة في خادومنا، إلى خادومنا) يجب أن يتم قبولها من طرف iptables. لرؤية قواعدنا الحاليّة، يجب أن نستخدم الخيار -a . هذا بسبب أنّ الخيار -L لا يتضمّن بعض المعلومات، مثل اسم الواجهة المرتبطة بالقواعد، والذي يعتبر جزءًا مهمًّا في القاعدة التي قمنا بإضافتها: $ 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 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT تضمين قاعدة حظر (Drop) نمتلك الآن 4 قواعد منفصلة تقبل الاتصالات بناءً على معايير معيّنة. وبالرغم من ذلك، فإنّا خادومنا حاليًا لا يحظر وصول أيّ شيء إليه. إذا دخلت حزمة بياناتٍ إلى سلسلة INPUT ولم تكن مطابقة لأيٍّ من القواعد الأربعة التي أدخلناها، فإنّه سيتم تحويلها إلى السياسة الافتراضية للتعامل مع حزم البيانات، والتي هي حاليًا "قبول حزم البيانات جميعها"، ونحتاج لتغيير هذا الأمر. هناك طريقتان يمكننا فعل ذلك بهما، مع بعض الاختلافات الجوهرية. الطريقة الأولى التي يمكننا من خلالها القيام بهذا هي عن طريق تعديل السياسة الافتراضية لسلسلة INPUT. يمكننا القيام بذلك عبر كتابة: $ sudo iptables -P INPUT DROP ستقوم القاعدة السابقة بالتقاط أيّ حزم بياناتٍ تفشل بالمرور عبر سلسلة INPUT الخاصّة بنا ويمنع وصولها إلى الخادوم. هذا ما ندعوه بسياسة المنع الافتراضيّة (default drop policy)، من مساوئ هذه الطريقة هي أنّ قاعدة الـDROP هذه يتم إلغاؤها في حال تم مسح قواعد iptables (حيث أنّها قاعدة هي الأخرى وبالتالي سيتم مسحها معها). قد تكون هذه الطريقة أكثر أمنًا، ولكنك قد تواجه عواقب وخيمة في حال لم يكن لديك طريقةٌ أخرى للوصول إلى خادومك. في DigitalOcean، يمكنك الولوج عبر لوحة التحكّم إلى خادومك والوصول إلى طرفيّة ويب تمكّنك من التحكّم به إذا حصل هذا. طرفيّة الويب هذه تعرّف نفسها على أنّها اتصال وهمي محلّي ولذلك فإنّ قواعد iptables لا تؤثّر عليها. قد تودّ لخادومك أن يقوم بحظر جميع الاتصالات في حال مسح جميع القواعد. قد يمنع هذا من ترك خادومك مفتوحًا للجميع. وهذا يعني أيضًا أنّه بمقدورك بسهولة إضافة القواعد إلى نهاية أيّ سلسلة تريدها بينما تحظر حزم البيانات التي لا تريدها بسهولة. إذا قمتَ بتغيير السياسة الافتراضيّة لسلسلة INPUT، فإنّه يمكنك إرجاعها عبر تطبيق: $ sudo iptables -P INPUT ACCEPT الآن، يمكنك إضافة قاعدة إلى نهاية السلسلة والتي ستقوم بحظر أيّ حزم بياناتٍ متبقية: $ sudo iptables -A INPUT -j DROP النتائج تحت شروطٍ تشغيلية عادية ستكون بالضبط هي نفس سياسة الحظر الافتراضيّة. تعمل هذه القاعدة عبر مطابقة كلّ حزمة بياناتٍ متبقية تصل إليها. يمنع هذا حزمةَ البيانات من الوصول إلى الخادوم في حال فشلت بتجاوز القواعد السابقة التي قمنا بإنشائها. بشكلٍ عام، يتم استخدام هذه القاعدة لجعل السياسة الافتراضيّة في التعامل مع الاتصالات تقبل التدفّق الواصل إليها. بهذه الطريقة، في حال كان هناك أيّ مشاكل وتم مسح جميع القواعد، فإنّك ستبقى قادرًا على الوصول إلى الآلة عبر الشبكة. بالطبع، هذا يعني أيضًا أنّ أيّ قاعدةٍ إضافية تودّ إضافتها إلى نهاية السلسلة يجب أن تكون قبل قاعدة الحظر أو الـdrop. يمكنك فعل هذا عبر حذف قاعدة الحظر مؤقتًا عبر: $ sudo iptables -D INPUT -j DROP $ sudo iptables -A INPUT new_rule_here $ sudo iptables -A INPUT -j DROP أو، يمكنك إدراج القواعد التي تحتاجها في نهاية السلسلة (ولكن قبل قاعدة الـdrop) عبر تحديد رقم السطر. لإدراج قاعدةٍ في السطر رقم 4، يمكنك كتابة: $ sudo iptables -I INPUT 4 new_rule_here إذا كنتَ تواجه مشاكل في معرفة إلى أيّ سطرٍ تنتمي أيّ قاعدة، فيمكنك إخبار iptables بأن يقوم بسرد السطور المتوفّرة عبر: $ sudo iptables -L –line-numbers Chain INPUT (policy DROP) num target prot opt source destination 1 ACCEPT all -- anywhere anywhere 2 ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED 3 ACCEPT tcp -- anywhere anywhere tcp dpt:ssh 4 ACCEPT tcp -- anywhere anywhere tcp dpt:http Chain FORWARD (policy ACCEPT) num target prot opt source destination Chain OUTPUT (policy ACCEPT) num target prot opt source destination يمكن لهذا أن يكون مفيدًا للتأكّد من أنّك تضيف القاعدة إلى مكانها الصحيح. حفظ إعدادات iptables الخاصّة بك افتراضيًا، تكون القواعد التي تضيفها إلى iptables غير دائمة. هذا يعني أنّك عندما تقوم بإعادة تشغيل خادومك، فإنّ جميع قواعد iptables ستختفي. هذه المشكلة في الواقع هي ميّزة لبعض المستخدمين لأنّها تعطيهم فرصةً للعودة إلى التحكّم بالخادوم في حال قاموا بحبس أنفسهم خارجها عن طريق الخطأ في تطبيق القواعد. وعلى كلّ حال، معظم المستخدمين سيودّون أن يكون هناك طريقة تلقائية لحفظ القواعد التي أنشؤوها وتحميلها تلقائيًا عند إقلاع الخادوم. هناك عدّة طرق لفعل هذا، لكنّ أسهلها هو باستخدام حزمة iptables-presistent، يمكنك تحميل هذه الحزمة من مستودعات Ubuntu الافتراضيّة: $ sudo apt-get update $ sudo apt-get install iptables-persistent أثناء التثبيت، سيتم سؤالك عمّا إذا كنتَ تحبّ حفظ قواعد iptables الحاليّة ليتم تحميلها تلقائيًا. إذا كنتَ مسرورًا مع إعداداتك الحاليّة (واختبرت قدرتك على الوصول إلى اتصالات SSH جديدة مستقلة) فإنّه يمكنك الموافقة على ذلك. سيتم سؤالك أيضًا عمّا إذا كنتَ تريد حفظ قواعد IPv6 التي قمتَ بإعدادها، يتم إعداد هذه القواعد عبر أداة منفصلة تدعى ip6tables والتي تتحكم بحزم بيانات IPv6 بنفس الطريقة. بمجرّد اكتمال التثبيت، ستتوفر خدمة جديدة لديك تدعى iptables-presistent وهي مُعدّة ليتم تشغيلها عند الإقلاع. ستقوم هذه الخدمة بتحميل قواعد iptables الحاليّة وتطبيقها من جديد في كلّ مرّة يتم إعادة تشغيل النظام فيها. الخاتمة يجب أن تكون الآن قد امتلكت نقطة بداية جيّدة للبدء في تطوير جدارٍ ناري يلبي احتياجاتك. هناك العديد من أدوات الجدران الناريّة الأخرى التي يمكنك استخدامها والتي قد تكون أسهل، ولكن iptables أداةٌ جيّدة لتعلّمها، ذلك لأنّها توفّر بنية netfilter تحتية جيّدة للاستعمال ولأنّها متوفّرة افتراضيًا في العديد من أنظمة التشغيل. ترجمة -وبتصرّف- للمقال: How To Set Up a Firewall Using IPTables on Ubuntu 14.04.