المحتوى عن 'حماية'.



مزيد من الخيارات

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المُحتوى


التصنيفات

  • التخطيط وسير العمل
  • التمويل
  • فريق العمل
  • دراسة حالات
  • نصائح وإرشادات
  • التعامل مع العملاء
  • التعهيد الخارجي
  • مقالات عامة
  • التجارة الإلكترونية

التصنيفات

  • PHP
    • Laravel
    • ووردبريس
  • جافاسكريبت
    • Node.js
    • jQuery
    • AngularJS
    • Cordova
  • HTML5
  • CSS
    • Sass
    • إطار عمل Bootstrap
  • SQL
  • سي شارب #C
    • منصة Xamarin
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • برمجة أندرويد
  • لغة R
  • سير العمل
    • Git
  • صناعة الألعاب
    • Unity3D
  • مقالات عامّة

التصنيفات

  • تجربة المستخدم
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
    • كوريل درو
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • مقالات عامّة

التصنيفات

  • خواديم
    • الويب HTTP
    • قواعد البيانات
    • البريد الإلكتروني
    • DNS
    • Samba
  • الحوسبة السّحابية
    • Docker
  • إدارة الإعدادات والنّشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • مقالات عامة

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • استسراع النمو
  • المبيعات

التصنيفات

  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • مقالات عامة

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
  • أندرويد
  • iOS
  • macOS
  • ويندوز

التصنيفات

  • شهادات سيسكو
    • CCNA
  • شهادات مايكروسوفت
  • شهادات Amazon Web Services
  • شهادات ريدهات
    • RHCSA
  • شهادات CompTIA
  • مقالات عامة

أسئلة وأجوبة

  • الأقسام
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة البرمجة
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات
    • أسئلة الشهادات المتخصصة

التصنيفات

  • ريادة الأعمال
  • العمل الحر
  • التسويق والمبيعات
  • البرمجة
  • التصميم
  • DevOps

تمّ العثور على 65 نتائج

  1. أنهينا الجزء الأكبر من العمل على تقرير المبيعات في الدرس السابق وستكون مهمتنا في هذا الدرس إضافة بعض اللمسات السحرية والتشطيبات النهائيَّة لبدء استعمال التقرير. سنتعلم في هذا الدرس بعض التوابع الجديدة التي سنضيفها إلى تقرير المبيعات وسنعرِّج على موضوع حماية أوراق العمل والنطاقات أثناء مشاركة الملف مع الآخرين ثمَّ سنتعرَّف على كيفيَّة استعمال التنسيق الشرطي. دمج مجموعة من التوابع استعملنا في الدرس السابق القائمة المنسدلة لإدراج المنتج المُباع (حقل رقم المنتج والوصف) ولكن توجد حقيقةً طريقة أخرى متقدمة نستعمل فيها التوابع لاختيار وصف المنتج بالبحث عنه في جدول المخزون. التوابع التي سنستخدمها هي: التابع طريقة الاستعمال الوصف 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 ونحدِّد تنسيق الخليَّة ونضغط “تم“. سنُنسق حقل الإجمالي وفق تنسيق التدرج اللوني لمعرفة القيمة العظمى والقيمة الصغرى المباعة في اليوم. نضغط على إضافة قاعدة جديدة ونختار “تدرج اللون” ثمَّ نحدِّد خلايا الحقل في مربع “ينطبق على نطاق”؛ نختار التدرج اللوني المناسب ثمَّ نختار “الحد الأدنى” من خيارات القيمة الدنيا وخيار “الحد الأقصى” من خيارات القيمة العظمى. يظهر تنسيق الحقل كما موضح في الصورة. توجد قواعد كثيرة في التنسيق الشرطي تنتظرك لاستكشافها والتي تسهِّل عليك تنسيق جدولك وتحليل البيانات وقراءتها بسرعة. الخاتمة انتهينا من إنشاء تقرير المبيعات وأصبح جاهزًا لملء البيانات فيه وآمنًا لمشاركته مع الآخرين. إنَّ ما تعلمته إلى الآن يمكِّنك من إنشاء أغلب الجداول التي ستلزمك في جميع أمور حياتك اليوميَّة وبأفضل تصميم؛ كل ما عليك هو فتح تطبيق جداول بيانات جوجل والبدء بتصميم جدولك.
  2. نعرف نحن مطوّري البرامج أهميّة اتّباع أفضل الممارسات الأمنية؛ إلا أننا نتسرّع غالبا في تنفيذها، ربما بسبب ما تستدعيه من العمل الجادّ حتى ترسخ في الأذهان. يحدُث أحيانا أن ترى ممارسة أمنية شديدة الخطورة لدرجة أنها تبقى محفورة في ذهنك. أمرّ في عملي مدير أنظمة على الكثير من الممارسات الأمنية الخاطئة، إلا أن الثلاثة التي سأتحدّث عنها في هذا المقال هي أساسيّات يجب على كلّ مطوّر برامج تفاديها. أنبّه هنا إلى أنني أرى كل واحدة من الممارسات المذكورة لدى شركات كبيرة ومطوّرين ذوي خبرة طويلة، لذا فليس صحيحا لصقُها بالمطوّرين المبتدئين. لا تستخدم التعمية لكلمات السّر .. بل التجزئة Hash عملتُ في وقت سابق من مسيرتي المهنية مع شركة تستخدم نظام إدارة يخزّن بيانات شديدة الأهميّة، وفي أحد الأيام طُلِب مني إجراء مراجعة أمنية للشبكة والبرنامج الذين تعتمد عليهما بياناتنا الحرجة. قضيتُ بضع دقائق في البحث ثم قرّرت تشغيل Wireshark لرؤية حركة البيانات عبر الشبكة. استخدمتُ حاسوب العمل للدخول إلى نظام المعلومات ولاحظتُ أمرا غريبا. رغم أن هذه الحادثة كانت قبل انتشار SSL إلا أنني لم أكن أتوقّع أن أرى نصوصا واضحة تحوي حقولا مثل username (اسم المستخدِم) وpassword (كلمة السرّ). بدا بعد التدقيق أن النظام كان يُرسِل اسم المستخدم الخاصّ بي وسلسلة محارف عشوائية - لم تكن كلمتي للسرّ - عبر الشبكة. لم أستطع ترك الأمر على تلك الحال، فحاولتُ تسجيل الدخول مجدّدا إلا أنني هذه المرة أدخلتُ - عن قصد - كلمة سرّ خاطئة. لم أغيّر كلمة السّر كليّةً، بل اكتفيتُ بتغيير محرف واحد فقط. كنتُ أتوقّع رؤية سلسلة محارف جديدة مختلفة تمامًا تمثّل كلمتي للسّر تمرّ عبر الشبكة. بدلا من ذلك، لم يتغيّر سوى أول محرفيْن من سلسلة المحارف. كان الأمر مثيرًا للانتباه، فرغم أن خبرتي كانت متواضعة نوعا ما، إلا أنني كنتُ أعرف أنه إن طُبِّقت دالة تجزئة Hash بطريقة صحيحة على كلمتي للسرّ فستكون سلسلة المحارف مختلفة تماما، وليس فقط أول محرفين. ياللهوْل.. حتى مخطّط تعميّة (تشفير) جيّد كان سيُنتج سلسلتيْ محارف مختلفتين تماما، وهو ما يبدو أن مخطّط التعمية المستخدَم لا يقوم به. جرّبتُ كلمتي سرّ أخرييْن. تسلّحتُ بأوراق وقلم رصاص وقضيتُ الساعتيْن المواليتيْن في محاولة العثور على مخطّط فكّ التعمية. كان لديّ بانتهاء هاتيْن الساعتيْن سكريبت بايثون يمكنه أخذ أي واحدة كلمات السّر “المعمّاة” تلك ثوم فكّ تعميّتها وكشف كلمة السّر الأصلية؛ أمر يُفترَض أن لا أحد بإمكانه فعله. أنا متأكّد من أنه لم يدُر بخلد الشخص الذي وضع ذلك المخطَّط أن أحدا سيجلس ساعتيْن ويعمل على تفكيك مخطّطه؛ إلا أني فعلتُ ذلك. لماذا؟ لأنه كان بإمكاني ذلك. لا تعمّي كلمات السّر إن اضطررت لتخزينها من أجل المقارنة، فهناك دائما إمكانية أن يستطيع أحدهم إيجاد خوارزميّة أو مفتاح لفك التعميّة. لا يوجد عكس مباشر للتجزئة، بمعنى أنه لا يمكن لأحد الحصول على الأصل إلا إذا كان لديه جدول يربط بين النص الواضح وتجزئته (أو أنه خمّنه). معرفة آلية التجزئة وطريقة عملها لا تضرّ بسلامة البيانات، في حين يحدُث ذلك عند معرفة مخطّط التعمية ومفتاحها. 2. لا تترك منافذ خلفية Backdoors سريّة في البرامج كنتُ في وظيفة سابقة لدى إحدى شركات الخدمات البرمجية أقدّم الدعم لمستخدمين أخبروني أن أسماء المستخدمين التي بحوزتهم لم تعد تعمل. كان الدعم جزءًا من خدمة مدفوعة تقدّمها الشركة المطوّرة للبرنامج المستخدَم. خطر ببالي، قبل محاولة معرفة المشكل الكامن وراء إحدى أكثر مكالمات الدعم الفني إضجارا (“بيانات الدخول الخاصة بي لا تعمل”)، أن أجرّب تسجيل الدخول بنفسي. بالفعل لم تكن أسماء الدخول تعمل. كان النظام منصةً تعليمية مبنية على تقنيات الوِب، وكنا قد دفعنا مقابل وظائف محدودة من قدراتها الكثيرة. لفت أمر نظري بينما كنتُ أبحث في صفحة تسجيل الدخول. بدا حرف في إحدى المحارف ذا شكل مختلف قليلا عن البقية. ربما كان السببُ استخدام خط مختلف عن بقية الصفحة. عرضتُ مصدر الصفحة ولاحظتُ وجود رابط على هذا الحرف بالضبط. كان الرابط مخفيًّا عن قصد ولم تكن حالة المؤشّر تتغيّر عندما يحوم على الرابط. فتحتُ - بحذر شديد - الرابط في نافذة متصفّح جديدة. فجأةً بدت أمامي شاشة تفصّل معلومات عن مجموعة كاملة من الحواسيب، وتعطيني التحكّم الكامل في ما يمكن لهذه الحواسيب أن تعمله. كان بمقدوري إطفاء هذه الحواسيب، إعادة تشغيلها، أخذ لقطات من الشاشة.. أي شيء. هاتفتُ الشركة المطوّرة للبرنامج وطلبتُ الحديث مع مسؤول التقنية لديهم. تحدّثتُ في الأخير بعد المرور على أشخاص عدّة مع مَن يبدو أنهم يفهم ما أتحدّث عنه. أجاب “آه.. فعلا”، وأكمل “أضفنا ذلك الرابط ليسهل علينا الوصول. ولا أحد - قبلك - أبدا عثر عليه. سنحذفه فورا”. سألني قبل أن ننهي المكالمة سؤالا أخيرا: “لماذا بدأت في النظر إلى شفرات HTML في صفحة الدخول؟” كانت إجابتي بسيطة: “لأنني أستطيع ذلك”. لا يستحق وضعُ منفذ خلفي في نظام ما أي درجة من المخاطرة.. سيعثُر عليه شخص ما في نهاية المطاف. مهما كانت درجة الغموض فإن تحليل الشفرات البرمجية - كذلك البحث والحافز عموما - يحمل في طيّاته أكثر النتائج غرابة وفجائية. 3. استوثق من المستخدمين على جميع الصفحات.. وليس فقط صفحة الدخول كنتُ في مرحلة سابقة من مسيرتي المهنية جزءًا من مشروع تطوير برمجي كان يتولّى تنفيذه مطوّر متمرّس. كنتُ أحسّ بعدم الارتياح مع هذا التطبيق خصوصا، فأخبرتُ مديري بأننا نحتاج لإجراء مراجعة أمنية معمَّقة للشفرة البرمجية. طُلِب مني أن أنظُر في التطبيق بحثا عمّا يمكنني العثور عليه. بدأتُ بالتجوّل في التطبيق، تسجيل الدخول، وعرض بعض البيانات. ثم لاحظتُ أمرا بدا لي مثيرا للاهتمام. إن علمتُ Bookmarked رابطا بعد تسجيل الدخول والتجول في النظام فإن بإمكاني نسخه ثم لصقه في متصفّح آخر وسأحصُل على نفس الصفحة المُعلَّمة، دون الحاجة لتسجيل الدخول. سألتُ المطوّر “لماذا لا تتحقّق في كل صفحة من أن المستخدم مسجَّل الدخول؟ إذ يكفي أن أحصُل على رابط بعد تسجيل الدخول ونسخه ويمكنني الوصول إلى هذه الصفحة متى أردت دون الحاجة لتسجيل الدخول”، فسألني “لماذا تفعل ذلك؟”. أجبتُه: “لأنه يمكنني ذلك”. لا تترك أي شيء للصدفة حتى المطوّرون المتمرّسون يقعون في هذه الأخطاء؛ فهم يظنّون ألا أحد سيتعمّق في نظام لا يحقّ له الوصول إليه. المشكلة أن المستخدمين سيتسكّعون في النظام وسيعثرون على هذه الثغرات في النهاية. النصيحة الأهم التي يمكن لشخص مثلي، مجرّد هاو لمجال الحماية، أن يقدّمها هي:لا تترك أي شيء للصدفة. يوجد أشخاص - مثلي - يحبون التعمق في الأشياء لمعرفة كيف تعمل ولماذا. ولكن يوجد آخرون ربما أكثر خبرة ومعرفة سيتعمّقون في الأنظمة بحثا عن اكتشاف الثغرات ولاستغلالها. لماذا؟ لأن باستطاعتهم فعل ذلك. ترجمة - بتصرّف - للمقال 3 security tips for software developers لصاحبه Pete Savage. حقوق الصورة البارزة محفوظة لـ Freepik
  3. سنتعرف في هذا المقال من سلسلة المقالات حول التعامل مع ويندوز 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 خاصّة. هناك الكثير مما يمكن قوله حول جدران الحماية، ولكن سنكتفي بما أوردناه في هذا المقال.
  4. تحدثنا في السابق عن بضع خطوات يمكنك تطبيقها لزيادة أمان وحماية موقعك العامل بسكربت ووردبريس الشهير. صحيحٌ أنّ نواة ووردبريس آمنة للغاية، ولكن يجب عليك تثبيت عدّة إضافات وملحقات إضافية لزيادة مستوى أمان موقعك. سنتحدّث في هذا الدرس عن أهم إضافات الأمان والنسخ الاحتياطي التي يمكنك تثبيتها وتفعيلها على سكربت ووردبريس الشهير. لماذا قد أحتاج إضافة للحماية؟ بشكلٍ عام، تقوم إضافات الحماية والأمان بتوفير طبقة إضافية من الحماية ضدّ هجمات 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.
  5. في الدرس السابق تحدثنا عن طرق تثبيت ووردبريس لأول مرة بأمان. في هذا الدرس، سنتحدّث عن كيفية تأمين موقع ووردبريس بعد تثبيته، سنتحدّث عن أساليب أفضل للحماية فوق مستوى نصائح "اختر كلمة مرور أكثر تعقيدًا" وسنحاول الغوص قليلًا في موضوع أمان ووردبريس. تقييد عمليات تسجيل الدخول واحدٌ من أول الأشياء التي يجب عليك فعلها لتأمين موقع ووردبريس الخاصّ بك هو تقييد عدد المرّات التي يمكن لشخصٍ ما أن يحاول تسجيل الدخول بها إلى الموقع. يحاول العديد من المخترقين القيام بهجمات التخمين أو ما يعرف بـ 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.
  6. سنناقش في هذا الدرس أهمّية تحديث كلّ شيءٍ متعلّق بموقع ووردبريس الخاصّ بك إلى آخر الإصدارات المتوفّرة وأهميّة التحديثات بشكلٍ عام، وهو من أهمّ الأمور التي يمكنك القيام بها لزيادة حماية وأمان موقعك. لماذا نقوم بالتحديث؟ السؤال الحقيقي يجب أن يكون "ولما لا"؟ يقوم مطوروا ووردبريس بإرسال التحديثات إلى المستخدمين لسببٍ معيّن في النهاية، حيث أنّ هذه التحديثات تحتوي على إصلاحاتٍ لثغراتٍ خطيرة يمكن أن يستغلها المهاجمون لمهاجمة موقعك، مما يجعل التحديث ضرورة لا مفرّ منها. أنواع التحديثات قبل أن نتابع، من المهمّ أن نفهم أنواع التحديثات المختلفة المتوفّرة في سكربت ووردبريس. يشير Tony Perez في تدوينة حديثة إلى أنّه هناك 3 أنواع مختلفة من التحديثات: تحديثات الأمان، الترقيعات والإصدارات الرئيسية. تحديثات الأمان هي بالضبط كما تبدو عليه من اسمها. يتم إصدارها بسرعة وتحتوي فقط على بضع إصلاحاتٍ لثغراتٍ موجودة تم اكتشافها مؤخرًا. تكون هذه التحديثات عادةً على شاكلة أرقام الإصدارات مثل 4.2.1. تحديثات الترقيعات أكبر قليلًا، لا تحتوي هي الأخرى على مميزاتٍ جديدة، ولكنّها تقوم بتحديث النظام وعادةً ما تتضمن تحديثاتٍ أمنية كذلك، كما أنّه يتم إصدارها بصفة دورية ومن الممكن توقّع وقت صدور الترقيع الجديد. وأمّا عن التحديثات الرئيسية من الانتقال من الإصدار 3.9 إلى الإصدار 4.0 فهذا تحديثٌ جوهري، يحتوي مميزاتٍ جديدة وإصلاحاتٍ للمشاكل الأمنية المعروفة بالإضافة لأمورٍ أخرى، كما أنّه يتم التدوين عنها في مدونة ووردبريس وفي العديد من المواقع الإخبارية الأخرى، حيث أنّها تحديثات كبيرة ويجب على الجميع معرفتها. قد تقوم هذه التحديثات أحيانًا بتحطيم شكل موقعك بسبب عدم توافقية مع القالب الذي تستخدمه مثلًا، ولكن مع وجود نسخة احتياطية من موقعك، فيجب ألّا تكون مشكلةً بالنسبة لك. الفشل بالتحديث يعني مشكلة أعظم كما ذكرنا سابقًا، عدم قيامك / فشلك بتحديث أيّ إضافات أو قوالب ووردبريس مثبّتة على موقعك قد يعرّضك لخطرٍ كبير، وما قد لا تفهمه هو "لماذا"؟ يمكن قول نفس الأمر بخصوص القوالب والإضافات، صحيحٌ أنّها ليست جزءً من لبّ نواة ووردبريس، ولكنّها أيضًا قد تحتوي على ثغرات تمكّن المخترقين من استغلالها لاختراق موقعك، وأيضًا يتم اكتشاف هذه الثغرات كلّ فترة وتصدر تحديثات لترقيعها كلّ فترة، وعليك تثبيتها بمجرّد توفّرها. بعض السمات والقوالب تكون مبرمجة بصورة سيئة ويكون بها العديد من الثغرات ويجب عليك الانتباه إلى ذلك، كما يجب عليك تثبيت واستخدام القوالب والإضافات التي تستعملها فقط وحذف كلّ شيء لا تستعمله. إدارة تحديثات ووردبريس أفضل طريقة للتأكّد من أنّ كلّ شيء على موقعك محدّث هو جعل عملية التحقق من وجود تحديثات متوفّرة هي مهمّة روتينية أخرى على جدولك (لو لم تكن تقنيًا، فيجب عليك البحث عن استضافة تقوم تلقائيًا بتحديث جميع القوالب والإضافات والنواة الخاصّة بووردبريس)، يجب عليك التحقق من توفّر التحديثات بنفسك كلّ يوم لتجنّب أي مشاكل أمنية قد تحصل. منذ الإصدار 3.7 من ووردبريس فإنّ المنصة تسمح بالتحديث التلقائي بسهولة، بمجرّد تفعيل هذا الخيار، فإنّه هذا يعني أنّ نواة موقعك ستقوم بالتحديث تلقائيًا عند توفّر تحديثات جديدة بدون أيّ تدخّل منك. طبعًا لا يمكن فعل نفس الشيء بالنسبة للقوالب والإضافات، حيث يجب عليك القيام بتحديثها يدويًا. الخاتمة تحديثات ووردبريس مهمّة للغاية، بل ومهمّة جدًا، ومن واجبك الاهتمام بتحديث كلّ شيءٍ موجود على موقعك إلى الإصدارات الأخيرة المتوفّرة، وإلّا فإنك تترك بابك مفتوحًا للمخترقين ليخترقوك، إنّها مسألة وقت. ترجمة -وبتصرف- للمقال: The WordPress Developer’s Guide to Security: Updates لصاحبه: Brenda Barron.
  7. من المهم لمطورّي ووردبريس أن يكونوا على اطّلاعٍ على تقنيات الحماية والأمان عند تطوير مواقع تعمل بسكربت ووردبريس أو تصميم قوالب جاهزة له، سنبدأ سلسلة من 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.
  8. يُستخدم برنامج وورد لتحرير أنواع كثيرة من النصوص وحفظها بشكل مستندات. وفي بعض الأحيان تكون هذه المستندات سريّة أو تحتوي على معلومات حساسة من ناحية الخصوصية ونرغب في حمايتها بطريقة أو بأخرى. ولهذا الغرض يوفّر وورد عدد من مستويات الحماية للمستندات مثل الحماية بكلمة مرور، تقييد عملية التحرير والتنسيق، أو غيرها. في هذا الدرس سنغطي كيفية حماية المستندات بجعلها للقراءة فقط، تقييد عمليات التحرير والتنسيق من قبل الآخرين، تشفير المستند بكلمة مرور، وحذف البيانات الوصفية 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: خاتمة استعرضنا في هذا الدرس طرق حماية مستندات وورد بعدّة مستويات. ويمكنك اختيار الطريقة المناسبة لمستنداتك التي تريد مشاركتها حسب درجة خصوصية أو سرّية المعلومات التي تحتويها. إذا كان لديك أي سؤال حول حماية مستندات وورد تفضّل بطرحه في التعليقات، وسنكون سعداء بمساعدتك
  9. تخزن هواتفنا الكثير من المعلومات الشخصية التي يكون بعضها حساسًا جدًا من ناحية الخصوصية والأمان مثل الصور، البريد الإلكتروني السري، البيانات المالية، كلمات المرور، وغيرها. وبالرغم من أنّ نظام تشغيل هواتف iPhone، iOS، مصمم بأمان عالٍ، إلّا أنّه من المفيد أن تتخذ بعض الإجراءات لتعزيز هذا الأمان كخطوة احترازية. فيما يلي بعض النصائح التي يمكنك تطبيقها لزيادة أمان هاتفك وحمايته من المخترقين: 1. استخدم كلمة مرور قويّة بدلًا من رمز المرور يفضّل الكثير من الناس استخدام رمز المرور (4 أو 6 أرقام) لسهولة تذكره وسرعة إدخاله. لكن لكي تمنع أي احتمال من أن يقوم أحدهم بتخمين رمز المرور الخاص بك، ولو كان هذا الاحتمال ضئيلا جدًا، استخدم كلمة مرور طويلة ومعقدة. فبخلاف رمز المرور الذي يتكون من أرقام فقط، يمكن تشكيل كلمة المرور من حروف، أرقام، ورموز. حتّى أنّها تكون حساسة من ناحية حالة الأحرف، صغيرة كانت أو كبيرة، وهذا الأمر يجعل تخمين كلمة المرور صعبًا جدًا. لاستخدام كلمة مرور بدلًا من رمز المرور اذهب إلى إعدادات Settings> Touch ID ورمز المرور Touch ID & Passcode> تغيير رمز الدخول Change Passcode: بعد ذلك قم بإدخال رمز الدخول القديم ثم انقر على خيارات رمز الدخول Passcode Options: اختر رمزًا أبجديًاا مخصصًا Custom Alphanumeric Code: ثم أدخل كلمة المرور وحاول جعلها معقدة باستخدام حروف، أرقام، ورموز متنوعة. لا تنس تسجيل كلمة المرور الجديدة أو تدوينها في مكان ما تحسّبًا لنسيانها. 2. عطّل خاصية التعبئة التلقائية AutoFill تتيح هذه الخاصية إمكانية ملء حقول نماذج الويب تلقائيًا بمعلومات جهة الاتصال الخاصة بك، الأسماء، كلمات المرور، ومعلومات بطاقات الائتمان التي قمت بإدخالها سابقًا. وهذه الخاصية مفيدة للتخلص من تعبئة الحقول المتكررة والمملة. لكنّها ستكون وسيلة سهلة للوصول إلى الكثير من معلوماتك الخاصة فيما لو قام أحدهم باستخدام هاتفك بطريقة أو بأخرى. لذلك يمكنك تعطيل التعبئة التلقائية بالذهاب إلى إعدادات Settings> Safari> التعبئة التلقائية AutoFill: عطّل جميع الخيارات أو الخيار الذي تراه غير آمن فقط. 3. فعّل مسح البيانات عند تفعيل هذه الخاصية سيقوم الهاتف بمسح كافة البيانات التي يحتويها تلقائيًا بعد 10 محاولات فاشلة لإدخال كلمة المرور. وفي هذه الحالة ستضمن حماية معلومات الخاصة والسرية حتى لو تمكّن أحدهم من فتح هاتفك. لكن خذ في الحسبان أنّ البيانات المحذوفة لا يمكن استرجاعها إلا في حال قمت بحفظ نسخة احتياطية محلية أو على iCloud. لتفعيل مسح البيانات اذهب إلى إعدادات Settings> Touch ID ورمز المرور Touch ID & Passcode> مسح البيانات Erase Data، ثم أكّد التفعيل: 4. عطّل الوصول إلى Siri من شاشة القفل تتحدّث المساعدة الشخصية الافتراضية سيري مع جميع الناس وليس مع صاحب الهاتف فقط. ويمكن لأي شخص استخدامها من شاشة القفل. وهذا يفتح بابًا لاستخلاص البيانات من سيري دون الحاجة إلى فتح قفل الهاتف. وتجنّبًا لحدوث ذلك، قم بتعطيل الوصول إلى سيري من شاشة القفل بالذهاب إلى إعدادات Settings> Touch ID ورمز المرور Touch ID & Passcode> قم بتعطيل سيري من قسم السماح بالوصول عند القفل Allow access when locked: 5. تحكّم في وصول التطبيقات تحتوي هواتفنا على الكثير من تطبيقات الطرف الثالث، وأغلب هذه التطبيقات تتطّلب الوصول إلى بعض خصائص الهاتف أو بياناته مثل الصور، الرسائل، الميكروفون، جهات الاتصال، وغيرها. وهي بحاجة إلى تخويل الوصول لكي تعمل جميع خصائصها بشكل صحيح. على سبيل المثال، إذا قمت بتنزيل تطبيق لتعديل الصور، سيتطلّب هذا التطبيق الوصول إلى الصور والكاميرا لكي تكون قادرًا على التقاط الصور أو استيرادها من تطبيق الصور لتعديلها. وبالرغم من أنّ تقييد وصول التطبيقات يمكن أن يحرمك من بعض خصائصها، لكنّه أيضًا طريقة لتجنّب أي احتمالية لمعرفة بعض بياناتك الخاصة والحساسة وخصوصًا إذا كان التطبيق غير موثوق. اذهب إلى إعدادات Settings> الخصوصية Privacy> ادخل على أية فئة من القائمة (جهات الاتصال، التقويمات، خدمات الموقع، إلخ) ثم عطّل وصول التطبيق المرغوب: 6. عطّل الإشعارات في شاشة القفل تظهر الكثير من الإشعارات التي تصلنا على شاشة القفل، ويمكن قراءتها من قبل أي شخص دون فتح القفل. في بعض الأحيان تحتوي هذه الإشعارات مثل الرسائل، تنبيهات التقويم، البريد الإلكتروني وغيرها على معلومات يمكن أن تكون شخصية أو سرية. وبالرغم من أنّها خاصيّة مفيدة، إلّا أنّه من الأفضل تجنّب كشف الإشعارات للجميع بالذهاب إلى إعدادات Settings > Touch ID ورمز المرور Touch ID & Passcode> تعطيل عرض الإشعارات من قسم السماح بالوصول عند القفل Allow access when locked: 7. لا تفتح الروابط المشبوهة في بعض الأحيان تصلك رسائل نصيّة، أو رسائل بريد إلكتروني من مرسل مجهول، وقد تحتوي هذه الرسائل على روابط أو مرفقات يمكن أن تشكّل خطرًا على جهازك. فإذا كنت تشتبه بمصدر الرسائل أو طبيعتها لا تفتح الروابط لتجنّب أي احتمال للوصول إلى بياناتك الخاصّة. 8. حدّث نظام الهاتف باستمرار يبحث المخترقون عن الثغرات في تشفير iOS للوصول إلى بياناتك الخاصة، وتحاول Apple دائمًا تحسين أمان النظام وسد الثغرات من خلال التحديثات المستمرة. لذلك احرص دائمًا على تحديث نظام هاتفك بالذهاب إلى الإعدادات Settings> عام General> تحديث البرامج Software Update. سيتم التحقق من وجود تحديث، فإذا كان جهازك يشغّل آخر إصدارات النظام ستظهر الرسالة أدناه: أمّا إذا كان النظام يحتاج إلى تحديث، ستظهر رسالة تحتوي على إصدار النظام الجديد والمشاكل التي يقوم بإصلاحها، بإضافة إلى زر تنزيل وتثبيت Install Now لتحديث النظام. خاتمة لقد جمعنا لك النصائح أعلاه لزيادة أمان هاتفك وحمايته من أيّة احتمالية لاختراقه، لكن ليس من الضروري تطبيقها كلّها. اختر تلك التي تراها مناسبة وضرورية لحماية هاتفك وحسب نوع البيانات التي تريد تأمينها. كما يجب أن تكون حذرًا عند تفعيل بعض الخصائص (مثل مسح البيانات) وتفكر مليًا قبل استخدامها. هل هناك طرقًا أخرى تستخدمها لحماية بيانات هاتفك؟ شاركنا نصائحك عبر التعليقات.
  10. تُسهِّل برمجية ووردبريس إنشاءَ صفحاتٍ ومنشوراتٍ محميةٍ بكلمة مرور، وهذه ميزةٌ رائعة إذا أردتَ تقييد الوصول إلى محتوى معيّن، لكن المشكلة الوحيدة هي أنَّ أيّة صور أومقاطع فيديو تَعرِضُها في تلك الصفحات ستبقى متاحةً للوصول من صفحات الوسائط المرفقة. يمكن أن يتحول الأمر إلى إشكالية رئيسية إذا كانت تحتوي ملفات الوسائط على معلومات مهمة التي تريد أن تبقى محميةً بكلمة مرور. أحدحلول هذه المشكلة هو إلغاء دعم صفحات الوسائط (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
  11. إحدى أبسط الطرق لزيادة حماية موقعك هي عن طريق اختيار اسم مخصص لحساب مدير ووردبريس (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
  12. عملية تشفير الهاتف الذي يعمل بنظام الأندرويد عملية مهمة لحماية بياناتك من السرقة والاستغلال، ويمكن القيام بهذه العملية على الهواتف التي تحوي نظام الأندرويد الإصدار 2.3 فما فوق، بينما في العديد من الهواتف التي تعمل بالإصدار 5.0 فما فوق يُفترض أن لن تحتاج للقيام بهذه العملية لأنه يُفترض أن تكون مشفّرة تلقائيًّا. وعلى الرغم من أن جوجل قد أعلنت بأن جميع الهواتف التي ستعمل بنظام الأندرويد 5 ستكون مشفّرة تلقائيًّا بشكل أساسي منذ اللحظة الأولى لتشغيل الهاتف، وذلك في معرض إعلانها عن إطلاق نظام الأندرويد 5، إلا أنها تراجعت عن هذه السياسة بعد بضعة شهور، وادّعت الشركة بأن السبب هو أن عددًا من الهواتف التي أنتجتها مجموعة من الشركات المختلفة تتضمن مواصفات منخفضة وغير قادرة على تقديم أداء لائق في وجود التشفير. لكن عددًا من مواقع الإنترنت العالمية المختصة بمتابعة الأمور التقنية للهواتف وأنظمتها أكّدت أن السبب الحقيقي وراء تراجع جوجل عن هذه السياسة هو الأداء الهزيل الذي ظهر عليه هاتف Nexus 6 والذي افتتحت به الشركة نظام الأندرويد 5، حيث كان أداء هذا الهاتف أقل من هاتف Nexus 5 الأقدم، وذلك بسبب وجود التشفير التلقائي الكامل للبيانات، ما أجبر الشركة على التراجع وجعل وجود تقنية التشفير الكامل التلقائي للبيانات اختياريًّا لدى الشركات المنتجة للهواتف التي تعمل بهذا النظام، وذلك بحسب مواصفات كل هاتف. إن خوارزمية التشفير في أنظمة الأندرويد هي (Advanced Encryption Standard (AES بمفتاح 128 بت مبنية على نواة لينكس الأساس لنظام الأندرويد ما يجعل فك تشفير البيانات أمرًا مستبعدًا في الوقت الراهن في ظل السرعات الحالية للحواسيب وذلك لأن عدد العمليات اللازمة لكسر مفتاح بطول 128 بت هو 8 وبجانبه 37 صفرًا ، وهو ما يُطمئن مالكي الهواتف المشفرة بالنسبة لحماية بياناتهم من احتمالية الاستعادة وفك التشفير. يمكن لباقي الشركات المُصنّعة لهواتف الأندرويد أن تستخدم مفتاح تشفير 128 بت أو أعلى. ويقول Dan Schiappa المدير العام في شركة Sophos الأمنية: لم قد ترغب بتشفير هاتفك تعلّمنا في الدرس السابق طرق وأساليب قفل شاشة الهواتف التي تعمل بنظام الأندرويد، ولكن هذه الأساليب غير كافية لحماية البيانات الموجودة على الهاتف بصورة ممتازة، حيث يستطيع أي شخص لديه حاسوب وبعض الإلمام بالبرامج الخاصة بفتح الهواتف المقفلة أن يفتح قفل هذا الهاتف، ولو قام أحدهم بسرقة الهاتف فلن يشكّل قفل الهاتف أي عائق أمامه للوصول إلى كافة البيانات على الهاتف، وقد يحوي الهاتف بيانات مهمّة تتعلّق بالعمل كالحسابات المصرفية وحسابات أرباح الشركة والمراسلات الخاصة مع الشركات والزبائن وغيرها. وحتى إن كان هاتفك شخصيًّا ولا علاقة له بالعمل، فهو بالتأكيد يحوي على بريدك الإلكتروني وصورك الشخصية الخاصة جدًّا، بالإضافة إلى أي بيانات خاصة لا تريدها أن تقع بأيدي أحد حتى وإن كانت مجرّد أرقام هواتف. لذلك فمن الأفضل لك أن تقوم بتشفير الهاتف وهو ما يمنحه الحماية القصوى بحيث لن يتمكن اللص أو أي شخص تمّكن من الحصول على الهاتف بأي طريقة من الحصول على أي بيانات أو معلومات حتى ولو نجح في نسخ جميع محتويات الهاتف على حاسوبه بأي طريقة، فلن يتمكن من الاستفادة منها لأنها مشفّرة ومحمية وبحاجة إلى كلمة المرور الخاصة بك ليتمكّن من فك الشيفرة والحصول على البيانات. أيضًا أمر آخر مهم، فلو كنتَ تريد بيع الهاتف لأي سبب كان، فعليك أن تعلم بأن هناك برامج عديدة على الحاسوب وحتى على الهاتف يمكنها استعادة بياناتك كلّها حتى ولو قمت بإعادة تعيين بيانات المصنع للهاتف أو أدخلت رمز تهيئة الهاتف، فهذا لن يردع تلك البرامج من استعادة ملفاتك وبياناتك بسهولة، لذلك فإن الحل الأفضل في هذه الحالة هو تشفير الهاتف ثم تنفيذ عملية إعادة تعيين بيانات المصنع، وبذلك لن تتمكن تلك البرامج من الحصول على بياناتك، وحتى لو تمكّنت من ذلك فستكون بياناتك مشفّرة ولن يتمكّن مالك الهاتف الجديد من فك الشيفرة والاستفادة منها بأي شكل كان. أمور يجب معرفتها قبل البدء بتشفير الهاتف إن عملية تشفير الهاتف هي عملية باتجاه واحد، أي أنه لن تتمكن من العودة عن هذه العملية إلا بإعادة تعيين بيانات المصنع، وهذا سيتسبب بضياع البيانات على الهاتف ومحوها. إن عملية التشفير ستجعل الهاتف يقوم بفك تشفير البيانات التي ترغب في العمل عليها وإعادة تشفيرها بعد الانتهاء وقفل الهاتف، وهذا ما يتطلب عملًا إضافيًّا من المعالج، ما سيؤدّي إلى زيادة حرارة الهاتف وستلاحظ بعض البطء في أدائه أيضًا، وهذا ينطبق فقط على الهواتف ذات المواصفات الضعيفة بينما لن تشعر بأي تغيير في الهواتف ذات الإمكانات الجيدة. يجب التأكّد من أن البطارية ممتلئة ويُفضّل وصل الهاتف بقابس الشاحن أثناء العملية، لأنها قد تستغرق أكثر من ساعة، وذلك بحسب حجم البيانات على الهاتف. سيتوّجب عليك تحديد قفل الشاشة إمّا بكلمة المرور أو برمز PIN فقط عند اتخاذ قرار التشفير، وفي حال لم تقم بذلك ستظهر لك رسالة أثناء السير بخطوات التشفير تبلغك بضرورة القيام بذلك للمتابعة. إذا كنت قد قمت بعمل روت Root لهاتفك فيجب عليك إزالة الروت مؤقتًا لتشفير الهاتف ثم العودة مجدّدًا وعمل الروت من جديد بعد الانتهاء من عملية التشفير، لأن الروت قد يتسبب بفشل تشفير الهاتف ومحو البيانات التي عليه وقد يتسبب بمشاكل كبيرة في النظام أيضًا. لا يجب أن تتم مقاطعة العملية لأي سبب كان، وإلا فإن البيانات على الهاتف وإلا فإن البيانات على الهاتف قد تتعرض للتلف والضياع. كيفية تشفير الهاتف أولًا يجب أن نفهم بأن قائمة الضبط (الإعدادات) في هواتف الأندرويد تختلف قليلًا من إصدار لآخر وكذلك قد تختلف من نوع هاتف لآخر بحيث قد نجد خيار التشفير في بعض هواتف LG ضمن قائمة التخزين بينما قد نجدها في هواتف Samsung ضمن قائمة الحماية، لذلك يجب البحث قليلًا في هاتفك في حال لم يتطابق مع الصورة المُوّضحة في هذا الدرس. وحتى نتجنب الدخول إلى قائمة التشفير والعودة مجدّدًا بسبب عدم وضع كلمة مرور، قم بمتابعة الدرس السابق وضع كلمة مرور قبل البدء بالعملية. الآن قم الضغط على أيقونة الدخول إلى قائمة التطبيقات في الهاتف. ثم أدخل إلى أيقونة (الضبط) كما في الصورة. ثم أدخل إلى قائمة الحماية. (في بعض الهواتف قد تكون عملية التشفير موجودة ضمن قائمة التخزين). ثم اختر خيار تشفير الهاتف. في بعض الهواتف قد يكون هناك المزيد من الخيارات للتشفير كتشفير الهاتف وبطاقة التخزين معًا أو كلٌّ على حدة، هذا الأمر عائد إليك ولكننا هنا بصدد تشفير الهاتف فقط. ستظهر لك التعليمات العامة الخاصة بالتشفير. وفي حال لم تضع كلمة المرور بعد ستظهر لك رسالة تفيد بوجوب وضعها قبل البدء كما في هذه الصورة. ثم اضغط على خيار تشفير الجهاز ولا تنسَ أن تتأكّد من أن الهاتف مشحون بالكامل وموصول بقابس شحن البطارية. سيقوم الهاتف بإعادة التشغيل والبدء بعملية التشفير، قد تستغرق العملية وقتًا طويلًا. بعد الانتهاء سيقوم الهاتف بإعادة التشغيل مجدّدًا وهذه المرة سيطلب منك كلمة المرور لتتمكن من الدخول إلى الهاتف، وبهذا يكون الهاتف مشفّرًا. الأسئلة الأكثر شيوعا هل يمكن إلغاء ميزة التشفير والعودة إلى وضعية الهاتف بدون تشفير؟ في بعض الهواتف يمكن القيام بالعملية بسهولة من ذات القائمة ضمن ضبط الهاتف بحيث ستجد زر إلغاء التشفير ببساطة ولكن في هواتف أخرى لن تتمكن من إلغاء التشفير إلا بإعادة تعيين بيانات المصنع (ضبط المصنع) وهذا سيؤّدي إلى ضياع البيانات على الهاتف. إلا أن هذه الطريقة لن تنفع مع الهواتف التي تأتي مشفرة تلقائيًّا تشفير بيانات كامل والتي لا تحوي ضمن قوائم إعداداتها على خيار إلغاء التشفير لأن إعادة ضبط المصنع للهاتف ستبقي على وجود التشفير بطبيعة الحال لذلك لا يمكن إلغاء ميزة التشفير بالطرق الرسمية في هذه الحالة ولكن من الممكن القيام بذلك بطرق غير رسمية. هل يمكنني تغيير كلمة المرور أو رمز PIN بعد القيام بعملية التشفير بدون إلغاء تشفير الهاتف؟ نعم من خلال الدخول إلى قائمة قفل الشاشة وتغيير كلمة المرور بعد إدخال الكلمة القديمة أولًا وسيبقى الهاتف مشفرًا. هل يمكنني نقل الملفات بين هاتفي وحاسوبي بعد تشفير الهاتف؟ أم أن البيانات ستكون مشفرة ولن أستطيع الاستفادة منها؟ عندما ستحاول وصل الهاتف بالحاسوب سيكون عليك فتح قفل الهاتف لإتمام عملية الوصل وهذا سيؤدي إلى فك التشفير وبالتالي تستطيع أن تنقل بياناتك من الهاتف للحاسوب بسهولة ولن تكون مشفرة ما هو التشفير الكامل للقرص المستخدم في الأندرويد؟ هو تشفير جميع بيانات المستخدم الموجودة ضمن هاتف الأندرويد باستخدام مفتاح التشفير بناء على dm-crypt المستخدمة في تشفير البيانات المبينة على نواة لينوكس القوية أمنيًّا. ماذا لو نسيت كلمة المرور هل يمكنني استعادتها؟ في حالة التشفير لن تستطيع استعادة كلمة المرور بكل أسف وخصوصًا في الإصدار 5 فما فوق ولن يكون أمامك سوى إعادة الهاتف إلى ضبط المصنع وهذا سيؤدي إلى مسح بيانات الهاتف بالكامل، وقد تعمّدت جوجل ذلك لتأمين الحماية القصوى للبيانات من السرقة، ويبقى عليك تأمين حماية البيانات من الضياع وذلك عبر النسخ المتزامن للبيانات على الحاسوب أو بطاقة ذاكرة خارجية أو عبر أحد مواقع السحب الإلكترونية على الإنترنت ومن أهمّها سحابة جوجل. المصادر Google quietly backs away from encrypting new Lollipop devices by default من موقع ARS Technica Full Disk Encryption من موقع Android Are Android phones more easily hacked than iPhones من موقع USA Today How to disable encryption in Android Lollipop من موقع Android Central
  13. يُعدّ 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.
  14. كل واحد منّا بحاجة لأن يؤمّن هاتفه لأسباب عديدة وأهمها هو أن يحمي جهازه من التطفّل، فنقوم بوضع كلمة سر لمنع الآخرين من الولوج إليه، هناك طرق تقليدية ضمن نظام الأندرويد توفّر الحماية عبر وضع كلمة سر لشاشة القفل أو نمط معيّن، بالإضافة إلى إمكانية تشفير الهواتف بحيث يتم تأمين الحماية القصوى للهاتف وللبيانات الموجودة ضمنه، كما يوجد تقنيات حماية أخرى مختلفة كنمط الضيف، وتحوي بعض الهواتف على ميزات إضافية كمسح الوجه وبصمة الإصبع، وأخيرًا هناك تطبيقات تساعد على تأمين الهواتف بطرق مختلفة. وسنقوم هنا بالتعرّف على أساليب قفل الشاشة لحماية هاتف الأندرويد. لحماية الهاتف ببساطة سيكون علينا أن نقفل الشاشة بمعنى أنه إذا ما أطفأت الشاشة بنفسك أو انطفأت تلقائيًّا بعد مدة زمنية محددة (عادة ما تكون 10-15 ثانية) فيجب أن يكون هناك قفل للسماح للدخول مجدّدًا إلى الهاتف عند محاولة تشغيل الشاشة مجدّدًا كالضغط على الزر الأوسط الرئيسي أو زر التشغيل بنقرة واحدة ولتحقيق ذلك سيكون علينا القيام بما يلي. أولًا ادخل إلى قائمة التطبيقات بالضغط على زر المربعات أسفل الشاشة: وبعض إصدارات الأندرويد يكون شكل هذا الرمز هكذا: ثم ادخل إلى الضبط (الإعدادات): ثم ابحث في قوائم هذه الإعدادات عن خيار قفل الشاشة (حيث أن هذه القوائم تختلف من جهاز لآخر ومن إصدار أندرويد آخر): سيظهر لك خيار تأمين الشاشة وقد يكون الخيار موضوعًا على (السحب) أو (بلا) بكل الأحوال اضغط على الخيار في السطر الأول ذاته. ستحصل على مجموعة من الخيارات وهي: السحب، النمط، رمز PIN، كلمة المرور و "بلا" وستجد بأنه هناك شرح بجانب كل واحدة من هذه الخيارات تدل على مستوى الأمن الذي ستحصل عليه في حال اخترت أيًّا منها. الآن سنقوم بتجربتها جميعًا لتتعرّف عليها. وسنبدأ بخيار النمط. كما ترى هنا فالنمط يعني رسم توصيل معيّن خاص بك بين النقاط الواضحة في الصورة، يمكنك رسم أية طريقة توصيل تريدها المهم هو أن تحفظ طريقة التوصيل هذه حتى تتمكن من الدخول إلى الهاتف عند قفله. فعند إطفاء الشاشة ومحاولة الدخول إلى الهاتف مجدّدًا سوف تضطر إلى رسم ذات النمط الذي اخترته لتتمكن من الدخول إلى الهاتف ولذلك عليك حفظ النمط الذي ستختاره جيدًا وكلما كان معقّدًا أكثر كان أصعب على المتطفلين رسمه ذاته والدخول إلى الهاتف. وستلاحظ عند رسم النمط أنه لا يمكنك المرور على النقطة ذاتها مرتين ولكن يمكنك رسم أنماط متقاطعة صعبة التقليد إلا أنها ستكون أيضًا صعبة الحفظ للبعض وسيعتاد عليها البعض عند التكرار وهذه عينة. قد تعتقد للوهلة الأولى بأنني رسمت فوق النقطة المركزية أكثر مرة وأنا قلت لا يمكن الرسم على النقطة ذاتها مرتين ولكن الحقيقة أن ما تراه هو تقاطع خطوط ليس إلا فأن لم أرسم على النقطة ذاتها أكثر من مرة. وبعد رسم النمط للمرة الأولى اضغط على خيار المتابعة ثم ارسم النمط للمرة الثانية ثم اختر الخيار تأكيد لتظهر بعدها شاشة تطلب منك تعيين رقم PIN احتياطي وهذا ضروري في حال نسيت هذا النمط حتى تستطيع فتح القفل. أدخل رمز PIN وهو عبارة عن أربعة أرقام على الأقل ولكن ليس أكثر من ثمانية ثم اضغط متابعة وبعدها سيطلب منك تأكيد الرمز فقم بإعادة كتابته مجدّدًا واضغط موافق. هناك عدة خيارات للتحكم بمظهر شاشة القفل في كل حالة من الحالات والنمط واحدة منها كأن تجعل رسم النمط مخفي وهذا سيجعل من معرفة هذا النمط أمرًا شبه مستحيل خصوصًا إذا كام معقّدًا بالإضافة إلى خيارات أخرى يمكنك اكتشافها بنفسك منها وضع عبارة معينة على الشاشة ووضع ساعة أو غيرها. أو يمكنك اختيار رمز PIN وهو عبارة عن أرقام عددها بين الأربعة والثمانية تختارها بنفسك وبها تقفل شاشة الهاتف وللدخول مجدّدًا إليه سيتوجب عليك إدخال هذا الرمز. ويمكنك اختيار نفس الرقم مرتين، ذلك سيرفع من الحماية لأنه من سيشاهد آثار الأصابع على الشاشة لن يعرف أي رقم يجب أن يُكرّر. والأمر ذاته ينطبق على خيارات شاشة القفل وتخصيصها كما في النمط. وأخيرًا أهم وأقوى هذه الخيارات هو إدخال كلمة المرور والتي سيكون من الصعب جدًّا على المتطفلين معرفتها وإدخالها حتى لو كانوا بقربك في حال أدخلت كلمة طويلة ومتنوعة ما بين أرقام وحروف وبسرعة الإدخال بأصابعك عندها سيكون من الصعب جدًّا إيجاد هذه الكلمة. ماذا لو نسيت كلمة المرور أو رمز PIN أو نمط القفل فكيف سنتمكن عندها من فتح الهاتف؟ بعد عدّة محاولات فاشلة لفك القفل بما أنك نسيت الرمز أيًّا كان فسوف تظهر لك رسالة تخبرك بأنك أدخل الرمز أو النمط بشكل خاطئ عدّة مرات خلال فترة زمنية قصيرة لذلك حاول مجدّدًا بعد ثلاثين ثانية. ثم ستظهر لك ثلاثة خيارات إضافية في الأسفل. الأولى هي (رقم PIN للنسخ الاحتياطي) وهنا يمكنك إدخال رمز PIN الذي أدخلته عند رسم النمط. ماذا لو نسيته أيضًا، عندها نحتار الخيار الأوسط (نسيت النقش) وفيه نقوم بإدخال بريدنا الإلكتروني على GMAIL مع كلمة المرور ليتم إلغاء قفل الهاتف وتستطيع الدخول وتغيير رمز القفل مجدّدًا. أمّا إذا نسيت كلمة المرور لحسابك على GOOGLE فعليك بالتوجه إلى الحاسوب ومحاولة استعادة كلمة المرور ثم العودة مجدّدًا لفتح قفل الهاتف. ولو لم تكن قد ربطت هاتفك بحساب GOOGLE أو لا تتوفر أية شبكة إنترنت لأي سبب كان فهناك طرق عدة كربط الهاتف بالحاسوب واستخدام برامج معقّدة لفتح القفل أو استخدام ملفات الريكفري (الاستعادة) أو طرق أخرى ولكن هذه الطرق في معظمها ستفقد بياناتك على الهاتف بالكامل وجميعها معقد وقد يسبب التلف والأعطال للهاتف في حال لم تتقن القيام بها بالشكل الصحيح لذلك أنصحك وبشدّة باللجوء إلى أقرب مركز لصيانة الهواتف المحمولة أو إلى مركز الصيانة المعتمد لهاتفك وسيقوم بفتح قفل هاتفك بسهولة وسرعة وبدون التسبب بالأضرار للهاتف أو للبيانات التي عليها. ويجب التنبُّه في النهاية إلى مسألة زمن قفل الهاتف، فالهاتف لا يقفل خلال لحظة بعد بعد مدّة زمنية محدّدة وهي زمن تُحدّده أنتَ بعد توقف الشاشة عن العمل. بالنسبة إلى زمن توقّف الشاشة عن العمل فيمكن تحديده عبر الدخول إلى قائمة الضبط مجدّدًا ثم الدخول إلى قائمة (الشاشة). بعدها ندخل إلى قائمة (زمن توقف الشاشة). ثم نختار أحد الأزمنة المحدّدة بالقائمة. وبذلك ستتوقف الشاشة عن العمل وتنطفئ تلقائيًّا بعد المهلة الزمنية التي ستحدّدها في القائمة السابقة. والآن سنحدّد زمن قفل الهاتف وذلك بعد الدخول إلى قائمة الضبط مجدّدًا واختيار قائمة (قفل الشاشة). ثم الدخول إلى قائمة (القفل التلقائي). ثم نقوم بتحديد الزمن المطلوب ليتم قفل الهاتف بعده وذلك بعد توقف الشاشة عن العمل. أي بمعنى، هناك زمن تبقى فيه الشاشة مُضاءة وتعمل في حال لم تلمس الهاتف أو تعمل عليه سيتم توقف الشاشة عن العمل وتنطفئ بعد هذه المهلة المحدّدة ثم سيبدأ عدّاد زمني آخر بعد توقف الشاشة عن العمل في حال لم تلمس الهاتف أو لم تعمل عليه فسوف يتم بعدها قفل الهاتف بطريقة القفل التي اخترتها سابقًا كالنمط أو كلمة المرور مثلًا. هذا الأمر سيكون مطلوبًا في حالات خاصة، كأن تقوم مثلًا بالتجوّل باستخدام برنامج الخرائط في مكان ما وتحتاج في كل بضع دقائق أن تنظر إلى الخريطة مجدّدًا وتتأكّد من أنّك في الاتجاه الصحيح، عندها سيكون مُزعجًا فك القفل في كل مرّة خصوصًا إذا كانت كلمة مرور طويلة ومعقّدة أو نمطًا صعبًا، لذلك يمكننا تأخير قفل الهاتف بشكل لا نضطّر فيه إلى فتح الهاتف في كل مرّة في هذه الحالة. خاتمة البعض قد يختار طريقة النمط لسهولتها وسهولة حفظها نظرًا لأن طبيعة العقل تحفظ الرسوم أكثر من الكلمات والرموز والبعض الآخر يختار طريقة رمز PIN لأنها أسرع وأقصر ولكن الأفضل هو اختيار كلمة المرور لأنها الأقوى والأكثر أمانًا مما سبق. في كل الأحوال يبقى المهم هو تأمين الحماية للهاتف في حال وقع بأيدي أي شخص حتى لا يتمكن من فتح الهاتف وتصفح المحتوى الخاص بك بدون إذنك. هناك طرق أكثر قوة للحماية وطرق حماية أخرى تتعلق بنوع هذه الحماية والحالة التي نحتاج فيها إلى هذه الأنواع، سنتطرق إليها في دروس قادمة.
  15. تحدد صلاحيّات الملفّات من يستطيع قراءة، إنشاء، تحرير ملف و/أو فتحه، وهذه العملية مهمّة في ووردبريس، لأنها قد تحتاج إلى إمكانية إنشاء ملفات جديدة في مجلد 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.
  16. يُوفّر التّحكّم بخادوم لينكس الخاصّ بك فرصةً لتجربة أشياء جديدة والاستفادة من صلابة ومرونة هذه المنصّة الرّائعة. مع ذلك يجب على مسؤولي خواديم لينكس الانتباه إلى أنّ ميزات المنصّة لا تُغني عن التّدابير اللّازم اتّخاذها عند التّعامل مع حاسوب متّصل بالشّبكة، من أجل تأمينه وحمايته. تندرج العديدُ من الموضوعات الأمنيّة في الفئة العامة المسمّاة “أمان لينكس”، كما توجد العديد من الآراء حول مستوى الأمان المناسِب لخاودم لينكس. الفكرة الأساسيّة الّتي يجب العمل عليها هي تقرير نوعيّة الإجراءات الأمنيّة المطلوبة لحماية نظامك. قبل ذلك، ولكي تتّخذ القرارات المناسبة؛ يجب أن تعيَ الأخطار الموجودة والمقايضات الممكنة ثمّ تحدّد نقطة التّوازن بين قابليّة الاستخدام والأمان. يهدف هذا المقال إلى مساعدتك في اتّخاذ قراراتك عبر عرض بعض الإجراءات الأمنيّة الأكثر شيوعًا في البيئات الّتي تستخدم خواديم لينكس. يُرجى الانتباه إلى أنّ هذه القائمة غير شاملة ولا تتطرّق للإعدادات المنصوح بها؛ لكنّها ستُحيل إلى روابط توفّر موارد أكثر وتناقش مدى أهميّة بعض العناصر في نُظُم مختلفة. استخدام الجدران النّاريّة 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.
  17. 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.
  18. تنفيذ جدار الحماية هو خطوة هامة في تأمين الخادوم الخاص بك. جزء كبير من عملية التنفيذ هو اتخاذ قرارات بشأن القواعد والسياسات التي تفرض قيودا على حركة مرور البيانات. يسمح لك الجدار الناري أن يكون لك دور في بنية إطار العمل الذي يتم فيه تطبيق القواعد الخاصة بك. في هذا الدليل سوف نبني جدار حماية ليكون أساسا للمزيد من القواعد المعقدة. وسيركز هذا الجدار الناري في المقام الأول على تقديم افتراضات معقولة ووضع إطار سهل التمدد. سيكون تطبيق هذا الدليل على أوبنتو 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.
  19. ينصبّ الاهتمام عند إعداد بنية تحتيّة 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.
  20. إعداد جدارٍ ناريّ قوي هو خطوةٌ أساسية يجب فعلها بهدف تأمين أيّ نظام تشغيلٍ حديث. تأتي معظم توزيعات لينكس بأدواتٍ مختلفة يمكننا استخدامها لضبط جداراتنا الناريّة. في هذا الدرس، سنتحدّث عن جدار 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.
  21. من المعروف أن حزمة LEMP (والتي هي اختصار لـ Linux, Nginx, MySQL, PHP) توفر سرعة وموثوقية عالية لتشغيل مواقع PHP، إلّا أنها تملك مزايا أخرى غير مشهورة كالأمن والعزل. في هذا المثال، سنعرض لك مزايا أمن وعزل المواقع على LEMP مع مستخدمين مُختلفين، وهذا عن طريق إنشاء أحواض pools خاصّة بـ php-fpm لكل جزء من خادوم nginx (سواء كان موقعًا أو مستضيفًا افتراضيًا virtual host). المتطلبات الأساسية تمت تجربة هذا الدرس على أوبنتو 14.04 وعلى الرغم من ذلك فإن طريقة التثبيت والإعداد ستكون مشابهة لها على بقية الأنظمة والإصدارات، لكن قد تختلف الأوامر وأماكن ملفات الإعداد بين الأنظمة. كما أننا نفترض أنك قد ثبتت nginx و php-fpm، وبخلاف ذلك أنصحك بإتباع الخطوة الأولى والثالثة من هذا المقال: كيف تثبت حزم MySQL ،nginx ،Linux :LEMP وPHP على أوبنتو 14.04. يجب تنفيذ جميع الأوامر في هذا الدرس التعليمي بمستخدم غير الجذر (non-root)، وإن إحتجنا لصلاحياته فسنستخدم sudo، وإذا لم تُعدّ بعد هذا المستخدم فأنصحك بإتباع هذا الدرس: الإعداد الابتدائي لخادوم أوبنتو 14.04. ستحتاج أيضا إلى اسم نطاق مؤهل بالكامل (fully qualified domain name (fqdn الذي يربط على خادوم أو خادوم للتجربة بالإضافة إلى localhost الافتراضي، وإذا لم يكن لديك واحد، يمكنك استخدام site1.example.org، وذلك عن طريق تعديل ملف etc/hosts/ باستخدام محررك المفضل كهذا sudo vim /etc/hosts وأضف هذا السطر (استبدل site1.example.org بـ fqdn الخاص بك إذا كنت تستخدمه): ... 127.0.0.1 site1.example.org ... أسباب لزيادة تأمين LEMP عند إعداد LEMP مشترك سيكون هنالك حوض pool php-fpm واحد فقط والذي سيشغل جميع سكربتات PHP لجميع المواقع باستخدام نفس المستخدم، وهذا يطرح مشكلتين كبيرتين: إذا تعرض تطبيق ويب على أحد أجزاء خادوم nginx -على سبيل المثال عنوان فرعي أو موقع ما- إلى خطر أو هجوم فستتعرض جميع مواقع الموجودة على هذا الخادوم أيضا، فالمهاجم سيتمكن من قراءة ملفات الإعداد (configuration files) بما في ذلك تفاصيل قواعد بيانات لمواقع أخرى أو حتى تغيير ملفاتها. إذا أردت إعطاء مستخدم صلاحيات للدخول إلى الخادوم الخاص بك، فسوف تعطيه صلاحيات الوصول إلى جميع المواقع، فعلى سبيل المثال، إذا كان مطورك يحتاج إلى العمل على بيئة الإدراج (staging environment)، فحتى مع صلاحيات صارمة جدا على الملفات، فستبقى له إمكانية وصوله إلى جميع المواقع بما في ذلك موقعك الرئيسي على نفس الخادوم. المشاكل أعلاه تم حلها في php-fpm بإنشاء أحواض مختلفة والتي تشتغل تحت مستخدم مختلف لكل موقع. الخطوة الأولى - إعداد php-fpm إذا غطيت المتطلبات الأساسية فسيكون لديك في الوقت الحالي موقع ويب يعمل على خادوم. سننشئ الآن موقعًا ثانيًا (site1.example.org) مع حوض php-fpm ومستخدم لينكس مخصصين له. لنبدأ بإنشاء المستخدم الضروري، ولأفضل عملية فصل يجب أن يحصل المستخدم الجديد على مجموعته الخاصة لذلك سننشئ أولا مجموعة المستخدم site1: sudo groupadd site1 وبعد ذلك سننشئ مستخدم site1 ينتمي إلى هذه المجموعة: sudo useradd -g site1 site1 حتى الآن لا يملك هذا المستخدم الجديد كلمة مرور ولا يمكنك تسجيل دخوله في خادوم، إذا أردت توفير صلاحيات وصول إلى هذه الملفات من الموقع لشخص معين، فيجب عليك في هذه الحالة إنشاء كلمة مرور لهذا المستخدم عن طريق الأمر: sudo passwd site1 ومع تركيبة اسم المستخدم/كلمة المرور سيتمكن المستخدم من تسجيل دخوله عن بعد باستخدام ssh أو sftp. بعد ذلك، أنشئ حوض php-fpm جديد لـ site1، فالحوض مهم للغاية وهو عبارة عن عملية (process) لينكس عادية والتي تعمل تحت مستخدم/مجموعة محددة وتستمع لـ Linux socket وقد تستمع أيضا لتركيبة IP:Port لكن سيتطلب هذا إلى المزيد من موارد الخادوم وهذه الطريقة ليست جيدة. بشكل افتراضي في نظام أبنتو 14.04، كل حوض php-fpm يجب أن يتم إعداده في ملف داخل مجلد etc/php5/fpm/pool.d/. كل ملف مع امتداد conf. في هذا المجلد سيتم تحميله تلقائيا في الإعداد العام لـ php-fpm. لذلك سننشئ ملف etc/php5/fpm/pool.d/site1.conf/ لموقعنا، يمكنك فعل ذلك مع محررك المفضل كالتالي: sudo vim /etc/php5/fpm/pool.d/site1.conf يجب أن يحتوي هذا الملف على: [site1] user = site1 group = site1 listen = /var/run/php5-fpm-site1.sock listen.owner = www-data listen.group = www-data php_admin_value[disable_functions] = exec,passthru,shell_exec,system php_admin_flag[allow_url_fopen] = off pm = dynamic pm.max_children = 5 pm.start_servers = 2 pm.min_spare_servers = 1 pm.max_spare_servers = 3 chdir = / في الإعدادات أعلاه، لاحظ هذه الخيارات: إن [site1] هو اسم الحوض، فلكل حوض اسم خاص به. يشير كل من user و group إلى المستخدم المجموعة التي سيعمل عليها الحوض الجديد. ستشير listen إلى مكان خاص لكل حوض. إن كل من listen.owner و listen.group يعرّفان ملكية المستمع (listener) -على سبيل المثال socket الخاصة بحوض php-fpm الجديد- ويجب على Nginx أن يكون قادرا على قراءة هذا socket، وهذا هو سبب أن socket يُنشأ مع اسم المستخدم والمجموعة تحت nginx الذي يشغل www-data. يسمح لك php_admin_value بوضع قيم إعداد php مخصصة والتي سنستخدمها لتعطيل دوال التي تُشغّل أوامر لينكس مثل exec, passthru, shell_exec, system. إن php_admin_flag مشابه لـ php_admin_value لكنه مجرد مبدل لقيم المنطقية مثل on و off. سنعطل دالة PHP التي تدعى allow_url_fopen والتي تسمح لسكربت PHP بفتح ملفات عن بعد والتي يمكن أن تُستخدم بواسطة المهاجم. ملاحظة: إن قيم php_admin_value و php_admin_flag يمكن تطبيقها بشكل عام، وعلى الرغم من ذلك قد يحتاجهما الموقع وهذا هو سبب عدم إعدادهما بشكل افتراضي. إن من مميزات أحواض php-fpm أنها تسمح لك بتخصيص إعدادات أمن لكل موقع، وعلاوة على ذلك، فيمكنك استخدام هذه الخيارات لأي إعدادات php أخرى، خارج المجال الأمني، لتخصيص بيئة الموقع. لن نتحدث في درسنا حول الأمن عن خيارات pm، لكن يجب أن تعرف أنها تسمح لك بإعداد أداء الحوض. وبالنسبة إلى خيار chdir فيجب أن يكون / والذي يعبر عن جذر نظام الملفات، وهذا السطر لا يجب تغييره ما لم تكن تستخدم chroot. لم يتم تضمين خيار chroot في الإعدادات أعلاه لأنه سيسمح لك بتشغيل الحوض في بيئة مسجونة، مثل قفل المجلد، وهذا الأمر سيكون رائعًا لأغراض أمنية لأنه ستتمكن من قفل الحوض دخل مجلد الجذر للموقع، ولكن على الرغم من ذلك فإن هذا الخيار الأمني قد يتسبب بالعديد من المشاكل لأي تطبيق PHP يعتمد على تطبيقات النظام (system binaries) وتطبيقات مثل Imagemagick والتي لن تكون متوفرة. بمجرد انتهائك من الإعدادات أعلاه أعد تشغيل php-fpm لتفعيل الخيارات الجديدة وذلك عن طريق الأمر: sudo service php5-fpm restart تأكد من أن الحوض يعمل بشكل صحيح وذلك بواسطة البحث عن عملياته كالتالي: ps aux |grep site1 إذا اتبعت التعليمات بدقة فستحصل على مخرجات مشابهة لهذه: site1 14042 0.0 0.8 133620 4208 ? S 14:45 0:00 php-fpm: pool site1 site1 14043 0.0 1.1 133760 5892 ? S 14:45 0:00 php-fpm: pool site1 بالإضافة إلى ذلك، سنعطل التخزين المؤقت الذي يوفره opcache، فهذا الأخير قد يُحسّن الأداء لكنه قد يتسبب في مشاكل أمنية. لتعطيله، عدل ملف etc/php5/fpm/conf.d/05-opcache.ini/ باستخدام صلاحيات أعلى (super user) وأضف السطر التالي: opcache.enable=0 بعد ذلك أعد تشغيل php-fpm حتى تعمل الخيارات الجديدة: sudo service php5-fpm restart الخطوة الثانية - إعداد nginx بعد أن انتهينا من إعداد حوض php-fpm لموقعنا، سنقوم الآن بإعداد جزء الخادوم في nginx. ولذلك أنشئ ملفًا جديدًا وذلك باستخدام محررك المفضل كالتالي: sudo vim /etc/nginx/sites-available/site1 يجب أن يحتوي هذا الملف على: server { listen 80; root /usr/share/nginx/sites/site1; index index.php index.html index.htm; server_name site1.example.org; location / { try_files $uri $uri/ =404; } location ~ \.php$ { try_files $uri =404; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix:/var/run/php5-fpm-site1.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } } الشيفرة أعلاه تظهر إعدادات مشتركة لجزء الخادوم في nginx، لاحظ هذه الأجزاء: جذر الويب (Web root) هو usr/share/nginx/sites/site1/. اسم الخادوم يستخدم site1.example.org التي ذكرناها في جزء المتطلبات الأساسية من هذا الدرس. يحدد fastcgi_pass المتعامل (handler) لملفات php، يجب استخدام unix socket مختلفة لكل موقع مثل var/run/php5-fpm-site1.sock/. بعد ذلك أنشئ مجلد جذر الويب: sudo mkdir /usr/share/nginx/sites sudo mkdir /usr/share/nginx/sites/site1 لتفعيل الموقع أعلاه تحتاج إلى إنشاء رابط رمزي (symlink) له في مجلد /etc/nginx/sites-enabled/. يمكنك فعل ذلك باستعمال الأمر التالي: sudo ln -s /etc/nginx/sites-available/site1 /etc/nginx/sites-enabled/site1 في النهاية، أعد تشغيل nginx لتعمل التغييرات الجديدة كالتالي: sudo service nginx restart الخطوة الثالثة - التجارب للتجارب، سنستخدم دالة phpinfo والتي توفر لنا معلومات تفصيلية حول بيئة php. أنشئ ملفًا جديدًا باسم info.php والذي يحتوي على سطر واحد فقط: <?php phpinfo(); ?> ستحتاج هذا الملف في الموقع الافتراضي لـ nginx وفي جذر الويب /usr/share/nginx/html/، ولهذا الغرض يمكنك استخدام محرر النّصوص كالتالي: sudo vim /usr/share/nginx/html/info.php ثم انسخ الملف إلى جذر الويب للموقع الآخر (site1.example.org) كالتالي: sudo cp /usr/share/nginx/html/info.php /usr/share/nginx/sites/site1/ أنت الآن مستعد لتشغيل أبسط اختبار للتأكد من مستخدم الخادوم، يمكنك إجراء الاختبار عن طريق متصفح أو من خلال طرفية خادوم و lynx (متصفح يعمل عبر الطرفية)، وإذا لم تثبت lynx سابقا في خادوم فيمكنك تثبيته بكل سهولة عن طريق الأمر: sudo apt-get install lynx تأكد أولا من وجود ملف info.php في الموقع الافتراضي، ينبغي أن تتمكن من الوصول إليه عبر localhost كالتالي: lynx --dump http://localhost/info.php |grep 'SERVER\["USER"\]' في الأمر السابق نرشح المخرجات باستخدام grep لمتغير ["SERVER["USER فقط والذي يشير إلى مستخدم الخادوم، بالنسبة إلى الموقع الافتراضي يفترض أن تكون المخرجات تعرض مستخدم www-data الافتراضي كالتالي: _SERVER["USER"] www-data ونفس الشيء سنفعله للتأكد من مستخدم خادوم site1.example.org: lynx --dump http://site1.example.org/info.php |grep 'SERVER\["USER"\]' يجب أن ترى هذه المرة site1 في المخرجات: _SERVER["USER"] site1 إذا قمت بعمل أية تخصيصات في إعدادات php في أحواض php-fpm الأساسية، فيمكنك أيضا التأكد من قيمهما بنفس الطريقة السابقة وذلك عن طريق ترشيح المخرجات التي تهمك. حتى الآن، عرفنا أن موقعينا يعملان تحت مستخدمين مختلفين، لكن لنرى الآن كيف يمكننا تأمين الاتصال، لتفسير المشكلة الأمنية التي نريد حلها في هذا المقال، سننشئ ملفًا يحتوي على معلومات حساسة، في العادة يحتوي هذا الملف معلومات الاتصال بقاعدة البيانات ويحتوي على تفاصيل اسم المستخدم وكلمة المرور لقاعدة بيانات المستخدم، فإذا وُجد أن أحدهم يستطيع الوصول إلى هذه المعلومات فسيتمكن من فعل أي شيء لموقعنا. أنشئ باستخدام محررك المفضل ملفًا جديدًا في موقعك الرئيسي يدعىusr/share/nginx/html/config.php/ ويحتوي على التالي: <?php $pass = 'secret'; ?> في الملف أعلاه عرّفنا متغيرًا يدعى pass والذي يحتوي على قيمة secret، وطبعا نريد تقييد الوصول إلى هذا الملف لذلك سنغير الصلاحيات إلى 400، والتي تعطي صلاحيات القراءة فقط لمالك الملف. لتغيير الصلاحيات إلى 400 نفذ الأمر التالي: sudo chmod 400 /usr/share/nginx/html/config.php بالإضافة إلى ذلك موقعنا الرئيسي يعمل تحت مستخدم www-data والذي يجب أن يكون قادرًا على قراءة هذا الملف، وبالتالي، غيّر ملكية الملف إلى ذاك المستخدم كالتالي: sudo chown www-data:www-data /usr/share/nginx/html/config.php في مثالنا سنستخدم ملفًا آخر يدعى usr/share/nginx/html/readfile.php/ لقراءة المعلومات السرية ومن ثم طباعتها، ويجب أن يحتوي هذا الملف على الشيفرة البرمجية التالية: <?php include('/usr/share/nginx/html/config.php'); print($pass); ?> بعد ذلك غيّر ملكية هذا الملف لمستخدم www-data كالتالي: sudo chown www-data:www-data /usr/share/nginx/html/readfile.php للتأكد من جميع الصلاحيات والملكيات في جذر ويب، نفّذ الأمر التالي: ls -l /usr/share/nginx/html/ يجب أن تكون المخرجات شبيهة بهذه: -r-------- 1 www-data www-data 27 Jun 19 05:35 config.php -rw-r--r-- 1 www-data www-data 68 Jun 21 16:31 readfile.php الآن جرب الوصول إلى الملف السّابق على موقعك الافتراضي باستخدام الأمر: lynx --dump http://localhost/readfile.php ستلاحظ أن secret مطبوعة على الشاشة والتي تعني أن الملف مع المعلومات الحساسة يمكن الوصول إليه من داخل نفس الموقع، وهذا السلوك متوقع. الآن جرب نسخ ملف usr/share/nginx/html/readfile.php/ إلى موقعك الثاني site1.example.org كالتالي: sudo cp /usr/share/nginx/html/readfile.php /usr/share/nginx/sites/site1/ للحفاظ على علاقات الموقع/المستخدم، تأكد من أن الملفات داخل كل موقع مملوكة من طرف المستخدم المعني وذلك عن طريق تغيير ملكية الملف المنسوخ إلى site1 باستخدام الأمر التالي: sudo chown site1:site1 /usr/share/nginx/sites/site1/readfile.php للتحقق من وضعك الصلاحيات والملكيات الصحيحة للملفات، اعرض قائمة محتويات جذر ويب site1 باستخدام الأمر: ls -l /usr/share/nginx/sites/site1/ يجب أن ترى كالتالي: -rw-r--r-- 1 site1 site1 80 Jun 21 16:44 readfile.php بعد ذلك حاول الوصول إلى نفس الملف من site1.example.com باستخدام الأمر: lynx --dump http://site1.example.org/readfile.php سترى أنه تم إرجاع مساحة فارغة، وبالإضافة إلى ذلك، إذا بحثت عن الأخطاء في سجل الأخطاء لـ nginx باستخدام الأمر grep التالي: sudo grep error /var/log/nginx/error.log فسترى شيئا مشابها لهذا: 2015/06/30 15:15:13 [error] 894#0: *242 FastCGI sent in stderr: "PHP message: PHP Warning: include(/usr/share/nginx/html/config.php): failed to open stream: Permission denied in /usr/share/nginx/sites/site1/readfile.php on line 2 ملاحظة: سترى أيضا خطأ مشابهًا في مخرجات lynx إذا فعّلت خيار display_errors في إعدادات php-fpm في ملف etc/php5/fpm/php.ini/ (بوضع On في ذلك الخيار). يظهر التحذير أن السكربت من موقع site1.example.org لا يمكنه قراءة الملف الحساس (config.php) من الموقع الرئيسي وبالتالي، المواقع التي تعمل تحت عدة مستخدمين لا يمكنها تعريض أمن بقية المواقع. إذا ذهبت إلى نهاية جزء الإعدادات من هذا المقال، سترى أننا عطلنا التخزين المؤقت التي يوفرها opcache بشكل افتراضي، وإذا رغبت بمعرفة السبب حاول تفعيله مجددا وذلك عن طريق وضع opcache.enable=1 في ملفetc/php5/fpm/conf.d/05-opcache.ini/ عن طريق مستخدم sudo ومن ثم إعادة تشغيل php5-fpm باستخدام الأمر sudo service php5-fpm restart. ستجد أنه إذا قمت بإعادة خطوات الاختبار بنفس الترتيب فإنك ستتمكن من قراءة الملف الحساس على الرغم من صلاحياته وملكياته، وهذه المشكلة في opcache قد تم الإبلاغ عنها منذ فترة طويلة لكن لم يتم إصلاحها حتى وقت كتابة هذا المقال. الخاتمة من الناحية الأمنية، يجب استخدام أحواض php-fpm مع مستخدم مختلف لكل موقع على نفس خادوم ويب nginx، فهذا الأمر حتى لو كان يضْعف الأداء قليلا، فإن ميزة عملية الفصل يمكنها منع خروق أمنية خطيرة. الفكرة التي شرحناها في هذا المقال ليست فريدة، وهي موجودة في تقنيات فصل PHP أخرى مثل SuPHP. وعلى الرغم من ذلك، أداء بقية البدائل أسوء من php-fpm. ترجمة -وبتصرف- للمقال: How To Host Multiple Websites Securely With Nginx And Php-fpm On Ubuntu 14.04 لصاحبه Anatoliy Dimitrov.
  22. أحيانًا تكون على شبكة غير آمنة أو لديها جدار ناري يملك قيودًا مُفرطة، وتحتاج الوصول إلى موقع على شبكة الإنترنت. تريد أن تتأكد أنه لا أحد في المنتصف يشاهد البيانات المارة. أحد الحلول هو استخدام VPN، ولكن يتطلب VPN برنامج عميل خاص على حاسوبك، وقد لا يكون لك صلاحيات اللازمة لتثبيته. إذا كان كل ما تريد تأمينه هو متصفح الويب الخاص بك، فهناك بديل بسيط: نفق وسيط SOCKS 5. وسيط SOCKS هو بالأساس نفق SSH حيث توّجه تطبيقات مُحدّدة دفق بياناتها خلال النفق إلى الخادوم، ثمّ على الخادوم، يقوم الوسيط (Proxy) بإعادة توجيه دفق البيانات إلى شبكة الإنترنت. على عكس VPN، يجب أن يتم ضبط وسيط SOCKS لكل تطبيق على حدة في حاسوب العميل، ولكن يُمكن إعداده بدون أي وكلاء عميل متخصصة. طالما لديك خادوم بوصول SSH، فيمكن استخدامه كوسيط SOCKS. سنستخدم خادوم أوبنتو 14.04 كالوسيط، ومتصفح فَيرفُكس كتطبيق العميل. وعندما ننتهي ينبغي أن تكون قادرًا على تصفح المواقع بشكلٍ آمن عبر النفق. المتطلبات كما ذُكر بالأعلى، أول شيء نحتاجه هو خادوم يعمل بأي توزيعة لينكس، مثل أوبنتو 14.04، بوصول SSH. أنشئ خادوما (هذا المثال يستخدم أوبنتو 14.04) مطلوب تثبيت بعض البرمجيات على حاسوبك المحلي. لهذا ستحتاج أن تُنزل برنامجًا أو اثنين. متصفح فَيرفُكس (للجميع) PuTTY (مستخدمي ويندوز) يُمَكننا فَيرفُكس من إعداد الوسيط لفَيرفُكس فقط بدلًا من إعداد الوسيط لكامل النظام. يُستخدم PuTTY لإعداد نفق الوسيط لمستخدمي ويندوز. لدى مستخدمي Mac OS X أو لينكس الأدوات اللازمة لإعداد النفق مُثبتة مسبقًا. الخطوة الأولى (Mac OS X/لينكس) - إعداد النفق أنشئ مفتاح SSH على حاسوبك المحلي. إذا كان لديك مفتاح SSH، فيمكنك استخدامه. على الرغم من أن تحديد كلمة مرور لمفتاح SSH هي عادة جيدة، سنترك كلمة المرور فارغة الآن لنتجنب مشاكل لاحقة. وأنت تَعُدّ المفتاح، تأكد أن تُضيفه للمفاتيح المخولة لمستخدم sudo على الخادوم (في هذا المثال، هذا هو المستخدم sammy). افتح برنامج الطرفية على حاسوبك. على Mac OS X، تجد الطرفية Terminal في Applications > Utilities. أنشئ النفق بهذا الأمر: $ ssh -D 8123 -f -C -q -N sammy@example.com شرح المعاملات D-: يُخبر SSH بأننا نريد نفق SOCKS على رقم المنفذ المُحدد (اختر رقم بين 1025-65536) f-: يضع العملية في الخلفية C-: يضغط البيانات قبل إرسالها q-: يستخدم الوضع الصامت N-: يُخبر SSH بأنه لا يوجد أي أمر سيُرسَل بمجرد فتح النفق تأكد من استبدال sammy@example.com بمستخدم sudo الخاص بك وعنوان IP أو اسم نطاق الخادوم. بمجرد أن تُدخل الأمر، ستعود إلى مِحث سطر الأوامر مرة أخرى بدون أي إشارة على النجاح أو الفشل؛ هذا طبيعي. تحقق من أن النفق يعمل بالأمر: $ ps aux | grep ssh ينبغي أن ترى سطرًا في المُخرجات مثل: sammy 14345 0.0 0.0 2462228 452 ?? Ss 6:43AM 0:00.00 ssh -D 8123 -f -C -q -N sammy@example.com يمكنك إغلاق تطبيق الطرفية وسيظل النفق يعمل. هذا لأننا استخدمنا الخيار f- الذي يضع جلسة SSH في الخلفية. ملاحظة: إذا أردت أن تُنهى النفق سيتوجب عليك معرفة PID الجلسة عبر ps واستخدام الأمر kill، وهذا ما سنُريك كيفية القيام به لاحقًا. الخطوة الأولى (ويندوز) - إعداد النفق افتح PuTTY. إذا لم تُثبته بعد، نزل PuTTY واحفظه بالمكان الذي تُحب. لا يحتاج PuTTY صلاحيات المُدير لتثبيته؛ حمل الملف التنفيذي exe. وشغلهُ فقط. أكمل الخطوات التالية لإعداد النفق: من قسم Session، أضف اسم مُضيف (أو عنوان IP) Host Name (or IP address) خادومك، ومنفذ Port SSH (عادة يكون المنفذ رقم 22) على الجانب الأيسر، انتقل إلى: Connection > SSH > Tunnels ادخل رقم أي منفذ مصدري source port بين 1025-65536. استخدمنا في هذا المثال المنفذ رقم 1337 اختر Dynamic اضغط Add ارجع إلى Session على الجانب الأيسر. اضف اسم اسفل Saved Sessions واضغط زر Save الآن اضغط Open لتفتح الاتصال ادخل اسم مُستخدم sudo وكلمة سر الخادوم للدخول. يمكنك تصغير نافذة PuTTY الآن، لكن لا تُغلقها. ينبغي أن يفتح اتصال SSH. تلميحة: يمكنك حفظ اسم مُستخدم sudo ومفتاح SSH للجلسة الحالية باتباع تعليمات مفتاح SSH الخاص ببرنامج PuTTY. وهكذا لن تَضطرّ إلى إدخال اسم المُستخدم وكلمة السر كل مرة تفتح الاتصال. الخطوة الثانية - ضبط متصفح فَيرفُكس Firefox ليستخدم النفق الآن بما أنه أصبح لدينا نفق SSH، فقد حان الوقت لضبط فَيرفُكس ليستخدم هذا النفق. تذكر لكي يعمل نفق SOCKS 5، يجب أن تستخدم تطبيق محلي يُمكنهُ استغلال النفق؛ فَيرفُكس يقوم بهذا. هذه الخطوة متشابهة لمُستخدمي ويندوز، Mac OS X ولينكس. تأكد أن لديك رقم المنفذ الذي استخدمته في أمر SSH أو في PuTTY. لقد استخدمنا 8123 في مثال OS X / لينكس و 1337 في مثال ويندوز حتى الآن، أو قد تكون استخدمت منفذًا مُختلفًا. نُفذَت الخطوات التالية على نُسخة فَيرفُكس 39 وينبغي أن تعمل على النُسخ الأخرى، على الرغم من احتمال اختلاف أماكن الخيارات. اضغط على أيقونة الهامبرجر في أعلى الركن الأيمن للوصول إلى قائمة فَيرفُكس: اضغط على أيقونة Preferences أو Options انتقل لقسم Advanced اضغط على تبويب Network اضغط على Settings أسفل العنوان Connection. ستفتح نافذة جديدة. اختر Manual proxy configuration: اكتب localhost أمام SOCKS HOST ادخل نفس رقم المنفذ Port من اتصال SSH الخاص بك؛ ترى في الصورة أننا أدخلنا 1337 ليُطابق تعليمات ويندوز. اضغط OK لحفظ وإغلاق ضبطك. الآن، افتح تبويبًا آخر في فَيرفُكس وتصفح الإنترنت. ينبغي أن يكون كل شيء جاهز للتصفح الآمن عبر نفق SSH الخاصة بك. اختياري: لتتأكد أنك تستخدم الوسيط، ارجع إلى إعدادات الشبكة Network في فَيرفُكس. أدخل رقم منفذ مُختلف. اضغط OK لحفظ الإعدادات. الآن إذا جربت تصفح الإنترنت، ينبغي أن ترى رسالة الخطأ The proxy server is refusing connections. هذا يؤكد أن فَيرفُكس يستخدم الوسيط وليس الاتصال الافتراضي. عُد إلى رقم المنفذ الصحيح، وينغي أن تكون قادر على التصفح مرة أخرى. العودة إلى التصفح العادي غير الآمن في فَيرفُكس عندما تنتهي حاجتك لخصوصية نفق SSH، ارجع إلى إعدادات وسيط الشبكة (Preferences > Advanced > Network > Settings) في فَيرفُكس. اختر Use system proxy settings واضغط OK. سيستخدم فَيرفُكس الآن إعدادات اتصالك العادي، ومن المرجح أن يكون غير آمن. إذا انتهيت من استخدام النفق يجب أن تُغلق النفق أيضًا، وهذا ما سنُغطيه في الخطوة التالية. إذا كنت تنوي استخدام النفق كثيرًا، فاتركه مفتوحًا للاستخدام لاحقًا، لكن لاحظ أنه قد يُغلق من تلقاء نفسه إذا بقي خاملًا (غير مُستخدم) لمدة طويلة، أو إذا سَكَن (sleep) حاسوبك. الخطوة الثالثة (Mac OS X/لينكس) - إغلاق النفق سيوقف إغلاق النفق قدرة فَيرفُكس على التصفح بالوسيط. أُرسل النفق الذي أنشأناه سابقًا على حاسوبنا المحلي إلى الخلفية، لذا لن يُنهيه إغلاق نافذة الطرفية التي استخدمناها لفتح النفق. لإنهاء النفق نحتاج أن نُحدد مُعَرف العملية (PID) باستخدام الأمر ps، ثم قتله باستخدام الأمر kill. فلنبحث عن كل عمليات ssh على حاسوبنا: $ ps aux | grep ssh جد السطر الذي يبدو كالأمر الذي أدخلته سابقًا لإنشاء النفق. هذا مثال على المخرجات: sammy 14345 0.0 0.0 2462228 452 ?? Ss 6:43AM 0:00.00 ssh -D 8123 -f -C -q -N sammy@example.com من بداية السطر، في واحد من العمودين الأولين، هناك رقم مكون من ثلاثة إلى خمسة أعداد. هذا هو رقم PID. وفي المخرجات السابقة هو الرقم 14345. بعد أن عرفنا رقم PID، يُمكننا استخدام الأمر kill لنُغلق النفق. استخدم رقم PID الخاص بك عندما تقتل العملية. $ sudo kill 14345 إذا أردت أتمتت عملية الاتصال، اذهب للخطوة الرابعة. الخطوة الثالثة (ويندوز) - إغلاق النفق سيوقف إغلاق النفق قدرة فَيرفُكس على التصفح بالوسيط. اغلق نافذة PuTTY التي استخدمتها لإنشاء النفق فقط. لا يوجد في ويندوز طريقة سهلة لأتمتة عملية الاتصال، لكن PuTTY وفَيرفُكس يمكنهما حفظ الإعدادات التي أدخلتها سابقًا، لذا افتح الاتصالات فقط مرة أخرى لتستخدم النفق مجددًا. الخطوة الرابعة (Mac OS X/لينكس) - إنشاء اختصارات للاستخدام المتكرر يمكننا إنشاء أمر بديل أو سكربت في أنظمة لينكس أو OS X لكي يُنشئ النفق سريعًا من اجلنا. سنعرض طريقتين لأتمتة عملية إنشاء النفق. ملاحظة: طريقتي الاختصار كلاهما تَتَطلبان مفتاح SSH بلا كلمة سر للوصول إلى الخادوم. 1. سكربت BASH قابل للنقر إذا أردت أيقونة لتضغط عليها مرتين فيبدأ النفق، يمكن أن نُنشئ سكربت BASH بسيط للقيام بهذه المهمة. سنجعل السكربت يقوم بإعداد النفق وتشغيل فَيرفُكس، على الرغم من أنك ستظل في حاجة إلى إضافة إعدادات الوسيط يدويًا بالمرة الأولى في فَيرفُكس. ملف فَيرفُكس الثُنائي على OS X الذي يمكننا تشغيله من سطر الأوامر هو داخل Firefox.app. بافتراض أن التطبيق في مُجلّد التطبيقات Applications، سنجد الملف الثُنائي في Applications/Firefox.app/Contents/MacOS/firefox/. على أنظمة لينكس، إذا ثبتّت فَيرفُكس عبر مستودع أو كان مُثبت مسبقًا، فينبغي أن تجده في usr/bin/firefox/. يمكنك دائمًا استخدام الأمر which firefox لمعرفة موقعه على نظامك. استبدل في السكربت الذي بالأسفل مسار فَيرفُكس بالمسار المناسب لنظامك. باستخدام مُحرر نصوص مثل nano أنشئ ملف جديد: $ nano ~/socks5.sh وأضف السطور التالية إليه: #!/bin/bash ssh -D 8123 -f -C -q -N sammy@example.com /Applications/Firefox.app/Contents/MacOS/firefox & استبدل 8123 برقم المنفذ الذي تريده، يجب أن يُطابق ما وضعته في فَيرفُكس استبدل sammy@example.com بمُستخدم SSH الخاص بك واسم المُضيف أو عنوان IP استبدل Applications/Firefox.app/Contents/MacOS/firefox/ بمسار ملف فَيرفُكس الثُنائي احفظ السكربت. تقوم بهذا في nano بالضغط على Ctrl-o، ثم اخرج بالضغط على Ctrl-x. اجعل السكربت قابلًا للتنفيذ، لكي يتم تنفيذه عندما تضغط عليه مرتين. ادخل هذا الأمر في سطر الأوامر لتُضيف صلاحيات التنفيذ، باستخدام مسار السكربت الخاص بك: $ chmod +x /path/to/socks5.sh قد تحتاج في OS X القيام بخطوات إضافية لتُخبر Mac OS X أن ملف بلاحقة .sh يجب أن يُنَفَذ كبرنامج وألا يتم فتحه في مُحرر. لتقوم بهذا، اضغط بزر الفأرة الأيمن على ملف socks5.sh واختر Get Info. جد القسم Open with: وإذا لم يُشر سهم الكشف إلى الأسفل، اضغط عليه لكي ترى القائمة المُندسلة. قد تجد Xcode مضبوطًا كالتطبيق الافتراضي. غيره إلى Terminal.app. إذا لم تجد Terminal.app بالقائمة، اختر Other، ثم انتقل إلى Applications > Utilities > Terminal.app. اضغط مرتين على ملف socks.sh لتفتح وسيط SOCKS الخاص بك الآن. ملاحظة: بعد التنفيذ، لن يطلب السكربت كلمة سر، ولذلك سيفشل بصمت إذا أعددت مفتاح SSH مُسبقًا ليطلب كلمة مرور. سوف يفتح السكربت نافذة الطرفية، يبدأ اتصال SSH ويُشغل فَيرفُكس. لا تخش من إغلاق نافذة الطرفية. يمكنك الآن أن تبدأ التصفح في اتصالك الآمن، طالما أنك تحتفظ بإعدادات الوسيط في فَيرفُكس. 2. إنشاء Alias إذا وجدت أنك تستخدم سطر الأوامر كثيرًا وتُريد تشغيل النفق، يمكنك إنشاء Alias ليقوم بالمهمة من أجلك. الجزء الأصعب في إنشاء Alias هو أين تحفظه. تحفظ توزيعات لينكس وإصدارات OS X المختلفة الـ aliases في أماكن مختلفة. أفضل طريقة هي البحث عن أحد الملفات التالية وتبحث بداخله عن الكلمة alias لترى أين تُحفظ الأوامر البديلة الأخرى حاليًا. ~/.bashrc ~/.bash_aliases ~/.bash_profile ~/.profile بمجرد إيجاد الملف الصحيح، أضف هذا السطر التّالي أسفل Aliases موجودة لديك، أو فقط بنهاية الملف. alias socks5=’ssh -D 8123 -f -C -q -N sammy@example.com && /Applications/Firefox.app/Contents/MacOS/firefox &’ استبدل 8123 برقم المنفذ الذي تريده، يجب أن يُطابق ما وضعته في فَيرفُكس استبدل sammy@example.com بمُستخدم SSH الخاص بك واسم المُضيف أو عنوان IP استبدل Applications/Firefox.app/Contents/MacOS/firefox/ بمسار ملف فَيرفُكس الثُنائي يتم تحميل الـ aliases فقط عندما تبدأ صدفة جديدة، لذا أغلق جلسة طرفيتك وابدأ واحدة جديدة. الآن عندما تكتب: $ socks5 هذا الأمر يقوم بإنشاء نفقك، ثم يُشغل فَيرفُكس ويُعيدك إلى مِحث الأوامر. تأكد أن فَيرفُكس مضبوط ليستخدم الوسيط (proxy). يمكنك الآن التصفح بشكلٍ آمن. الخطوة الخامسة (اختياري) - استكشاف الأخطاء وإصلاحها: المرور عبر الجدران النارية إذا كان اتصالك يعمل، فلا حاجة لك لقراءة هذا القسم. ومع ذلك، إذا اكتشفت أنه لا يمكنك إنشاء اتصال SSH بسبب جدار ناري تقييدي، فالمرجح أن المنفذ 22، وهو المطلوب لإنشاء النفق، محجوب. إذا كان بإمكانك التحكم في إعدادات خادوم وسيط SSH، يمكنك إعداد SSH للإنصات إلى منفذ آخر غير 22. ما المنفذ غير المحجوب الذي يمكنك استخدامه؟ بجانب الخطة المشكوك بها لفحص المنافذ باستخدام أداة مثل ShieldsUP، مشكوك بها لأن شبكتك المحلية قد تُفسر هذا كهجوم، فالأفضل تجربة منافذ تُترك مفتوحة عادة. المنافذ المتروكة مفتوحة عادةً تكون 80 (لحركة مرور الويب العامة) و 443 (لحركة مرور SSL). إذا لم يكن خادوم SSH الخاص بك يخدم محتوى ويب، يمكننا أن نخبر SSH ليستخدم أحد هذين المنفذين ليتصل عبره بدلا من المنفذ الافتراضي 22. المنفذ 433 هو أفضل اختيار لأنه مُتَوقع أن يكون هناك حركة مرور مُشفرة على هذا المنفذ، وحركة مرور SSH الخاصة بنا ستكون مُشفرة. ابدأ اتصال SSH لخادومك من مكان غير محمي بجدار ناري، ثم حرّر ملف إعدادات SSH: $ sudo nano /etc/ssh/sshd_config ابحث عن السطر Port 22. يمكننا إما استبدال 22 كُليًا، وهي فكرة جيدة لزيادة أمان SSH، أو إضافة منفذ آخر ليُنصت SSH إليه. سنختار انصات SSH إلى منافذ متعددة، لذا سنُضيف سطر جديد أسفل Port 22 الذي يُقرأ Port 443. وإليك مثال لملف sshd_config: ... Port 22 Port 443 ... أعد تشغيل SSH لكي يُعيد تحميل ضبط SSH الذي أدخلته. قد يختلف اسم عفريت خادوم SSH بالاعتماد على توزيعتك، لكن من المرجح أن يكون اسمه ssh أو sshd. إذا لم يعمل أحدهما جرّب الآخر. $ sudo service ssh restart لتتحقق من أن منفذ SSH يعمل، افتح صدفة جديدة، لا تُغلق الجلسة الحالية بعد، فقد تحتاجها في حالة أغلقت الباب على نفسك وأنت خارج الخادوم بدون قصد، وابدأ اتصال SSH باستخدام المنفذ الجديد. $ ssh sammy@example.com -p 443 إذا نجحت بالاتصال، فيُمكنك الخروج الآن من الصدفتين وفتح نفق SSH باستخدام المنفذ الجديد. $ ssh -D 8123 -f -C -q -N sammy@example.com -p 443 ستكون إعدادات فَيرفُكس هي نفسها لأنه لا يعتمد على منفذ SSH، وإنما منفذ النفق (8123 كما بالأمر السابق). خاتمة افتح نفق SOCKS 5 للتصفح من خلال نفق SSH آمن كلما أردت طريقة خفيفة للوصول للويب بمأمن من أعين المُتطفلين. ترجمة -وبتصرّف- للمقال How To Route Web Traffic Securely Without a VPN Using a SOCKS Tunnel لصاحبه Michael Holley.
  23. تتوفّر على توزيعات لينكس برامج تحظُر إنشاء كلمات سر يسهُل تخمينها؛ فالوصول إلى الكثير من بيانات المستخدم وبرامجه يتطلّب تجاوز مرحلة إدخال كلمة السرّ ، الأمر الذي يجعل من كلمات السر نقطة حرجة في سبيل تأمين النظام والمستخدم على حدّ السواء ويجب بالتالي الحرص دائما على أن تكون محدَّثة. توجد الكثير من طرق تعمية البيانات ولكلّ منها خصوصيّاته. تستخدم أغلب توزيعات لينكس خوارزميّة تعمية تُسمّى معيار تعميّة البيانات Data Encryption Standard, DES لتعميّة كلمات السّر. تُخزّن كلمات السرّ المعمّاة في ملف etc/passwd/ أو etc/shadow/. عندما يحاول المستخدم الولوج إلى النظام فإن كلمة السّر التي يُدخِلها تُعمَّى ثم تقارن بحقل كلمة السّر المعمّاة في الملف، فإن حصل تطابق فهذا يعني أنها نفس كلمة السّر وبالتالي يُسمح له بالولوج. تستخدم أغلب توزيعات لينكس نسخة من DES لا تعمل إلا في اتجاه واحد؛ بمعنى أنه يمكن استخدامها لتعميّة كلمة سر ولكن لا يمكن استخدامها لفك تعميّة كلمات السر في ملفّي etc/passwd/ وetc/shadow/. يمكن لبرامج هجمات القوة العمياء Brute force attacks مثل John the Ripper وCrack تخمين كلمات السر التي لا تحترم حدًّا أدنى من العشوائية؛ وبإمكان مديري النّظم استخدامها لصالحهم في طريقة استباقية بتنفيذها على كلمات سرّ مستخدميهم للعثور على كلمات السّر غير الآمنة ثم الطلب من هؤلاء تغييرها إلى أخرى آمَن. التعمية بالمفاتيح العمومية تستخدم التعمية بالمفاتيح العمومية Public-Key Cryptography مفتاحا (سلسلة محارف) للتعمية وآخر لفكّها، على عكس طرق تعمية أخرى تستخدم نفس المفتاح للمهمتيْن. يهدف استخدام مفتاح خاصّ للتعميّة (المفتاح العموميّ) وآخر لفكّها (المفتاح الخصوصيّ) إلى تجاوز ضرورة تأمين نقل المفتاح الوحيد أثناء تبادل الرسائل المعمّاة. يتوفّر المفتاح العمومي لكلّ شخص للجميع دون استثناء بينما يقى المفتاح الخصوصي سرًّا خاصًّا به. مثلا، عندما يريد محمّد إرسال بريد معمّى إلى عمر فإنه يستخدم المفتاح العموميّ لعمر لتعمية البريد، عند وصول البريد إلى عمر فإنه يستخدم مفتاحه الخصوصي الذي لا يعرفه غيره لفك تعميّة الرسالة والاطّلاع عليها. بهذه الطريقة لن يعرف فحوى الرسالة غيرهما، محمّد لأنه كتب الأصل غير المعمَّى، وعمر لأنه الوحيد الذي يمكنه فك تعميتها. برنامج PGP يتبنّى برنامج PGP (اختصار لـ Pretty Good Privacy) مبدأ التعمية بالمفاتيح العمومية ويمكن استخدامه لتوقيع البيانات وتعميّتها: التوقيع للتأكد من المصدر والحؤول دون انتحال الشخصيّة، والتعمية للحفاظ على خصوصية البيانات. يجب الانتباه قبل استخدام البرنامج إلى التقييدات القانونية في استخدامه. يُحظَر في بعض الدوّل توجيه رسائل بتعميّة قويّة إلى خارج البلد. بروتوكول TLS يُستخدَم بروتوكول TLS (والإصدار السابق منه SSL) كثيرا لتأمين الاتصالات في شبكة حواسيب. يهدف البروتوكول إلى الحفاظ على خصوصية البيانات المنقولة عبر الاتصال بتعميتها، الاستيثاق من هويّات المتخاطبين باستخدام تعمية بالمفاتيح العمومية والتأكد من سلامة البيانات عن طريق جمع تحقق Checksum لكلّ حزمة بيانات. التنفيذ الأكثر شهرة على أنظمة لينكس لهذا المعيار هو مكتبة OpenSSL التي تدعم خوارزميات تعمية من بينها DES، Blowfish وIDEA. بروتوكول HTTPS وهو تطوير لبروتوكول HTTP بتضمينه داخل اتّصال يؤمّنه بروتوكول TLS (أو SSL). الأغراض الأساسية من استخدام HTTPS على مواقع الويب هي الاستيثاق، حماية الخصوصية والتحقق من سلامة البيانات المتبادلة. بروتوكول S/MIME يأتي الاسم اختصارا لـ Secure Multipurpose Internet Mail Extension (امتداد البريد الإلكتروني الآمن متعدّد الأغراض)، وهو معيار مفتوح يعتمد على التعميّة بالمفاتيح العمومية لتأمين البريد الإلكتروني وغيره من أنواع المراسلات على الشبكة. الشبكات الخاصة الافتراضية Virtual Private Network توجد تنفيذات عدّة لمعيار بروتوكول الإنترنت الآمن على لينكس. معيار IPSEC (اختصار لـ Internet Protocol Security؛ أمان بروتوكول الإنترنت) هو مجهود تقف خلفه قوة مهمات هندسة الإنتنرت IETF ويهدف إلى إنشاء اتصالات معمّاة على مستوى الشبكة (الطبقة الثالثة) وتوفير سبُل للتحقق من سلامة البيانات، التحكم في الوصول، الاستيثاق والسريّة. من الأمثلة على تطبيقات هذا البروتوكول في لينكس LibreSwan الذي يسمح للمستخدم ببناء نفق اتصالات آمن عبر شبكات غير موثوقة. يُعمَّى كل ما يمر إلى الشبكة غير الموثوقة قبل إرساله ليعمل الطرف الآخر عند استلامه على فك التعمية، تنتُج عن هذه العملية شبكة خاصّة افتراضية Virtual Private Network, VPN والتي هي شبكة اتصالات خاصّة على الرغم من أن الأجهزة فيها تتصل عن طريق شبكة غير موثوقة. لا تقتصر طُرُق إنشاء شبكات خاصة افتراضية في لينكس على IPSEC، بل توجد برامج خاصّة لهذا الغرض مثل OpenVPN التي تستخدم كثيرا مكتبات OpenSSL. بروتوكول SSH توجد عدّة حزم برمجية على لينكس لاستخدام SSH أبرزها OpenSSH. صُمِّم بروتوكول SSH ليحلّ مكان بروتوكولات الاتصال عن بعد غير الآمنة مثل rlogin، rsh وrexecالتي كانت ترسل البيانات دون احتياطات أمنية تُذكر. تعتمد حزمة برامج OpenSSH على التعمية بالمفاتيح العمومية لتعميّة الاتصالات بين مضيفين Hosts، وللاستيثاق من المستخدمين. كما يمكن استخدامها للولوج إلى خادوم بعيد أو لنسخ البيانات بين مضيفين مع الحماية من هجمات رجل في الوسط Man in the middle وهجمات أخرى. وحدات الاستيثاق سريعة التفعيل Pluggable Authentication Modules تأتي الإصدارات الحديثة من توزيعات لينكس محمّلة بآلية استيثاق موحدة تُسمّى Pluggable Authentication Modules, PAM تسمح للتطبيقات التي تعمل في فضاء المستخدم بتغيير متطلبات الاستيثاق الخاصّة بها وطريقته حسب الحاجة. يمكن باستخدام هذه الآلية من بين أمور أخرى: تحديد أمكنة وأوقات معيّنة لمستخدمين لا يمكنهم الولوج خارجها إلى النظام. تعيين سقف لاستخدام الموارد لكل مستخدِم. استعمال خوارزميات تعميّة أخرى غير DES لجعل فك التعمية بهجمات القوة العمياء أصعب. تفعيل كلمات السّر في ملف shadow حسب الحاجة. ملف Shadow لتأمين كلمات سر المستخدمين تستخدم الإصدارات الحديثة من توزيعات لينكس ملف etc/shadow/ لجعل كلمات سر المستخدم المعمّاة في مأمن من بقية المستخدمين على نفس النظام. كانت كلمات السر المعمّاة تخزّن في الإصدارات القديمة داخل ملف etc/passwd/ مبدئيا، ويمكن لجميع المستخدمين رؤيتها وبالتالي تنفيذ هجمات القوة العمياء عليها لمحاولة فك تعميتها. يعني اللجوء إلى ملف etc/shadow/ أن المستخدمين الإداريين فقط هم من يمكنهم رؤية كلمات السّر المعمّاة. التأكد من أمان كلمات مرور المستخدمين يحتاج مدير النظام أحيانا إلى التأكد من أن كلمات مرور المستخدمين جيّدة كفاية، لكي لا تكون بابا قد يؤدي فتحه إلى مشاكل أمنية أخرى، تُستخدم برامج مثل Jone the Ripper وCrack لهذا الغرض. تقوم فكرة هذه البرامج على توليد كلمات مرور معمّاة إما حسب نمط معرَّف مسبقا أو بالاعتماد على قاموس ألفاظ ثم مقارنتها بكلمات المرور المعمّاة الخاصّة بالمستخدمين، فإن وُجد تطابق عُرِفت كلمة السر. الجدير بالذكر أن مثل هذه البرامج تأخذ الكثير من الوقت وموارد الجهاز للعمل؛ وكلما كانت كلمات السّر معقدة كل ما كانت المهمة أصعب. في سيناريو هجمة حقيقية سيحتاج المخترق أولا إلى الحصول على ملف كلمات سر المستخدمين وهو أمر يحتاج لثغرات أمنية قد لا تكون موجودة؛ إلا أن الحيطة واجبة على الدوام. ترجمة - وبتصرّف - لمقال Encryption Methods in Linux لصاحبه M.el Khamlichi. حقوق الصورة البارزة: Designed by Freepik.
  24. سنتطرق في هذا الدّرس إلى كيفية تطبيق حماية أساسيّة لخادوم Redis. على الرغم من هذا، عليك تذكر بأن Redis قد صُمّم أساسا للاستخدام من طرف مستخدمين موثوقين على بيئة موثوقة، بدون أي مميزات أمنيّة خاصة به. لفهم هذه النّقطة أكثر إليك اقتباسا من الموقع الرسمي لـredis: بشكل عام، Redis ليس مُحسّنا لحماية قصوى بل لأداء عالي وبساطة فائقة. الأداء والبساطة بلا حماية بمثابة وصفة لكارثة. حتى مميّزات الحماية القليلة لدى Redis ليست ممتازة، وتشمل كلمة مرور بسيطة غير مُشفّرة، إعادة تسميّة الأوامر وتعطيلها. وتفتقر إلى نظام حقيقي للتحكم بالولوج. على الرغم من هذا، فإن ضبط هذه الخصائص الأمنيّة يبقى خطوة كبيرة إلى الأمام وأفضل من ترك قاعدة بياناتك بدون حماية. ستقرأ في هذا الدّرس كيفيّة ضبط الخصائص الأمنيّة القليلة التي يمتلكها Redis، وبعض الخصائص الأمنية الأخرى للنظام ما سيزيد من نسبة الحماية لخادوم Redis مُستقل على Ubuntu 14.04. ننوّه إلى أن هذا الدرس لا يتحدث عن حالات وجود كل من خادوم Redis وتطبيقات العملاء على استضافات مختلفة أو مراكز بيانات مختلفة. أو الحالات التي يجب على الاتصال بـ Redis أن يقطع شبكات غير آمنة أو غير موثوقة تتطلب نوعا مختلفا من الإعداد، مثل ضبط SSL proxy أو VPN بين خواديم Redis ، إضافة إلى الخطوات المذكورة هنا. المتطلبات ستحتاج في هذا الدّرس: خادوم Ubuntu مع مستخدم sudo مُضَاف، انظر درس الإعداد الابتدائي لخادوم أوبنتو 14.04 جدار ناري iptables معدّ باستخدام الدرس كيف تنفذ نموذجا للجدار الناري باستعمال Iptables إلى غاية خطوة "تحديث nameservers" (إذا لم تقم بإعداد جزء الخادوم nameserver فالـAPT لن يعمل). Redis مُثبت وقيد التنفيذ باستعمال الخطوات في الموضحة في الدرس كيفية تنصيب واستخدام Redis على أوبنتو. الخطوة الأولى، التأكد من أن Redis قيد التشغيل أولاً ادخل إلى الخادوم باستعمال SSH: ssh username@server-ip-address username: اسم المستخدم server-ip-address: عنوان IP الخاص بالخادوم للتأكد من أنّ Redis قيد التنفيذ، استعمل سطر الأوامر الخاص ب Redis .يُستعمل الأمر redis-cli للوصول إلى سطر أوامر Redis. redis-cli إذا سبق وأن أعددت كلمة مرور لـ Redis، فيجب عليك الاستيثاق بالأمر auth بعد الاتّصال: auth كلمة_المرور المخرج سيكون كلمة OK اختبر خادوم قاعدة البيانات: ping الرّد: PONG اُخرج: quit الخطوة الثانية، حماية الخادوم بـاستخدام Iptables إذا اتّبعت المُتطلّبات من أجل ضبط Iptables، فلك كامل الحريّة في تخطّي هذه الخطوة، أو يُمكنك القيام بذلك الآن. Redis مجرّد تطبيق يُنفّذ على خادومك، ولأنه لا يملك أي خصائص أمنيّة خاصة، فإنّ أول خطوة لحمايته حقيقة تكمن في حماية الخادوم الذي يُشغل منه. في حالة خادوم موجّه للعامة كخادومك Ubuntu 14.04، فإن ضبط جدار ناريّ كما هو مبيّن في درس Iptables يُعتبر الخطوة الأولى لذلك. اتّبع ذلك الرّابط واضبط جدارا ناريّا الآن. إذا طبّقت أحكام الجدار النّاري باستعمال ذلك الدّرس، فلن تحتاج لإضافة قاعدة أخرى لـ Redis، افتراضيّاً، إن أي مرور traffic يُمنَع إلّا عند السّماح له صراحةً. وبما أن خادوم Redis افتراضيّا يستمع على واجهة الاسترجاع (loopback (127.0.0.1 أو localhost، فلا يجب القلق حول المرور عبر المنفذ الافتراضي. إذا كنت تحتاج للسّماح لعنوان IP للوصول خصّيصا لـ Redis، يُمكنك التحقق من العنوان الذي يستمع منه Redis، وعلى أي منفذ باستخدام أمر grep لمُخرجات الأمر netstat. العمود الرّابع 127.0.0.1:6379 يطلعنا على عنوان IP والمنفذ المرتبطين بـ Redis: sudo netstat -plunt | grep -i redis المخرجات: tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 8562/redis-server 1 تأكّد من أن هذا العنوان مسموح له في الجدار النّاري. للمزيد من المعلومات عن كيفيّة إضافة الأحكام، اطّلع رجاء على درس أساسيّات Iptables. الخطوة الثالثة، الربط إلى المضيف المحلي localhost افتراضيًّا، يُمكن الوصول إلى خادوم Redis من المضيف المحليّ، على أي حال، إذا اتّبعت درس ضبط Redis على خادوم متبوع/سيّد فقد حدّثت ملفّ الإعدادات للسّماح للاتّصالات من أي مكان. وهذا ليس آمنا كالربط إلى المُضيف المحليّ. افتح ملفّ إعدادات Redis للتّعديل: sudo nano /etc/redis/redis.conf ابحث عن هذا السّطر وتأكّد من أنه ليس على شكل تعليق (احذف الرّمز # إذا كان موجودا): bind 127.0.0.1 سنستمرّ في استعمال هذا الملفّ، لذلك أبقه مفتوحا الآن. الخطوة الرابعة، ضبط كلمة مرور لـ Redis إذا ثبتت Redis باتّباع درس كيف تضبط خواديم Redis متعددة على أوبنتو 14.04 فيجب عليك أن تكون قد ضبطت كلمة مرور مُسبقا، يُمكنك أن تضع كلمة مرور أكثر أمانا باتّباع هذا القسم الآن، وهذه الخطوات تعرض كيفية وضع كلمة مرور لخادوم قاعدة البيانات. ضبط كلمة مرور لـ Redis يفعّل إحدى ميزتي الحماية المُضمّنة في Redis، وهو الأمر auth، الذي يطلُب من العملاء الاستيثاق للوصول إلى قاعدة البيانات. تُضبَطُ كلمة المرور مُباشرة في ملف الإعدادات etc/redis/redis.conf/ الذي يجب أن تكون قد فتحته منذ الخطوة الماضيّة. اذهب عن قسم SECURITY وابحث عن سطر مُعلّق بالرمز # كالتّالي: # requirepass foobared أزل التّعليق عن السّطر بحذف الرمز #، وغيّر foobared إلى كلمة مرور قويّة وطويلة. عوضاً عن الإتيان بكلمة مرور من عندك، يمكنك استعمال أداة مثل apg و pwgen لتوليد واحدة. إذا لم تكن ترغب بتثبيت أداة فقط لتوليد كلمة مرور، يُمكنك استخدام السطر التّالي. لتوليد كلمة مرور مُختلفة عن هذا المثال غير القيمة بداخل علامتي التنصيص: echo "hsoub-academy" | sha256sum المُخرج سيبدو كالتّالي: e118c2b8fa805fbd0a6af458ab7df9fea14881b87c2e793b4a2192cda30bf8d5 لكنّ كلمة المرور المولّدة لن تكون منطوقة، وهي قويّة وطويلة وهو تماما المطلوب لحماية Redis. بعد نسخ ولصق مُخرج هذا الأمر كقيمة جديدة لـ requirepass، يجب أن تكون كالتّالي: requirepass 960c3dac4fa81b4204779fd16ad7c954f95942876b9c4fb1a255667a9dbe389d إذا كنت تُفضّلُ كلمة مرور أقصر، استخدم مُخرج الأمر التالي عوضا عنها. غيّر القيمة بين علامتي التنصيص لكي لا تولّد نفس كلمة المرور: echo "hsoub-academy" | sha1sum المخرج سيكون أقصر هذه المرّة: 773a12cfe8616ff740258f8843c567f32227ac0f بعد ضبط كلمة المرور، احفظ الملفّ وأعد تشغيل Redis : sudo service redis-server restart لاختبار عمل كلمة المرور، حاول الوصول إلى سطر أوامر Redis : redis-cli السطر التالي يعرض سلسلة من الأوامر المُستعملة لاختبار ما إذا كانت كلمة المرور تعمل أو لا، الأمر الأول يُحاول إعطاء قيمة لمفتاح قبل القيام بالاستيثاق: set key1 10 الأمر لن يعمل، لذلك فإنك سترى خطأ في المخرجات: (error) NOAUTH Authentication required. الأمر الثاني يقوم بالاستيثاق بكلمة المرور التي وضعناها في ملفّ إعدادات Redis. auth your_redis_password سيُوافق Redis في الحال: OK بعد هذا، تنجح إعادة تنفيذ الأمر السّابق. set key1 10 المُخرج: OK الأمر get key1 يطلب من Redis قيمة المفتاح الجديد: get key1 المُخرج: “10” الأمر الأخير يقوم بإنهاء سطر الأوامر redis-cli. ويمكنك أيضاً استخدام exit: quit تالياّ، سننظر إلى إعادة تسميّة أوامر Redis. الخطوة الخامسة، إعادة تسمية الأوامر الخطرة الخاصيّة الأمنيّة الأخرى المبنيّة داخل Redis تُخوّل لك إعادة تسميّة أو تعطيل أوامر معيّنة والتّي تُعتبر أوامر خطيرة. عند تشغيل مستخدمين غير مُخولين لأوامر معينّة فقد تُستخدم هذه الأوامر لإعادة ضبط، أو تدمير أو حذف بياناتك. ومثل كلمة مرور الاستيثاق،فإن إعادة تسمية الأوامر أو تعطيلها تتم في نفس قسم SECURITY من الملفّ etc/redis/redis.conf/. بعض الأوامر المعروف أنها خطيرة هي: FLUSHDB, FLUSHALL, KEYS, PEXPIRE, DEL, CONFIG, SHUTDOWN, BGREWRITEAOF, BGSAVE, SAVE, SPOP, SREM, RENAME و DEBUG وهذه القائمة ليست شاملة، لكنّ إعادة تسميّتها أو تعطيلها كلّها يُعتبر نقطة بداية جيّدة. تعطيل أو إعادة تسميّة أمر يعتمد على مدى استعمالك للأمر، فمثلاً إذا كنت تعلم أنّك لن تستعمل أبدا أمرا يُمكن أن يُستَغلّ سلبيّاً، فمن المستحسن أن تُعطّله، عدا ذلك فمن الأفضل إعادة التّسميّة. لتشغيل أو تعطيل أمر ما، افتح ملفّ الإعدادات للتحرير مرة أخرى: sudo nano /etc/redis/redis.conf هذه بعض الأمثلة فقط. ويجب عليك أن تعيد تسميّة أو تعطّل الأوامر بما يُناسبك. يُمكنك التحقق من الأوامر بنفسك وتحديد إمكانيّة سوء استعملها على redis.io/commands. لتعطيل أو إيقاف أمر ما، فقط أعد تسميّتها إلى قيمة فارغة كما هو مبيّن أسفله: # It is also possible to completely kill a command by renaming it into # an empty string: # rename-command FLUSHDB "" rename-command FLUSHALL "" rename-command DEBUG "" وعند إعادة تسميّة أمر ما، عيّن اسما آخر كقيمة، كما في الأمثلة أسفله. الأوامر المعاد تسميّتها يجب أن تكون صعبة التخمين، وفي نفس الوقت سهلة التذكر بالنسبة لك.ولا تجعلها صعبة عليك. rename-command CONFIG "" rename-command SHUTDOWN SHUTDOWN_MENOT rename-command CONFIG ASC12_CONFIG بعد إعادة التّسميّة، طبّق التعديلات بإعادة تشغيل Redis: sudo service redis-server restart لاختبار الأمر الجديد، ادخل إلى سطر أوامر Redis: redis-cli بعد ذلك، على افتراض بأنّك قمت بإعادة تسميّة الأمر CONFIG إلى ASC12_CONFIG، المُخرج التّالي يوضح كيفيّة التأكد من أنّ الأمر الجديد يعمل. بعد الاستيثاق: auth your_redis_password المُخرج: OK يجب أن تكون مُحاولة استخدام الأمر config باسمه الأصلي فاشلة، لأنّنا بالطبع قمنا بإعادة تسميّتها: config get requirepass المُخرج": (error) ERR unknown command 'config' مناداة الأمر باسمه الجديد سيعمل (وهو غير حسّاس لحالة الأحرف): asc12_config get requirepass المُخرج: 1) "requirepass" 2) "your_redis_password" أخيرا، يمكنك الخروج من redis-cli: exit ملاحظة: إذا كنت تستخدم مسبقا سطر الأوامر Redis ثم أعدت تشغيل Redis، سيتوجب عليك إعادة الاستيثاق. إن لم تقوم بذلك، ستحصل على هذا الخطأ عند كتابة أمر ما: NOAUTH Authentication required. على الرغم من إعادة تسميّتك للأوامر، فهناك جملة تحذيريّة في آخر قسم SECURITY على ملفّ etc/redis/redis.conf/ تقول: هذا يعني أنّه إذا لم يكن الأمر المعاد تسميّته داخل ملفّ AOF، أو إذا كان موجودا لكنّ ملفّ AOF لم يُحَلْ إلى التّوابع، فلا يجب أن يكون هناك أي مُشكلة. لذلك تذكّر عند محاولة تغيير أسماء الأوامر، أفضل وقت لإعادة تسميّة أمر هو عند عدم استخدام AOF، أو مباشرة بعد التثبيت أي قبل نشر التطبيق المُستعمِل لـ Redis. عندما تستخدم AOF وعند التّعامل مع نظام تابع-متبوع، ضع في بالك هذه الإجابة من صفحة المسائل في المشروع على Github. الاقتباس التّالي هو جواب على سؤال الكاتب: لذلك فإن أفضل طريقة للتعامل مع إعادة التسمية في حالات كهذه هي أن تتأكّد من أنّ إعادة تسميّة الأوامر مطبّقة في جميع الخوادم في أنظمة تابع-متبوع. الخطوة السادسة، ضبط مجلد البيانات وصلاحيات المستخدم للملفات في هذه الخطوة، سوف نعرض بعض تعديلات المالك والصلاحيّات التّي يُمكنك القيّام لها لزيّادة حماية Redis. يتمثّل هذا في التأكد من أنّ المُستخدم الذي يحتاج إلى الوصول إلى Redis فقط يملك صلاحيّات قراءة البيانات. هذا المُستخدم افتراضيّا هو المُستخدم redis. يُمكنك التحقق من هذا باستخدام أداة grep مع الأمر ls لرؤية معلومات عن المُجلّد الأب لمجلّد بيانات Redis. الأمر والمُخرجات أسفله. ls -l /var/lib | grep redis المُخرج: drwxr-xr-x 2 redis redis 4096 Aug 6 09:32 redis يُمكنك ملاحظة بأن مجلّد بيانات Redis مملوك من طرف المُستخدم Redis، مع وصول ثانوي للمجموعة redis. وهذا أمر جيّد. الأمر السيئ هو صلاحيّات الوصول إلى المُجلّد، أي 755. للتأكد من أن المُستخدم redis هو فقط من يمتلك حقّ الوصول إلى المجلد ومُحتوياته، غيّر الصلاحية إلى 700: sudo chmod 700 /var/lib/redis الصلاحيّة الأخرى التّي عليك تغييرها هي الخاصّة بملفّ إعدادات Redis. يمتلك افتراضيّا صلاحيّة 644 ومملوك للمُستخدم الجذر root، مع مالك ثانوي يتمثّل في مجموعة الجذر root group: ls -l /etc/redis/redis.conf المُخرج: -rw-r--r-- 1 root root 30176 Jan 14 2014 /etc/redis/redis.conf هذه الصّلاحيّة (644) تعني مقروء من الكل، والتي تعتبر فكرة سيّئة لأن ذلك الملف يحتوي على كلمة المرور غير المُشفرة التّي وضعناها في الخطوة الرّابعة. نحتاج إلى تغيير المالك والصّلاحيّات. يجبُ أن تكون مملوكة للمُستخدم redis مع مجموعة الجذر كمالك ثانوي، لفعل ذلك، شغّل الأمر التّالي: sudo chown redis:root /etc/redis/redis.conf بعد ذلك غيّر المالك لكي يتمكّن مالك الملفّ فقط من قراءته أو/و الكتابة عليه: sudo chmod 600 /etc/redis/redis.conf يُمكنك التحقّق من المالك الجديد والصّلاحيّات باستخدام الأمر: ls -l /etc/redis/redis.conf المُخرج: total 40 -rw------- 1 redis root 29716 Sep 22 18:32 /etc/redis/redis.conf في الأخير، أعد تشغيل Redis: sudo service redis-server restart خاتمة تذكّر بأنه عند دخول أي شخص إلى خادومك، فمن السّهل التحايل على خصائص Redis الأمنيّة التي قمنا بضبطها. لذلك فإنّ أكثر خاصيّة أمنيّة هي التي تجعل من تجاوز هذا الحاجز صعبا قدر المُستطاع. أي خاصيّة الجدار النّاري. للتّقدّم بحماية خادومك إلى المستوى التّالي، فعليك ضبط نظام كشف تطفّل مثل OSSEC. إذا كنت تريد حماية تواصل Redis عبر شبكات غير آمنة فعليك توظيف SSL proxy، كما هو منصوح به من مطوّري Redis على دليل حمايةRedis الرسمي. وضبط SSL proxy لحماية تواصل Redis فهو موضوع آخر. لم نتطرّق إلى قائمة شاملة من أوامر Redis بقسم إعادة التّسميّة، لكنّك تستطيع إلقاء نظرة على مجموعة الأوامر بنفسك وتحديد إمكانيّة سوء استعملها على redis.io/commands. ترجمة -بتصرّف- للمقال How To Secure Your Redis Installation on Ubuntu 14.04 لصاحبه finid.
  25. استخدام الجدار الناري (firewall) يعتمد كثيرًا على السياسة (policy) التي ستتبعها في تصفية تدفّقات البيانات (data traffics) بنفس درجة اعتماده على تعلّمك للأوامر الأساسية وطريقة الاستخدام. بعض الجدران النارية مثل ـiptables تمتلك القدرة على فرض سياسات معيّنة يتم تحديدها من قبل مدير النظام، ولكن كواحدٍ من هؤلاء، يجب أن تعرف أفضل السياسات المناسبة لتطبيقها على البيئة الخاصّة بك. بينما تركّز دروسٌ أخرى على الأوامر اللازمة للحصول على جدار ناري فعّال، في هذا الدرس، سنناقش بعض الأمور التي يجب عليك فعلها عندما تقوم بتشغيل جدار ناري. ستؤثّر هذه الخيارات على الطريقة التي يتصرّف بها جدارك الناري، وعلى المدى الذي يجب إحكام إقفال خادومك إليه، بالإضافة إلى طريقة استجابته لمختلف الشروط التي قد تطرأ من حينٍ إلى آخر. سنستخدم iptables في درس اليوم، إلّا أنّ معظم ما سنتكلّم عنه سينطبق على أيّ أداة بغضّ النظر عن نوعها. اختيار السياسة الافتراضية عند بناء جدارٍ ناريّ فإن السياسة الافتراضية هي واحدة من الأشياء الأساسية التي يجب عليك التفكير فيها. تحدد السياسة الافتراضية ما يجب أن يحصل لتدفّقات البيانات في حال عدم مطابقتها لأيّ قاعدة (rule). يمكن افتراضيًا للجدار الناري أن يقبل أيّ تدفّق لا يطابق القواعد المعيّنة أو أن يرفضه. القبول افتراضيا مقابل الرفض افتراضيا سياسة "Accept" (قبول) الإفتراضية تعني أنّه سيتم السماح لأيّ تدفّق غير مطابق للقواعد المعيّنة مسبقًا بالمرور إلى الخادوم. لا ينصح باستخدام هذه السياسة افتراضيًا لأنّ هذا يعني أنّك ستقوم بعمل قائمة سوداء لمنع ما تريد منعه من الوصول إلى خادومك. القوائم السوداء صعبة الإدارة لأنّه يجب عليك متابعة وحظر جميع أنواع التدفّقات التي لا تريدها في خادومك. يمكن أن يؤدي هذا إلى الكثير من وجع الرأس بالإضافة إلى مشاكل تقنية في حال حصول غلطة بسيطة في القائمة السوداء مثلًا، لذلك هو أمرٌ غير مستحسن. الحلّ البديل هو "drop" (ترك) التدفّق افتراضيًا. هذا يعني أنّه لن يتم السماح لأيّ تدفّق لا يطابق القواعد المعيّنة مسبقًا بالوصول إلى الخادوم (أو الخروج منه)، وهو أمرٌ مشابه للقوائم البيضاء وقوائم تحكّم الوصول (Access Control List) حيث يجب السماح بشكلٍ استثنائي وخاصّ بأن يتم تشغيل وتنفيذ كلّ خدمة متوفّرة على حدى، والذي قد يحتاج الكثير من الوقت والجهد في البداية، ولكنّ هذا يعني أنّ السياسة الافتراضية الخاصّة بك ستكون أكثر أمانًا وستعرف بالضبط نوع تدفّق البيانات الداخل إلى خادومك. عليك الاختيار بين التوجّه نحو الخيار الأكثر أمانًا أو السماح للخدمات بالتحرّك بشكلٍ أكثر حرّية خارج الصندوق. صحيحٌ أنّ خيار استخدام سياسة "Accept" (قبول) افتراضيًا مع الجدار الناري قد يكون أفضل ما تفكّر به للوهلة الأولى، ولكن - في غالب الأحيان - من الأفضل في الواقع أن تستخدم سياسة "منع" افتراضيًا للجدار الناري. سياسة "drop" افتراضيا مقابل قاعدة "drop" نهائية الخيار السابق باستخدام سياسة "drop" (ترك) افتراضيًا يقود إلى قرارٍ مهم آخر. في iptables والجدران النارية المشابهة الأخرى، يمكن أن يتم تعيين السياسة الافتراضية باستخدام خصائص داخلية للجدار الناري، أو تضمينها عبر إضافة قاعدة "drop" (ترك) شاملة في نهاية قائمة قواعد الجدار الناري. الفرق بين هذين الطريقتين هو فيما سيحصل في حال تمّ مسح (flush) قواعد الجدار الناري. إذا كانت السياسة الافتراضية الداخلية في الجدار الناري الخاصّ بك معيّنة على "drop" (ترك) التدفّق وحصل يومًا ما وأن تمّ مسح قواعد الجدار الناري أو حذف بعضٍ منها عن طريق الخطأ مثلًا، فإنّ جميع الخدمات التي تشغّلها على الخادوم ستصبح غير قابلة للوصول. هذه غالبًا فكرة جيّدة عند ضبط الخدمات غير الحساسة على خادومك لكي لا يتم السماح للبرامج والأدوات الخبيثة بالمرور إذا اختفت القواعد فجأة. لكنّ الجانب المظلم في هذا التوجّه هو أنّ خدماتك ستصبح فورًا غير متوفّرة لمستخدميك إلى حين أن تقوم بإعادة تعيين قواعد الوصول مجددًا. يمكن أحيانًا أن تقوم بقفل الباب على نفسك وأنت في خارج الخادوم، الأمر سيّئ خاصّة إذا لم تكن تقدر على الوصول "فيزيائيا" إلى الخادوم أو وسيلةً أخرى للاتصال به (خواديم DigitalOcean قابلة للوصول دومًا بغضّ النظر عن إعدادات الشبكة عبر استخدام زرّ "Console Access" الموجود في قسم "Access" من لوحة التحكّم الخاصّة بالخادوم). إذا كنت أنت من يريد إعادة تعيين القواعد ومسحها بشكلٍ مقصود، فيمكنك ببساطة تجنّب هذه المشكلة عبر تغيير السياسة الافتراضية إلى "Accept" (قبول) مباشرةً قبل إعادة تعيين ومسح القواعد. الخيار البديل لما سبق هو تعيين السياسة الافتراضية الخاصّة بك إلى "Accept" (قبول) مع تضمين قاعدة "drop" (ترك) في النهاية مع القواعد الأخرى. يمكنك إضافة قاعدة عادية في نهاية قائمة القواعد الخاصّة بك تقوم بمطابقة ومنع كلّ التدفّق الباقي الغير مُطابق. في هذه الحالة، إذا تمّ إعادة تعيين قواعد الجدار الناري الخاصّة بك، فإنّ خدماتك ستكون قابلة الوصول ولكن غير محمية. اعتمادًا على خياراتك للوصول المحلّي أو البديل، يمكن أن يكون هذا شرًّا ضروريًا لكي تضمن أنّك قادر على الوصول إلى خادومك مجددًا في حال مُسحت قواعد الجدار الناري. إذا قررت استخدام هذا الخيار، فيجب أن تضمن أنّ قاعدة "drop" (ترك) التدفّق الغير مطابق هي دومًا آخر قاعدة في قائمة قواعد الجدار الناري. ترك التدفق مقابل رفضه هناك بضع طرق مختلفة لمنع حزمة بيانات (packet) من المرور إلى الوجهة التي تريدها. الاختيار المختلف لواحدٍ من هذه الطرق سيؤثر على الطريقة التي يقوم المستخدمون من خلالها بمحاولة الاتصال بالخادوم وسرعة إدراكهم أنّه لن يتم خدمة طلبهم الذي أرسلوه مسبقًا. الطريقة الأولى التي يمكن من خلالها منع حِزَم البيانات هي عبر "drop" (ترك) التدفّق. يمكن أن يتم استخدام الـ "ترك (drop)" كسياسة افتراضية أو ضمن قواعد الجدار الناري. عندما يتم ترك حزمة بيانات، يقوم iptables ببساطة برميها بعيدًا، حيث لا يقوم بإرسال أيّ رد إلى العميل الذي يحاول الاتصال ولا يقوم حتّى بإرجاع ردّ أنّه قد استلم الطلب بنجاح أم لا. هذا يعني أنّ العملاء لن يعرفوا ما إذا كان الخادوم قد وصله طلبهم أساسًا أم لا. لمحاولات الاتصال عبر بروتوكول TCP، سيتم الحفاظ على الاتصال إلى حين انقضاء مهلته (timeout). بما أنّ بروتوكول UDP هو بروتوكول غير اعتمادي على الاتصال (connectionless)، فإنّ عدم توفّر الردّ للعملاء يصبح أكثر إيهامًا. في الواقع، غالبًا ما يكون عدم تلقّي ردّ في هذه الحالة دليلًا على أنّ حزمة البيانات قد قُبلت. إذا كان عميل UDP يهتم بالجهة التي يرسل الحِزَم إليها، فسيقوم بإرسالها مجددًا لكي يتحقق مما إذا تمّ قبولها أو فقدانها أو رفضها. قد يزيد هذا من الوقت الذي يجب على البرمجيات والشفرات الخبيثة استغراقه للحصول على معلوماتٍ صحيحة عن حالة المنافذ في خادومك، لكنّه قد يسبب أيضًا مشكلة للتدفّق العادي. الخيار البديل هنا هو ببساطة رفض حزم البيانات التي لا تريدها بشكلٍ استثنائي. ICMP أو بروتوكول رسائل التحكّم بالإنترنت (Internet Control Message Protocol) هو عبارة عن بروتوكول وصفي (meta-protocol) يستعمل عبر الإنترنت لإرسال الحالة ومعلومات مواجهة الأعطال ورسائل الخطأ بين المضيفين (hosts) ضمن قناة لا تعتمد على اتصالات البروتوكولات التقليدية مثل TCP وUDP. عندما تقوم بـ "رفض" شيءٍ ما، فإنّ التدفّق سيتم منعه وسيتم إعادة حزمة ICMP إلى المُرسِل لإعلامه أنّ البيانات التي أرسلها قد تمّ استلامها إلّا أنّه قد تمّ رفضها. يمكن لرسالة الحالة أن تشير إلى السبب أيضًا. توجد العديد من العواقب لهذا، بافتراض أنّ تدفّق ICMP قادر على الرجوع إلى العميل، فإنّه سيتم إخطاره مباشرةً أنّ التدفّق الخاص به محظور. للعملاء العاديين، سيعني هذا أنّه يجب عليهم الاتصال بمدير الخادوم للاستفسار عن السبب أو التحقق من خيارات اتصالاتهم للتأكّد من أنّهم يتصلون عبر المنفذ الصحيح. أمّا بالنسبة للمستخدمين السيئين والذين يحاولون اختراق الخادوم، فإنّ هذا يعني أنّه يمكنهم إكمال عمليات بحثهم عن المنافذ المفتوحة والمغلقة والمُرشّحة في وقتٍ أقصر. هناك الكثير من الأمور التي يجب أخذها بعين الاعتبار عندما تقرر قبول أو رفض تدفّق البيانات. من بينها معرفة أنّ غالب تدفّق البيانات الخبيث الذي يتم إرساله بواسطة المخترقين يتم إرساله في الواقع عبر سكربتات وبرامج مؤتمتة، وبما أنّها ليست حساسة للوقت، فإنّ ترك التدفّق العادي لن يكون مفضلًا حيث أنّه سيؤثر على المستخدمين العاديين للخادوم. يمكنك قراءة المزيد عن هذا من هنا. جدول المقارنة بين ترك الطلب ورفضه يظهر الجدول أدناه كيفية حماية خادوم بواسطة جدارٍ ناريّ، حيث سيقوم بالاستجابة إلى طلباتٍ مختلفة بناءًا على السياسة التي يتم تطبيقها على منافذ معيّنة. يحدد العمود الأول نوع حزمة البيانات التي يتم إرسالها بواسطة العميل، بينما في الثاني، نقوم بذكر أمر nmap الذي سنستخدمه لاختبار كلّ سيناريو. يحدد العمود الثالث سياسة المنفذ المتبّعة على المنفذ، بينما الرابع يحدد الرد الذي سيتم إرجاعه إلى من طرف الخادوم. والخامس، هو ما يمكن للعميل أن يفهمه بناءًا على الرد الذي تلقاه. ترجمة -وبتصرّف- لـلمقال: How To Choose an Effective Firewall Policy to Secure your Servers لصاحبه Justin Ellingwood.