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

قد تتفاجأ ببعض المشاكل في عرض الصور بعد تثبيت شهادة SSL على مدونة ووردبريس. لا تقلق، ما عليك إلا أن تتابع قراءة هذا الموضوع لتتعرف على كيفية حل هذه المشكلة. عند تثبيت شهادة SSL على موقعك، يتغير عنوان موقعك بشكل طفيف، يسبب هذا التغيير حتى وإن كان بسيطا في الإضرار ببعض عناصر موقعك، الأمر الذي ينتج عن الاختلاف بين عنوان URL الذي تمت برمجة الموقع لاستخدامه وعنوان URL القديم الذي تستخدمه بعض عناصر المحتوى كالصور مثلا، أي أنه بعد تثبيت شهادة SSL يتم نقل كل المحتوى إلى عنوان https في حين لا تزال الصور تشير إلى عنوان http. يتجلى الحل إذن في ضرورة تغيير روابط كل الصور واستبدال http بـhttps ، ما يبدو أمرا شاقا للغاية. من حسن الحظ أنك لن تحتاج إلى تغيير روابط كل الصور التي سبق أن رفعتها واحدة تلو الأخرى. تبقى إمكانية التغيير اليدوي في قاعدة البيانات أمرا متاحا كما يمكنك اتباع الطريقة الأسهل والأكثر أمانا من خلال استخدام ملحق. إن واجهتك مشاكل في عمل الصور بعد تحديث موقعك باستخدام عنوان URL آمن جديد، تابع القراءة لتتعرف على كيفية القيام بالتغييرات الضرورية بشكل يدوي في قاعدة البيانات ولتطلع أيضا على الملحقات التي يمكن أن تستخدمها كحل بديل يتميز بالأمان وسرعة الاستخدام. البحث والاستبدال اليدويان باستخدام استعلامات قاعدة البيانات من الممكن القيام بتغيير روابط الصور بشكل يدوي في قاعدة البيانات. حتى نكون أكثر وضوحا: تجدر الإشارة إلى مدى سهولة ارتكابك للأخطاء أثناء القيام بذلك والإضرار بموقعك. سنتطرق لطريقة الاستبدال اليدوي لنشمل جميع الطُرق المُمكنة فقط رغم المخاطر التي ترافق القيام بالعملية. نظرًا لاحتمال ارتكابك لأخطاء أنصح باستعمال ملحق موثوق لتجنّب أيّة مشاكل قد تنتج عن التّعديل اليدوي. يعتبر عمل نسخة احتياطية (backup) لموقعك قبل القيام بأي تغيير كتعديل روابط الصور أمرا جيدا. يمكنك الإطلاع على المقال يفية نقل مواقع ووردبريس بسهولة باستخدام Snapshot في أكاديمية حسوب. بناء على ما سبق، إن وجدت نفسك في حالة نادرة تتطلب منك البحث في قاعدة البيانات لإيجاد روابط بعض الصور المعطلة، يمكنك القيام بذلك من خلال البحث في قاعدة البيانات بالطّريقة التّالية: سجل دخولك إلى phpMyAdmin، اضغط على قاعدة بيانات موقعك المدرجة في القائمة على اليسار ثم اضغط على تبويب Query. في استعلام SQL في خانة قاعدة البيانات أسفل الصفحة، أدخل الاستعلام التالي، ثم اضغط على GO: UPDATE wp_posts SET `post_content` = REPLACE (`post_content`, 'src="http://www.your-site.com', 'src="https://www.your-site.com'); تأكد من تحديث www.your-site.com إلى اسم نطاق موقعك الصحيح، ثم قم بتغيير البادئة النصية للجدول wp الخاصة ب wp_posts إذا لم تكن تستخدم البادئة الافتراضية وسبق لك أن قمت بتغييرها سابقا. إن كنت تستخدم نسخة ووردبريس متعددة المواقع ، تأكد من استخدام هذا الاستعلام لاحقا إن أردت أن تحدث الصور: UPDATE wp_2_posts SET `post_content` = REPLACE (`post_content`, 'src="http://www.your-site.com', 'src="https://www.your-site.com'); قم بتغيير 2 المتواجدة في wp_2_posts ليوافق رقم التعريف (ID) الصحيح لموقعك عند مطابقته مع مواقعك الفرعية، يجب عليك أن تستخدم هذا الاستعلام لكل المواقع في شبكتك. من المحتمل أن لا يكون ذلك ضروريا دائما، لكن إن كانت شبكتك معدة لاستخدام المجلدات الفرعية (sub-directories) ولم تكن مواقعك مجهزة لاستخدام نطاقات مختلفة قد تجد نفسك أمام ضرورة تغيير روابط صورك. يجب أن تستخدم الاستعلام أسفله لتحديث GUID الخاص بالصور المدرجة كمرفقات (attachments): UPDATE wp_posts SET `guid` = REPLACE (`guid`, 'http://www.your-site.com', 'https://www.your-site.com') WHERE post_type = 'attachment'; على غرار المثال الأول، يجب تغيير النطاق برابط URL الحالي وتغيير table prefix إن لم تكن تستخدم الإعداد الافتراضي. من المحتمل أن تحتاج استخدام هذا الاستعلام بالنسبة لكل المواقع على شبكتك: UPDATE wp_2_posts SET `guid` = REPLACE (`guid`, 'http://www.your-site.com', 'https://www.your-site.com') WHERE post_type = 'attachment'; لا تنس تغيير 2 المتواجدة في wp_2_posts برقم التعريف (ID number) الخاص بالمواقع في شبكتك. بعد القيام بما أسلفنا الذكر، من المفترض أن يتم تحديث كل الصور لتستخدم العنوان URL الجديد الذي (الذي يستخدم https)، إن لم ينجح الأمر في المرة الأولى كرر المحاولة فقد يكون ذلك مجديا. يساعد عدم استخدام كل الاستعلامات دفعة واحدة بل كل استعلام على حدة في نجاح هذه الطريقة. البحث عن روابط الصور واستبدالها باستخدام الملحقات يعتبر البحث عن روابط كل الصور واستبدالها باستخدام ملحق ما أكثر سهولة من القيام بذلك يدويا وأقل عرضة لارتكاب خطأ يؤدي إلى إيقاف موقعك. رغم ذلك، يبقى من المحتمل أن ترتكب خطأ ما، لذا يجب عليك أن تتأكد مرتين من كل ما تقوم بكتابته. يتم تحديث كل الملحقات التي سنتطرق لها بشكل تلقائي، لا تقلق فلن تستخدم ملحقا سرعان ما سيتجاوزه الزمن. في حين لا تتمتع كل هذه الملحقات بإمكانية العمل على المواقع المتعددة (Multisite) فإنها تفي بالغرض عند تفعيلها على كل موقع على حدة. بغض النظر عن أي هذه الخيارات ستقرر استخدامه نؤكد لك أنها كلها ذات جودة عالية كفيلة بإتمام العمل على أكمل وجه. Better Search Replace يتميز ملحق Better Search Replace على وجه الخصوص بتوفره على خاصية دعم المواقع المتعددة (Multisite)، فضلا عن بساطة تصميمه، يتوفر هذا الملحق على عدد محدود من الخصائص والإعدادات الضرورية التي لا يحتاج جُلُّ المستخدمين غيرَها. من أجل تثبيت هذا الملحق ببساطة، ما عليك إلا أن تتوفر على نسخة على ووردبريس منصبة، تعتبر إمكانية القيام بمعاينة تجريبية لترى أي الجداول تتأثر بالخيارات التي تحددها قبل تطبيقها فعليا من أفضل خاصيات Better Search Replace، تضمن لك هذه الخاصية احتماليةً أقل لاقتراف أي خطأ، ما يجعل منها أداة قَيِّمَةً للغاية. Search and Replace فضلا عن استبدال روابط الصور على موقعك، يمكن لملحق Search and Replace أن يقوم بالكثير من الأمور الأخرى، كتغيير عنوان URL ونطاق الموقع، عمل نسخة احتياطية لقاعدة بياناتك واستعادتها، إضافة إلى تغيير القيمة الافتراضية wp في table prefixes. يستطيع هذا الملحق القيام بمحاكاة للتغييرات التي تقترحها قبل تطبيقها فعليا، يكون ارتكاب الخطأ أقل احتمالا عند توافر إمكانية معاينة نتائج التغييرات دون القلق حول تطبيقها ثم إلغائها. يتطلب هذا الملحق استخدام نسخة 5.4 أو أحدث من PHP، يتم تثبيت Search and Replace بنفس سهولة أي ملحق آخر دون أي خطوات إضافية كما يتضمن أيضا دعم المواقع المتعددة (Multisite). WP Migrate DB يُستخدم WP Migrate DB عادة لتهجير (migration) المواقع، لكن يمكنك استخدامه أيضا للبحث عن الروابط القديمة لصورك وتغييرها، يتميز هذا الملحق بقدرته على تهجير موقع مطور محليا (locally developed) إلى استضافة مباشرة (live setup). يتميز هذا الملحق بسهولة الاستخدام فضلا عن عدم اشتراط أي متطلبات للتشغيل، رغم عدم أخذ الكثيرين لهذا الملحق بعين الاعتبار من أجل استبدال روابط الصور فإنه يبقى الخيار الأول للعديد من مستخدمي ووردبريس. خلاصة قد تسبب الصور بعض التعقيدات عند إضافة شهادة SSL إلى موقعك، حتى بعد تحديث عنوان URL الخاص بموقعك فإن الصور تبقى معطلة. يبقى الحل الوحيد هو قيامك بتحديث روابط الصور بنفسك ما يصبح عملية سهلة باستخدام أحد الملحقات المقدمة في هذا الموضوع. هل تمكنت من تغيير روابط صورك بنجاح؟ أي الملحقات استخدمت أو أيها تفضل؟ هل تفضل ملحقا آخر غير تلك التي أدرجنا في هذا الموضوع؟ تفضل بمشاركتنا تجربتك في التعليقات أسفله. ترجمة -وبتصرف- للمقال: Replacing Image Links in WordPress After Installing an SSL Certificate لكاتبته: JENNI MCKINNON.

أصبحت الفترة التي تزامنت مع ظهور الوسائل والطرق الجديدة التي يحاول المطورون استخدامها لإقناع الزائرين بالصور المتخصصة والمحتوى الديناميكي وإضافة الفيديو فترةً مهمة لتحميل صفحة الموقع ومصدر قلق دائم لمطوري الويب، خاصةً تلك الوسائط التي تحتاج وقت كبير في التحميل. وقد يظهر هذا القلق واضحًا عند إضافة أي محتوى جديد على اختلاف نوعه إلى صفحة الموقع، وهنا يتطلب من الموقع الخاص بك إنشاء طلبيات HTTPS (بروتوكول نقل النص التشعبي الآمن) إضافية تعمل بدورها على إبطاء موقعك بشكل تدريجي. سوف أتحدث في هذا المقال عن طلبيات خادم HTTPS، وعن ماهية الأدوات التي يجب استخدامها لتتبع هذه الطلبيات وأيضًا سوف أوضح الطرق التي يمكنك بها تقليص تلك الطلبيات داخل موقع ووردبريس الخاص بك. ما هي طلبيات خادم HTTPs وهل لها تأثير على تجربة المستخدم؟ بالطبع لا توجد هناك أهمية أكبر من أهمية تجربة المستخدم التي تعمل على جذب الزوار للموقع والاشتراك فيه أو شراء منتجاتك، أو التعرف على المزيد من المعلومات حول خدماتك. فهنا يظهر واضحًا جدًا أن أي خطأ بسيط يمكن أن يعرّض هذه التجربة للخطر فمثلًا لو كان لديك صفحة ويب تستغرق بضع ثوانٍ قليلة للتحميل، فهذا وحده كافٍ أن يعرّض معدل التحويل لديك للخطر. لذا ولتجنب ذلك، عليك التعرف على هذه المعلومات حول طلبيات خادم HTTPS ولماذا تحدث. ففي كل مرة يزور شخص ما موقع الويب الخاص بك أو إحدى صفحاته (وركّز هنا في عدد الصفحات الموجودة على موقعك)، إذ يقدّم متصفحه طلبًا إلى خادم موقع الويب الخاص بك وهذا يتكرر مع كل صفحة يقوم بزيارتها. وهنا تكمن مسؤولية موقع الويب الخاص بك في إرسال كل ملف بما يحتوي عليه (النصوص والصور التي عادة ما يشتمل عليها أغلب المواقع بالإضافة إلى الفيديو، وملفات CSS، وملفات جافاسكربت، …إلخ) ويتلقى كل ملف من تلك الملفات طلب خادم منفصل. وبعد أن تعالج جميع طلبيات الخادم وتنقل الملفات إلى المتصفح، يمكن تحميل موقع الويب الخاص بك على الشاشة، ولكن تخيل ماذا سوف يحدث إذا كان موقع Wordpress الخاص بك يحتوي على عشرات أو حتى مئات الملفات لإرسالها إلى متصفحات من يزوره؟ توقع فعليًا زمن تحميل الصفحات، بالطبع هذا شيء غير مستحب إن كان الزمن كبيرًا! وقد يزداد الأمر سوءًا بشكل كبير مع تزايد شعبية الموقع وتلقي طلبيات خادم HTTPS كثيرة في وقت واحد. مثال على ذلك: 40٪ من الناس لا يتحملون الانتظار وقد يفقدون صبرهم إذا كان عليهم الانتظار أكثر من ثلاث ثوان لتحميل الصفحة. و قد أشارت دراسة كيس ماتريكس إلى أن التأخير لمدة ثانية واحدة في استجابة الصفحة عندما يتفاعل الزائر معها قد يكلف ما يصل إلى 7٪ من التحويلات؛ لذا، تحتاج إلى العثور على طريقة لتقليص عدد الملفات التي يجب إرسالها إلى المتصفح إذا كنت تريد أن تظل أوقات التحميل هذه مقبولة. فمن غير المعقول أن يكون الحل هو تقليل عدد الصور أو المحتوى الديناميكي أو الانتقال إلى الحد الأدنى من التصميم الخاص بك بحيث تخسر بذلك ميزة العرض الخاصة بموقعك و يصبح الأمر مملًا للغاية. بالرغم من أهمية حجم وكمية الملفات، إلا أنه يتوفر هناك العديد من الطرق في ووردبريس للتغلب على ذلك. الأدوات الخاصة بتتبع طلبيات خادم HTTPS وما يتعلق به من حسن الحظ أن هناك عدد من الأدوات تساعدك في تخطي عقبة تخمين السبب وراء ظهور شاشة الموت البيضاء لدى زوار موقعك ومعرفة ما يسبب ذلك. وتعمل أيضًا على تتبع مصدر التأخر في أوقات تحميل موقعك. أعرض هنا إليك بعض الأدوات المجانية والموثوقة. أدوات التطوير في كروم إذا كنت تريد رؤية دقيقة ومتعمقة في المتصفح كروم للمدة التي يستغرقها كل عنصر وملف يعالج على موقع ووردبريس الخاص بك. ابدأ أولًا بفتح نافذة متصفح جوجل ثم انتقل إلى صفحة الإعدادات التي تسمى أدوات المطور (Developer Tools) كما يظهر في الصورة. ستفتح عند الضغط عليها لوحة تحكم جديدة على الجانب الأيمن من الشاشة. حينئذ اضغط فوق علامة التبويب Network "الشبكة"، ومن هنا ستتمكن من معرفة الإجراءات التي تحدث في صفحتك. وستتمكن أيضًا من البحث بحثًا دقيقًا في توقيت كل ملف على حدة للتأكد لمعرفة أيها قد يكون سببًا في زيادة الضغط (الحمل) على صفحتك. أداة PageSpeed Insights لتحليل الأداء والسرعة من غوغل هذه الأداة ليست الوحيدة بالطبع التي تقدمها جوجل لمساعدتك في اكتشاف المشكلات المتعلقة بطلبيات خادم HTTPS من الناحية المثالية، فإذا كنت من مستخدمي أدوات التطوير فمن الواجب عليك الاستفادة من الأداة PageSpeed Insights التي يجب أن تكون ضمن قائمتك. تحلل PageSpeed إحصاءات محتوى صفحة الويب ثم تقدم اقتراحات لتحسين سرعة تلك الصفحة. انتقل إلى صفحة PageSpeed Insights وضع رابط الصفحة التي تريد تحليلها وسوف تقدم لك نتائج تفصيلية تقيّم فيها أداء الصفحة على الجوال وكذلك على سطح المكتب. يقدم لك كل تقييم من هذه التقييمات درجة من 100 تبين مدى جودة الأداء ومن ثم يقدم لك نصائح حول كيفية تحسين موقعك لتحسين الأداء. أداة GTmetrix أداة GTmetrix هي أداة تقييم واختبار سرعة الموقع وستوفر لك درجة تقيِّم موقع الويب الخاص بك. وتتميز أداة GTmetrix أنها تتعامل في عملية شرح أداء موقعك بطريقة أكثر شمولًا وثقة من جوجل لذلك، بالرغم من ظهور العلامات الحمراء و الصفراء (وهي ليست جيدة)، إلا أنه يمكنك التمرير فوق كل نقطة من نقاط البيانات ومعرفة متوسط الدرجات وأوقات التحميل. وهذا سيعطي فكرة أكثر واقعية حول مستوى أداء صفحات موقعك. عند تقييمك من GTmatrix، تتلقى نصائح قياسية حول كيفية تحسين السرعة والأداء لصفحتك. كل تلميح يظهر بجانبه الدرجة المطابقة، وهذا يتيح لك معرفة المكان الذي أنجزت فيه الأمور بشكل جيد، وتعطي مقترحات للتحسين. وإذا كنت تريد المزيد من المساعدة في تلك المناطق الأضعف، فما عليك سوى النقر على السهم المتجه للأسفل وسيخبرك بالملفات التي يمكن أن تستخدم بعض الأعمال. أداة Pingdom الأداة Pingdom تتشابه إلى حد كبير مع أداة GTmetrix في عملها و كيفية تقديم المعلومات. وقد تجد أن الاختلاف الرئيسي بين الأداتين هو في السرعة التي توفر بها نتائجها وأيضًا الواجهة هذه أجمل قليلًا. و لكن من ناحية أخرى، ستتلقى نفس التقييم الدقيق تقريبًا من كلا الأداتين وهذا هو بالضبط ما تحتاجه إذا كنت تحاول توفير الوقت في تقييم مشاكل موقعك وتريد تضييق نطاق ما لا يعمل. الأداة WebPageTest لن يمر ذكر أدوات اختبار صفحات الويب دون ذكر الأداة WebPageTest هنا. مع أن الموقع قليل الشكوك والنتائج ليست سهلة القراءة مثل بعض الأدوات الأخرى، إلا أنني أحب الرسم البياني الشريطي المستخدم لعرض المدة التي يستغرقها كل ملف للتحميل. رغم أنه قد يكون هناك قدر هائل من البيانات في هذه الصفحة ولا توجد نصائح حول كيفية حل مشكلات التباطؤ المحددة، ما زلت أعتقد أن طريقة عرض العناصر الأثقل جيدة نوعًا ما. يمكنك دائمًا استخدام هذا بالاقتران مع أدوات المُطوِّر لتضييق نطاق العناصر ذات الإشكالية في موقعك. كيفية تقليل عدد طلبيات خادم HTTPS لموقع وورد الخاص بك وبعد أن تعرفت على كيفية تحديد المناطق المسببة لضعف أداء موقع الويب الخاص بك، دعنا نتحدث عن كيفية حل المشكلة كاملة من بدايتها وهي تقليل عدد طلبيات خادم HTTPS لموقع ووردبريس الخاص بك. أقدم إليك 9 خطوات يمكنك القيام بها وبذلك تحتفظ على عدد معقول من الطلبيات في موقعك. 1) حذف الصور غير الضرورية هذا ليس معناه أنه يتوجب عليك التضحية بالصور من أجل خفض طلبيات الخادم ولكن بدلًا من ذلك، أعتقد أنه يجب عليك التركيز والحفاظ على مكتبة الوسائط الخاصة بموقعك خالية من أي صور لا ضرورة لها أبدًا. لذا، إذا كانت هناك صور لا تستخدمها أو حتى لو كنت تفكر في استخدامها في المستقبل فيمكنك التخلص منها. في النهاية لن تضيف شيئًا لموقعك سوى إضافة وزن إضافي وطلبيات للخادم وموقعك ليس بحاجة إليها. 2) حذف الملفات الأخرى غير الضرورية وقد تُظهر لك أدوات تقييم سرعة صفحتك التي ذكرتها أن الصور ليست هي التي تسبب المشكلة، وتتفاجأ أن هناك إضافة لتغذية الوسائط الاجتماعية أو وجود فيديو مدمج في الصفحة. فأنصحك أنه إذا كان هناك أي شيء على موقعك ليس ضروريًا ويتسبب في الضغط، فقم بإلغائه. اشمل على ذلك الإضافات والقوالب التي قمت بتثبيتها، ولكن التي لا تستخدمها في الوقت الحالي. 3) ضغط وتقليص حجم الملف من الأشياء الأخرى التي يتوجب عليك فعلها هو تثبيت إضافة تدعى WP Smush التي تتولى عملية ضغط صور موقعك. فإذا كنت ترغب في الحفاظ على صور موقعك الجميلة وذات الدقة عالية على موقعك بجودة سليمة تحتاج إلى ضغطه. 4) إنشاء عفريت صور CSS باستخدام CSS، يمكنك إنشاء ما يعرف باسم عفاريت الصورة (Image Sprite وهي تقنية تقوم على مبدأ استعمال صورة واحدة تحتوي على مجموعة من الخلفيات واستعمالها في جميع أزرار الموقع ويرجع الهدف من استعمال هذه التقنية إلى تسريع تحميل الموقع والتقليل من استخدام موارد استضافة الموقع). فعليًا سوف يجمع ملف CSS هذا جميع ملفات الصور الخاصة بك ويضعها في ملف واحد. استعن بهذا الدليل من W3 Schools لإنشاء عفريت. 5) فعّل خاصية التحميل الكسول هل سمعت عن التحميل الكسول (lazy loading)؟ ربما تسمع به لأول مرة، وسأقرب لك فكرة عمله. هنالك إضافات خاصة ترسل طلبيات للخادم عندما يقوم المستخدم بالتمرير لأسفل إلى صورة على الصفحة، وهذا الإجراء يحفظ موقع الويب الخاص بك ويقلل من الاضطرار إلى إرسال طلبيات الخادم غير الضرورية إلى المتصفح التي لم يسبق لزوارك الوصول إليها من قبل. 6) تجاهل الأصول غير ذات الصلة عملية التجاهل هذه تقوم بها إضافة تسمى WP Asset Cleanup وهي خاصة بووردبريس وتعمل بشكل مشابه لكيفية عمل إضافات التحميل الكسول. فبدلًا من التركيز على تأخير طلبيات الخادم للصور التي لم تتم مشاهدتها، تستكشف هذه الإضافة ما إذا كان هناك إضافة أو ملف أو مادة عرض أخرى موجودة داخل القالب الخاص بك، ولكن ليس على تلك الصفحة المحددة وبعد ذلك تحفظ هذا الأصل من أن يتم تحميله والكشف عنه في تلك الصفحة. وبالتالي، يصبح هناك تقليل لعدد طلبيات الخادم التي تذهب إلى المتصفحات. 7) استخدام الإضافة Hummingbird استعمال إضافة التخزين المؤقت (caching) أمرًا ضروريًا لمواقع ووردبريس، وخصوصًا تكمن أهميته عندما يكون موقع ووردبريس الخاص بك يتعامل مع زوار دائمين للموقع. وبذلك ليست هناك حاجة فعلاً لمعالجة طلبيات الخادم نفسها إذا لم يتغير شيء، وبالتالي فإن إضافة التخزين المؤقت تعمل على ذلك وتزيل كل ما ليس له حاجة. ومن الإضافات المهمة في ووردبريس إضافة Hummingbird التي تؤدي دورها بشكل مثالي مع إدارة التخزين المؤقت للمتصفح، فهي تعتني أيضًا بضغط الملفات، وملفات CSS، وملفات JavaScript وتصغير ملفات html، كما يضيف CDN (أي اختصار شبكة توصيل المحتوى وهي عبارة عن مجموعة من الخوادم الموزعة بكل أنحاء العالم تعمل على إيصال المحتوى الثابت لمواقع الويب إلى المستخدمين حسب موقعهم الجغرافي بأقرب وقت وأقصر مسافة) وتعمل إضافة CDN على تسريع الأمور بشكل أكبر ومنح إمكانية الوصول إلى تقارير الأداء في حالة عدم رغبتك في استخدام أحد العناصر الثلاثة أعلاه لتقييم حالة سرعة موقعك. 8) دمج ملفات الجافا سكريبت و ال سي اس اس تحتوي مواقع ووردبريس على العديد من ملفات CSS وJavaScript فبدلًا من إرسال كل ملف كطلب خادم منفصل إلى متصفحات الزوار، يمكن دمجهم في ملف واحد منفرد لكل نوع. ضع باعتبارك أن ملف CSS المدمج الخاص بك يجب أن يكون داخل رأس موقع الويب الخاص بك، وملف جافاسكربت في التذييل. 9) الحد من الصور الخارجية يظهر هذا واضحًا وأكثر شيوعًا عند تعليقات المدونة. هل تعلم أنه إذا تركت نظام التعليق الافتراضي الخاص بووردبريس في مكانه فإنه سوف يستخدم تلقائيًا Gravatar (صورة تشخيصية ثابتة وهي عبارة عن خاصية أوتوماتيكية لسحب صور المعلقين وسيرهم) وبذلك تصبح هذه الصور طلبيات خادم إضافية يتعين عليك إرسالها إلى كل المتصفحات، فماذا لو كانت المدونة معروفة ومشهورة بالطبع سوف تصبح هناك فوضى. ولكن في ووردبريس يوجد هناك بعض الإضافات الخاصة بالتعليقات وتعمل على تجنب هذه المشكلة. الخلاصة أخيرًا مما يميز تطوير مواقع ووردبريس أن هناك الكثير من الأشياء التي تستطيع القيام بها داخل الموقع و تحسين أداءه، ولكن أحيانًا نغفل كيف يمكن لموقعنا الخاص بما يحتويه من قوالب وإضافات وصور رائعة تبرز جماله أنها قد تكون بشكل مفرط يفوق الحد في نظر المستعرض الذي يحاول ببساطة معالجة الموقع بالكامل. ومع ذلك، في وورد بريس عليك أن لا تخف أبدًا، فإذا استخدمت أداة مراقبة السرعة للصفحة وتابعت عليها دومًا وأيضًا التزمت بنصائح الحد من طلبيات الخادم التسعة التي ذكرتها في الأعلى، أعتقد أنك بذلك سوف تجعل أداء موقعك جيدًا. ترجمة -وبتصرف- للمقال How to Reduce HTTP/S Requests in WordPress لصاحبته Brenda Barron

كصاحب أي موقع جدّي، فإن أمن زوّارك أو مستخدمي موقعك يجب أن يكون من أولى أولوياتك، ولعلنا كمديري مواقع لطالما أردنا أيقونة القفل تلك (أحيانا تكون خضراء) بجانب عنوان (URL) الموقع، تُشير إلى أن موقعنا آمن ويستخدم اتصالا مشفرًا بين الزائر والخادوم. لحظة، ماهي شهادة SSL/TLS أولا؟SSL/TLS اختصارٌ لـِ Secure Socket Layer/Transport Layer Security وببساطة هو بروتوكول لتشفير نقل البيانات بين طرفين، في حالتنا هذه بين الخادوم والمستخدم (المتصفح)، ما يضيف ميزة الحماية على بروتوكول التصّفح HTTP، ومنه جاءت إضافة حرف S له فأصبح HTTPS. لماذا؟بدون هذا التشفير، يتم استعمال بروتوكول التصفح العادي HTTP، وهو بروتوكول ذو طبيعة نقل بيانات في شكلها النصّي البحت. أمّا مع HTTPS فسيقوم المتصفح بتشفير البيانات أوّلا قبل إرسالها، ثم يتم فكّ تشفيرها لمّا تصل إلى الخادوم، فإن التقط أحدهم هذه البيانات وسط الطريق، لن يكون بإمكانه قراءتها ﻷنها مشفّرة. تخيل أن لديك صفحة تسجيل دخول على موقعك (Login)، وموقعك لا يزال يستعمل HTTP، فإن حدث وأن كان أحد المتطفلين/المخترقين على نفس شبكة مُستخدمك (مثلا يتشارك معه نفس اتصال WiFi) والتقط هذا الأخير البيانات التي يرسلها مُستخدم موقعك، فسيعرف ماهو اسم المستخدم/بريده وكلمة مروره بكل سهولة ودون عناءٍ حتى. لا يقتصر هذا على المتطفلين فقط، فقد يكون مزود الخدمة لديك (ISP) ممن يسجّل تحركات زبائنه وبالتالي يمكنه أيضا كشف بيانات الدخول أيضا. هذه أمثلة فقط فالخطر لا يُمكن حصره، فالأجدر سدّ هذا الباب. بسبب هذا، نما في السنوات القليلة الماضية وعيٌ لدى مستخدمي الويب عموما، وجهات الويب المفتوح وحقوق المستخدم بضرورة تعميم استعمال بروتوكول HTTPS وتسهيل عملية تفعيله عوض تعقيدات التنصيب وتكلفة الشراء الباهضة. حيث قبل أيام قليلة فقط، كان الحصول على شهادة SSL/TLS أمرًا عسيرًا وقد يتطلب ميزانية مالية سنوية معتبرة زائدة على صاحب الموقع. فإما أن تشتري شهادة من طرف أحد الهيئات العالمية المعترف بها من طرف أغلب المتصفحات (مثل Comodo و Symantec)، أو تطلب شهادة شخصية مجانية واحدة فقط غير صالحة للاستخدام التجاري من عند StartSSL، أو تمر عبر خدمة Cloudflare التي تنصب نفسها وسطا بين خادوم موقعك وزوَاره حتى تنعم بـ SSL مجاني. مبادرة Let's encrypt من منطلق الوعي الحاصل بضرورة توفير شهادات SSL بطريقة سهلة، مجانية، مفتوحة وتلقائية، بادرت كل من Mozilla, Facebook, Cisco، منظمة لينكس وغيرها بإنشاء هيئة ذات سلطة توليد، تفعيل وإمضاء شهادات SSL، وقد نجحت في جعلها جهة مُعترفًا بها من طرف متصفحات الويب، وأطلقتها مؤخرا لعامة الناس كمرحلة Beta لكنها فعّالة ويمكن التعويل عليها من الآن فصاعدا. تحميل عميل أتمتة طلب شهادات Let's encrypt ملاحظة: حاليا، أداة العميل (client tool) تدعم فقط أنظمة يونكس، ولا يوجد دعم لخواديم Windows بعد. أولا، يجب طبعا الدخول على خادومك عبر ssh، إن كنت لا تعرف كيفية القيام بذلك، فأكاديمية حسوب تأخذ بيدك. تأكد أنك تملك صلاحيات root. ثانيا، عليك بتنصيب git، إن كنت على Ubuntu أو Debian مثلا فقم بالأمر التالي: sudo apt-get install gitأما على Fedora/Centos: sudo yum install gitوإن كنت على Arch Linux يكفي كتابة الأمر: sudo pacman -S gitثالثا: حمّل عميل Let's encrypt على خادومك عبر كتابة هذه الأوامر: git clone https://github.com/letsencrypt/letsencrypt طلب وتنصيب الشهادة لخادوم nginxملاحظة 1: عليك توقيف خادوم nginx للحظات لغاية انتهاء التنصيب، العميل لا يدعم توقيف وإعادة تشعيل nginx بشكل تلقائي بعد، لذلك يجب القيام بهذا يدويا. يمكنك توقيف خادوم nginx بكتابة الأمر التالي على Debian ومشتقالتها: sudo service nginx stopأو عبر: sudo systemctl stop nginxللأنظمة التي تعتمد على systemd. إن كنت تجهل كيفية التعامل مع خادوم nginx فإليك قسما كاملا على أكاديمية حسوب يهتم بهذا الجانب، وأنصحك أن تبدأ بهذا الدرس، عليك أن تألف إعادات nginx وكيفية عملها قبل المواصلة مع هذا الدرس. ملاحظة 2: أي إعداد خاطئ في هذه المرحلة قد يسبب توقف موقعك لمدة مُعتبرة، يجدر بك أولا معرفة مبادئ التعامل مع nginx. أولا يجب الدخول إلى حيث قمنا بتحميل عميل let's encrypt: cd letsencryptثم طلب الشهادة بهذ الطريقة: sudo ./letsencrypt-auto certonly --standalone -d example.com -d www.example.com الأمر أعلاه يقوم بالتالي: sudo ./letsencrypt-auto: تشغيل عميل طلب الشهادة بصلاحيات root.certonly: أي أننا نطلب فقط الشهادة لوحدها دون التنصيب التلقائي لها على nginx أو ما شابه (كون هذه الخاصية لا تزال تجريبية ولا يمكن التعويل عليها).standalone--: أي استعمل خادوم ويب خاص يتم تشغيله للاستماع على كل من منفذي 80 و 433 لتوثيق الشهادة من طرف سلطة let's encrypt (ضروري، ولهذا وجب توقيف nginx أولا).d-: اختصارًا لـ domain أي النطاق أو النطاقات الفرعية التي ستكون هذه الشهادة صالحة لها.ملاحظة: لا يمكن حاليا تمرير example.com.* مثلا إلى تعليمة d- حيث لم يتم بعد دعم wildcard domain، أي النطاقات التعميمية، لكن من السهل إضافة دعم أي نطاق فرعي آخر عبر إضافته إلى تعليمة d-. ستجلب الأداة بعض الاعتماديات اللازمة وتنصبها على النظام ثم تُظهِر لك الرسالة التالية: أدخل عنوان بريدك الالكتروني صحيحًا، ﻷنه سيكون مهما لاستعادة المفاتيح الضائعة أولإشعارك بأمور مهمة خاصة بشهادتك (كقرب موعد انتهاء صلاحيتها). ثم اضغط على مفتاح Enter. ستظهر بعدها إتفاقية الاستحدام -كما هو ظاهر أدناه- قم بقراءتها ثم الموافقة عليها: سيباشر بعدها العميل بطلب الشهادة وتوثيقها، لتظهر أخيرًا الرسالة التالية: IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at /etc/letsencrypt/live/example.com/fullchain.pem. Your cert will expire on 2016-03-04. To obtain a new version of the certificate in the future, simply run Let's Encrypt again. - If like Let's Encrypt, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le كما هو موضّح في الرسالة، فقد تم تنصيب الشهادة في مسار /etc/letsencrypt/live/example.com/ حيث example.com هو اسم نطاق موقعك. يمكن تنصيب الشهادة على خادوم nginx بسهولة عبر تحرير الملف الخاص بموقعك وإضافة بضعة سطور، كالتالي: sudo nano /etc/nginx/sites-available/www.example.comحيث www.example.com هو اسم ملف، ويجب تغييره باسم ملف إعدادات موقعك مع nginx. ثم إضافة الأسطر التالية في كتلة server ضمن ملف الإعدادات: http { server { listen 443 ssl; server_name www.example.com; ssl_certificate /etc/letsencrypt/live/www.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem; ... // باقي الإعدادات تجاهلها } }قم بإعادة تشغيل خادوم nginx عبر الأمر التالي: sudo service nginx startإن كنت على أحد الأنظمة التي تستعمل systemd فقد يكون عليك إعادة تشغيل nginx بالأمر التالي: sudo systemctl start nginxتهانينا لك شهادة SSL مجانية صالحة لمدة 90 يوم، يمكنك طبعا تجديدها بتشغيل نفس الأمر، كما يمكنك أتمتة عملية التجديد عبر برمجتها كمهمة cron job عبر crontab (كل شهر مثلا لتفادي أي مشكل). تنصيب الشهادة على خادوم apacheيمكن طلب الشهادة بنفس الطريقة ثم فقط تنصيبها يدويا على خادوم Apache كما فعلنا مع nginx، يمكنك اتباع الدرس التالي من على أكاديمية حسوب لمعرفة كيفية القيام بذلك، أما إن كنت على أحد أنظمة Debian أو مشتقاتها (مثل Ubuntu) فيمكنك أتمتة العملية بأكملها (دون الحاجة لتوقيف الخادوم) عبر تشغيل الأمر التالي: sudo ./letsencrypt-auto --apacheسيتم سؤالك طبعا عن أسماء النطاقات، بريدك الالكتروني وشروط الخدمة. أجب عليها واترك الأداة تعمل لغاية ظهور رسالة التهنئة. ملاحظة: في حين احتاج nginx لملفي fullchain.pem و privkey.pem فإن Apache يحتاج لملفي: chain.pem لتعلمية SSLCertificateChainFile.وprivkey.pem لتعليمة SSLCertificateKeyFile.بهذا نكون قد تحصلنا على شهادتنا، يمكن إلقاء نظرة على التوثيق الرسمي لتخصيص الأداة وزيادة نسبة الأتمتة وكيفية التجديد التلقائي. على أمل أن نجعل الويب النّاطق بالعربية أكثر أمنا وخصوصية!

نحن نرسل معلوماتنا الشخصية في كل يوم عبر الإنترنت، ففي الساعة الماضية دفعتُ المستحقات على بطاقتي الائتمانية، واشتريتُ كتابًا، وحفظتُ نسخةً من عناوين منازل أصدقائي، وأرسلتُ بعض رسائل البريد الإلكتروني، واشتريتُ بعض الحاجيات. أصبحتْ مشاركة معلوماتنا شائعة جدًا في هذه الفترة، حتى أننا لم نعد نفكر قبل مشاركتها. هذا هو الغرض من SSL، فشهادات SSL تحمي التفاصيل التي نشاركها على الإنترنت، مانعةً وقوعها في الأيدي الخاطئة. استخدام SSL –وبالتالي HTTPS– لحماية موقع ووردبريس الخاص بك وزواره لن يكون أمرًا صعبًا ومعقدًا، وسنناقش في هذا الدرس ما هو SSL وكيف نستخدمه. ما هو SSL؟ «طبقة المقابس الآمنة» (Secure Socket Layer اختصارًا SSL) بدأت كطريقة لزيادة الحماية بين المواقع الإلكترونية وزوارها في 1994 من شركة Netscape Communications حيث وجدوا أنَّ الحاجة لمثل هذه التقنية في تزايد. تم تحسين SSL لاحقًا وأُصدِرَ لأول مرة بنسخة 3.0 في عام 1996، لكنه كان يحتوي على ثغرات. ومن ثم استحوذت «Internet Engineering Task Force» (اختصارًا IETF) عليه رسميًا في 1999 وطوِّرَ كثيرًا منذ ذاك الحين. وفي الوقت الراهن، أعيدت تسمية SSL إلى TLS ‏(Transport Layer Security أي حماية طبقة النقل)، لكن ما يزال يشار إليه باسم SSL أو TLS/SSL. وما يزال الغرض منه هو ذاته إلى يومنا هذا، وأصبحت هذه التقنية معياريةً لحماية مواقع الويب. متى يجب أن تستعمل SSL؟ أعلنت شركة Google منذ مدة أنَّها ستزيد من تقييم المواقع التي تستعمل SSL في نتائج بحثها، لكن ربما تجد زيادةً مقدارها 1% في هذه الفترة، لإعطاء الجميع فرصةً للانتقال إلى استخدام SSL. وبغض النظر عمّا سبق: إذا كان يطلب موقعك من المستخدمين تسجيل دخولهم أو إعطاء معلوماتهم الشخصية مثل أسمائهم وعناوين بريدهم الإلكتروني وتفاصيل بطاقتهم الائتمانية وهلم جرًا… فيجب أن توفِّر حمايةً عبر SSL. فبدونها قد تُعرِّض معلومات المستخدمين للخطر. كيف يعمل SSL؟ يعمل SSL عبر تشفير المعلومات المُمرَّرة بين الخادوم الذي يُستضاف عليه الموقع إلى المتصفح بدلًا من ترك المعلومات بصيغتها النصية، مما يعني أنَّ النص سيُعاد صياغته بطريقةٍ تجعله يبدو وكأنه سلسلة من الحروف غير المفهومة والأرقام، بدلًا من بقائه بصيغته المفهومة. لإنشاء اتصال SSL آمن على موقع ويب، فيجب أن يحصل صاحب الموقع على شهادة SSL (أي SSL certificate) من إحدى الشركات المتخصصة والتي تُسمى «سلطة الشهادات» (Certificate Authority). وبعد دفع المبلغ، فيجب إرسال معلومات الموقع الإلكتروني إلى سلطة الشهادات مثل الاسم والعنوان ورقم الهاتف. توضح هذه الصورة بعض المعلومات اللازمة لتسجيل شهادة SSL أساسية، هنالك معلوماتٌ أخرى تتطلبها الشهادات الأكثر أمانًا: وبالمقابل، سيحصل مالك الموقع على مفتاح عمومي (public key) ومفتاح خاص (private key). لا يجب مشاركة المفتاح الخاص مع أي شخص (مَثَلُهُ كمَثل كلمة المرور) لكن المفتاح العمومي ليس مهمًا أن يبقى مخفيًا. تلك المفاتيح هي أحرف وأرقام متناسقة مع بعضها رياضيًا، وهي تشبه المفتاح والقفل. وتُنشَأ عبر خوارزمية باسم Secure Hash Algorithm. يُرسَل المفتاح العمومي مع البيانات التي أدخلتها مسبقًا في ملفٍ باسم «Certificate Signing Request» (أي طلب توقيع الشهادة). ستتحقق سلطة الشهادات من المعلومات التي أدخلتَها وتتأكد أنها دقيقة (وأنَّك لستَ مُخترِقًا) وإذا جرى كل شيءٍ على ما يرام، فستوقَّع الشهادة عبر خوارزمية SHA. بعد ذلك ستصدر شهادة SSL، وهذه هي المرحلة التي يمكن للموقع فيها استخدام اتصالات مشفرة عبر SSL. وعندما يزور المستخدم موقعًا محميًا، فسيتأكد الخادوم أنَّ شهادة SSL تتطابق مع المفتاح الخاص، ومن ثم سينُشَأ «نفق مشفَّر» بين الخادوم (أو الموقع) والمتصفح (أو المستخدم). كيف تبدو المواقع المحمية بشهادات SSL؟ السابقة https ستظهر قبل رابط URL بدلًا من البروتوكول الافتراضي http. يمكنك أن تلاحظ قفلًا لونه أخضر معروضٌ في حقل العنوان في متصفحك. إذا اختار القائمون على الموقع شراء شهادة موسعة (تسمى «Extended Validation Certificate») فسيصبح شريط العنوان أخضر اللون بأكمله، أو سيحتوي على اسم الشركة باللون الأخضر قبل عنوان URL. أما في متصفح Safari فلن يصبح شريط العنوان أخضر اللون، ولن يكون لاسم الشركة خلفيةٌ خضراء، وإنما سيُستعمَل اللون الأخضر لكتابة اسم الشركة: عادةً، توفِّر الشهادات الموسعة حمايةً أكثر، وتُصدَر بعد أن تجتاز الشركة تحققات أكثر من سلطة الشهادات. وسيُطلَب من القائمين عليها توفير دليل على العنوان الفيزيائي وغير ذلك من الأمور القانونية، إضافةً إلى المعلومات الأساسية التي ذكرناها آنفًا. متى تتوقف شهادة SSL عن العمل إذا انتهت صلاحية شهادة SSL أو كانت موقعةً ذاتيًا (self-signed) أو كانت غير صالحة، فسيتحول لون كلمة https إلى الأحمر وأحيانًا يوضع خط فوقها، وأغلبية المتصفحات تحذِّرك إذا كان الموقع يستخدم شهادة SSL متوقفة، وتطلب تأكيدك قبل الدخول إلى الموقع غير الموثوق: عندما تنتهي صلاحية الشهادة، فيجب على مالك الموقع أن يُجدِّد شهادة SSL ببساطة، وذلك عبر سلطة الشهادات؛ لكن من الأفضل عدم الانتظار حتى انتهاء الشهادة لتجديدها، لكي يكون موقعك محميًا دومًا. أو سينبِّهك المتصفح إذا كنتَ تستخدم شهادة موقعة ذاتيًا وذلك إذا أصدرتَ شهادة SSL خاصة بك ولم تذهب إلى سلطة شهادات لتحقق من صحة المعلومات التي أدخلتها. أغلبية المتصفحات تثق بشهادات SSL المُصدَرَة من سلطة شهادات موثوقة، وستعرض تحذيرًا لجميع المواقع التي تستخدم شهادات موقعة ذاتيًا. إذا اشتريتَ شهادة SSL من شركة ليس ذات مستوى مرموق، فقد يُعتَبَر أنَّ موقعك يستخدم شهادة موقعة ذاتيًا. قد تصبح شهادة SSL غير صالحة لعدد من الأسباب، أحدها هو استخدام خوارزمية SHA قديمة. عملية التجزئة (hashing) هي عملية تحويل كمية كبيرة من المعلومات النصية إلى كمية أصغر يُشار إليها بالمفتاح (key) ويتم تحويلها عبر تطبيق مجموعة من القواعد الرياضية. وهنالك حاجةٌ إلى عملية تجزئة أقوى مع تقدم التقنية. لم تعد خوارزمية SHA0 مستخدمةً، وخفَّ استخدام خوارزمية SHA1 كثيرًا في الآونة الأخيرة، وأصبح متصفح Chrome يُظهِر تحذيرات بدءًا من عام 2016 للمواقع التي تستخدم خوارزمية SHA1. المعيار الحالي للتشفير هو خوارزمية SHA2 وأتوقع أن تحل محلها خوارزمية SHA3. قد يبدو لك أنَّ شهادة SSL غير صالحة إذا لم يتمكن المتصفح من التحقق منها من سلطة الشهادات. وهذا يحدث إذا كان اسم النطاق المستعمل في الشهادة يختلف عن اسم نطاق الموقع الذي يستخدمها. أفضل طريقة لحل هذه المشاكل هي تحديث شهادة SSL بالتنسيق مع سلطة الشهادات وباتباع تعليماتهم. إذا ظهر قفلٌ أمامه مثلثٌ أصفرٌ صغير، فمن المرجَّح أنَّ السبب هو أنَّ موقعك يحتوي على روابط لصفحات غير آمنة، تأكَّد أنَّ جميع صورك وعناصر القائمة وجميع الروابط في موقعك تستعمل بروتوكول https. من السهل معرفة السبب وراء عدم صلاحية الشهادة عبر استخدام أداة مجانية باسم Why No Padlock حيث تُعلِمُك مباشرةً بالمشكلة بما في ذلك استعمال الصور والسكربتات لبروتوكول http بدلًا من https. استخدام شهادة SSL مع ووردبريس بعد أن تملك شهادة SSL فيمكنك الآن استخدامها مع موقعك الذي يعتمد على ووردبريس. لا تنسَ أن تأخذ نسخةً احتياطيةً من كامل الموقع قبل إجراء أيّة تغييرات لمنع فقدان بياناتك في حال حدث شيءٌ غيرُ متوقعٍ. يمكنك الإكمال بعد أخذ النسخة الاحتياطية. لضبط شهادة SSL على موقع ووردبريس مستقل أو على شبكة متعددة المواقع، فافتح ملف wp-config.php وأضف السطر الآتي من الشيفرة. حيث سيُجبِر صفحات تسجيل الدخول ولوحة التحكم على استعمال تشفير SSL: define('FORCE_SSL_ADMIN', true); احرص على أن تضع السطر السابق قبل التعليق الآتي: /* That's all, stop editing! Happy blogging. */ سنضبط الآن إعادة توجيه (301) لكي يعاد توجيه كل زوار موقعك إلى النسخة الآمنة من الموقع التي تستعمل https بدلًا من http. عدِّل ملف ‎.htaccess أو أنشِئ واحدًا إن لم يكن موجودًا من قبل. إذا كان موجودًا فعليك وضع الشيفرة الآتية في أول الملف قبل أي شيءٍ آخر. لا تنسَ وضع اسم نطاقك بدلًا من mysite.com واحرص على إدخال المنفذ الصحيح إذا لم يستعمل موقعك المنفذ 80. <IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{SERVER_PORT} 80 RewriteRule ^(.*)$ https://www.mysite.com/$1 [R,L] </IfModule> افتح موقعك الآن لتجرِّبه. فإذا ظهرت الكلمة https في عنوان URL مع القفل الأخضر فهذا يعني أنَّ موقعك أصبح يستعمل شهادة SSL. الخلاصة الحصول على شهادة SSL لموقعك هي خطوةٌ مهمةٌ في طريق حمايته وحماية زواره، لكنها ليست الخطوة الوحيدة التي عليها فعلها، يمكنك الاطلاع على هذا الدرس. إذا أردتَ معلوماتٍ أكثر عن استخدام SSL مع ووردبريس لاحتياجاتك الخاصة، فانظر إلى صفحة Administration Over SSL في توثيق ووردبريس. هل أنت مهتم بالحصول على شهادة SSL مجانية؟ أعلنت EFF ‏(Electronic Frontier Foundation) في عام 2014 أنها تعمل على مشروع مفتوح المصدر لإنشاء شهادات SSL مجانًا، وأُطلِق هذا المشروع لاحقًا باسم Let’s Encrypt. هنالك إضافاتُ تساعدك في ضبط شهادة SSL في موقعك، لكن انتبه فقد لا تكون تلك الإضافات مُحدَّثةً وقد لا تتوافق مع آخر نسخة من ووردبريس. قد تحسب أنَّه لا بأس باستعمال إضافات قديمة إذا كان يستعملها الكثيرون وقد اختبرتَها في موقعٍ تجريبي دون مشاكل، لكن حماية موقعك ليست شيئًا يُستهان به. ترجمة –وبتصرّف– للمقال How to Use SSL and HTTPS with WordPressلصاحبته Jenni McKinnon

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

تتوفّر على توزيعات لينكس برامج تحظُر إنشاء كلمات سر يسهُل تخمينها؛ فالوصول إلى الكثير من بيانات المستخدم وبرامجه يتطلّب تجاوز مرحلة إدخال كلمة السرّ ، الأمر الذي يجعل من كلمات السر نقطة حرجة في سبيل تأمين النظام والمستخدم على حدّ السواء ويجب بالتالي الحرص دائما على أن تكون محدَّثة. توجد الكثير من طرق تعمية البيانات ولكلّ منها خصوصيّاته. تستخدم أغلب توزيعات لينكس خوارزميّة تعمية تُسمّى معيار تعميّة البيانات 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.

واحدة من أكثر الأشكال الشائعة للتشفير في وقتنا الراهن هي التشفير وفق المفتاح العمومي (public-key cryptography)؛ يستخدم التشفير وفق المفتاح العمومي مفتاحًا عامًا (public key) ومفتاحًا خاصًا (private key)؛ يعمل النظام بتشفير (encrypt) المعلومات باستخدام مفتاح عمومي، ولا يمكن أن يُفَكّ تشفيرها (decrypted) إلا باستخدام المفتاح الخاص. استخدام شائع للتشفير وفق المفتاح العمومي هو تشفير البيانات المنقولة باستخدام اتصال SSL ‏(Secure Socket Layer) أو TLS‏ (Transport Layer Security)؛ على سبيل المثال، إن ضبط أباتشي لتوفير HTTPS -بروتوكول HTTP عبر SSL- يسمح بتشفير البيانات في بروتوكول لا يوفر بحد ذاته آليةً للتشفير. الشهادة (Certificate) هي طريقة تستخدم لتوزيع المفتاح العمومي وغيره من المعلومات عن الخادوم والمنظمة المسؤولة عنه؛ تُوقَّع الشهادات إلكترونيًا بواسطة «سلطة الشهادات» (CA)، إن سلطة الشهادات هي طرفٌ ثالثٌ موثوق تأكد من دقة المعلومات الموجودة في الشهادة. أنواع الشهاداتلضبط خادوم آمن باستخدام تشفير وفق المفتاح العمومي، عليك إرسال -في أغلب الحالات- طلب الشهادة (متضمنًا المفتاح العمومي الخاص بك) ودليلًا على هوية شركتك ودفعةً ماليةً إلى سلطة شهادات؛ ثم ستتحقق سلطة الشهادات من طلب الشهادة ومن هويتك، ثم ستُرسِل الشهادة إلى خادومك الآمن. بشكلٍ بديل، تستطيع إنشاء شهادتك الموقعة ذاتيًا. للحصول على شهادة SSL قم باتباع الخطوات الموضحة في درس كيفية تثبيت شهادة SSL من سلطة شهادات تجارية أو يمكنك الحصول على شهادة SSL مجانية عبر خدمة Let's encrypt. ملاحظة: لاحظ أنه لا يجدر بك استخدام الشهادات الموقعة ذاتيًا في أغلبية بيئات العمل الإنتاجية. بإكمال مثال HTTPS، ستوفر شهادة موقعة من سلطة الشهادات إمكانيتَين مهمتين لا تملكهما الشهادات الموقعة ذاتيًا: المتصفحات تتعرف (عادةً) تلقائيًا على الشهادة وتسمح بإنشاء اتصال آمن دون طلب موافقة المستخدم.عندما تعطي سلطة الشهادات شهادةً موقعة، فإنها تضمن هوية المنظمة التي توفر صفحات الويب إلى المتصفح.أغلبية متصفحات الويب والحواسيب التي تدعم SSL لديها قائمة بسلطات الشهادات التي تُقبَل شهاداتها تلقائيًا؛ إذا واجه المتصفح شهادةً لم تكن سلطة الشهادات التي أصدرتها في قائمته، فإنه (أي المتصفح) سيطلب من المستخدم قبول أو رفض الاتصال؛ وقد تُولِّد بعض التطبيقات الأخرى رسالة خطأ عند استخدام شهادة موقعة ذاتيًا. عملية الحصول على شهادة من سلطة الشهادات هي عملية سهلة جدًا، لمحة سريعة هي الآتية: أنشِئ زوج مفاتيح خاص وعام.أنشِئ طلب شهادة بناءً على المفتاح العمومي، يحتوي طلب الشهادة على معلومات عن خادومك والشركة التي تستضيفه.أرسل طلب الشهادة مع الوثائق التي تثبت هويتك إلى سلطة الشهادات؛ لا نستطيع إخبارك أيّة سلطة شهادات عليك أن تختارها؛ ربما يكون قرارك مبنيًا على تجارب سابقة، أو على تجارب أحد أصدقائك أو زملائك، أو على عوامل اقتصادية.بعد أن تختار سلطة الشهادات، فعليك اتباع تعليماتهم التي يوفرونها عن كيفية الحصول على شهادة منهم.بعد أن تتأكد سلطة الشهادات أنك من تدعيّ أنك هو؛ فسيرسلون لك شهادةً رقميةً.ثبِّت هذه الشهادة على خادومك الآمن، واضبط البرامج الملائمة لاستخدام هذه الشهادة.توليد طلب توقيع الشهادة (CSR)إذا كنت ستحصل على شهادة من سلطة شهادات أو كنت ستُوقِّع شهادتك ذاتيًا، فإن أول خطوة هي توليد مفتاح. إذا كانت الشهادة ستُستخدَم من عفاريت الخدمات، مثل أباتشي، أو Postfix، أو Dovecot ...إلخ. فإن مفتاحًا بدون عبارة مرور (passphrase) كافٍ عادةً؛ عدم وجود عبارة مرور تسمح للخدمات أن تبدأ دون تدخل يدوي، وهذه هي الطريقة المفضلة لبدء تشغيل عفريت. سيغطي هذا القسم طريقة توليد مفتاح مع عبارة مرور، وواحد آخر بدون عبارة مرور؛ ثم سنستخدم المفتاح بدون عبارة مرور لتوليد شهادة ستُستخدَم في مختلف عفاريت الخدمات. تحذير: تشغيل خدمة آمنة بدون عبارة مرور هو أمر ملائم ﻷنك لن تحتاج إلى إدخال عبارة المرور كل مرة تبدأ فيها خدمتك الآمنة، لكن هذا غير آمن وأي كشف عن المفتاح سيؤدي إلى جعل الخادوم عرضةً للهجمات. لتوليد «مفاتيح» لطلب توقيع الشهادة، عليك تنفيذ الأمر الآتي من مِحَث الطرفية: openssl genrsa -des3 -out server.key 2048 Generating RSA private key, 2048 bit long modulus ..........................++++++ .......++++++ e is 65537 (0x10001) Enter pass phrase for server.key:تستطيع الآن إدخال عبارة مرورك، لأفضل قدر من الحماية، يجب أن تحتوي على الأقل على ثمانية محارف؛ الطول الأدنى عند تحديد الخيار ‎-des3 هو أربعة محارف؛ ويجب أن تحتوي على أرقام أو على علامات ترقيم ولا تحتوي على كلمة من القاموس؛ تذكر أن عبارة المرور حساسة لحالة الأحرف. أعد كتابة عبارة المرور للتحقق؛ وبعد إعادة كتابتها بشكل صحيح، فسيُولَّد مفتاح الخادوم وسيُخزَّن في ملف server.key. أنشِئ الآن مفتاحًا غير آمن (insecure أي بدون عبارة مرور) ثم بدِّل بين أسماء المفاتيح: openssl rsa -in server.key -out server.key.insecure mv server.key server.key.secure mv server.key.insecure server.keyأصبح الآن اسم ملف المفتاح غير الآمن هو server.key، وسنستخدم هذا الملف لتوليد CSR بدون عبارة مرور. نفِّذ الأمر الآتي في مِحَث الطرفية لإنشاء CSR: openssl req -new -key server.key -out server.csrستُسأل عن إدخال عبارة المرور، إذا أدخلت عبارةً صحيحةً، فستُسأل عن إدخال اسم الشركة، واسم الموقع، ومعرف البريد الإلكتروني ...إلخ. بعد أن تُدخِل كل هذه التفاصيل، فسيُنشَأ طلب توقيع الشهادة (CSR) وسيُخزَّن في ملف server.csr. يجب الآن إرسال ملف طلب توقيع الشهادة إلى سلطة الشهادات لمعالجته؛ ستستخدم سلطة الشهادات ملف طلب توقيع الشهادة لإصدار الشهادة؛ وعلى الكفة الأخرى، تستطيع توليد شهادتك الموقعة ذاتيًا باستخدام طلب توقيع الشهادة السابق. إنشاء شهادة موقعة ذاتيانفِّذ الأمر الآتي في الطرفية لإنشاء شهادة موقعة ذاتيًا: openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crtسيسألك الأمر السابق عن عبارة المرور، بعد أن تدخل عبارة المرور الصحيحة، فستُنشَأ الشهادة وتُخزَّن في ملف server.crt. تحذير: إذا استُخدِم خادومك الآمن في بيئة إنتاجية، فربما تحتاج إلى شهادة موقع من سلطة الشهادات (CA)، ليس من المستحسن استخدام شهادة موقعة ذاتيًا. تثبيت الشهادةتستطيع تثبيت ملف المفتاح server.key وملف الشهادة server.crt أو ملف الشهادة المُصدَر من سلطة الشهادات، بتنفيذ الأمرين الآتيين في الطرفية: sudo cp server.crt /etc/ssl/certs sudo cp server.key /etc/ssl/privateاضبط الآن ببساطة أيّة تطبيقات فيها إمكانية استخدام التشفير وفق المفتاح العمومي لكي تستخدم ملفات الشهادة والمفتاح؛ على سبيل المثال، يمكن أن يزود أباتشي HTTPS، و Dovecot يستطيع أن يزود IMAPS و POP3S ...إلخ. سلطة الشهاداتإذا كانت تتطلب الخدمات على شبكتك أكثر من مجرد بضع شهادات موقعة ذاتيًا، فربما يكون من المفيد بذل جهد إضافي وإعداد سلطة شهادات داخلية؛ ستسمح الشهادات الموقعة من سلطة الشهادات الخاصة بك لمختلف الخدمات باستخدام الشهادات لكي تثق بسهولة بالخدمات الأخرى التي تملك شهادات مُصدَرة من نفس سلطة الشهادات. أنشِئ أولًا المجلدات التي سنضع فيها شهادة سلطة الشهادات والملفات المتعلقة بذلك: sudo mkdir /etc/ssl/CA sudo mkdir /etc/ssl/newcertsتحتاج سلطة الشهادات إلى بضعة ملفات إضافية لكي تعمل، واحدٌ لكي يتعقب آخر رقم تسلسلي اُستخدِم من سلطة الشهادات، إذ يجب أن تملك كل شهادة رقمًا تسلسليًا فريدًا؛ وملفٌ آخر لتسجيل الشهادات التي أُصدِرَت: sudo sh -c "echo '01' > /etc/ssl/CA/serial" sudo touch /etc/ssl/CA/index.txtالملف الثالث هو ملف ضبط سلطة الشهادات، على الرغم من أنه ليس مطلوبًا، لكن من المنطقي وجوده عند إنشاء عدّة شهادات؛ عدِّل ملف ‎/etc/ssl/openssl.cnf وفي قسم [ CA_default ]، غيِّر ما يلي: dir = /etc/ssl/ # Where everything is kept database = $dir/CA/index.txt # database index file. certificate = $dir/certs/cacert.pem # The CA certificate serial = $dir/CA/serial # The current serial number private_key = $dir/private/cakey.pem # The private keyثم أنشِئ الشهادة الجذر الموقعة ذاتيًا: openssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem \ -days 3650ستُسأل عن إدخال التفاصيل حول الشهادة. الآن ثبت الشهادة الجذر والمفتاح: sudo mv cakey.pem /etc/ssl/private/ sudo mv cacert.pem /etc/ssl/certs/أنت الآن جاهزٌ لبدء توقيع الشهادات، أول شيء مطلوب هو «طلب توقيع الشهادة» (راجع القسم السابق لمزيد من المعلومات)، بعد أن تحصل على طلب توقيع الشهادة، فأدخِل ما يلي لتوليد شهادة موقعة من سلطة الشهادات: sudo openssl ca -in server.csr -config /etc/ssl/openssl.cnfبعد إدخال كلمة المرور لمفتاح سلطة الشهادات، فستُسأل عن توقيع الشهادة، ومرةً أخرى لإصدار الشهادة، يجب أن ترى كميةً كبيرةً من المخرجات المتعلقة بإنشاء الشهادة. يجب أن يكون هنالك ملف جديد هو ‎/etc/ssl/netcerts/01.pem يحتوي على نفس المخرجات، انسخ والصق كل شيء من بداية السطر -----BEGIN CERTIFICATE----- إلى السطر ----END CERTIFICATE----- إلى ملف مسمى بنفس اسم المضيف لخادومك مكان تثبيت الشهادة؛ فمثلًا الاسم mail.example.com.crt هو اسم وصفي جيد. الشهادات المتتالية ستُسمى 02‎.pem ،03‎.pem ...إلخ. ملاحظة: استبدل mail.example.com.crt بالاسم الوصفي الخاص بك. في النهاية، انسخ الشهادة الجديدة إلى المضيف الذي يحتاج لها واضبط الخدمات الملائمة لكي تستخدمها، المكان الافتراضي لتثبيت الشهادات هو ‎/etc/ssl/certs، وهذا ما سيُمكِّن عدِّة خدمات من استخدام نفس الشهادة دون تعقيد أذونات الملف. للتطبيقات التي يمكن ضبطها لاستخدام شهادة CA، يجب أن تَنسخ أيضًا الملف ‎/etc/ssl/certs/cacert.pem إلى مجلد ‎/etc/ssl/certs/‎ على كل خادوم. مصادرلتعليمات تفصيلية عن استخدام التشفير، راجع صفحة «SSL Certificates HOWTO».صفحة ويكيبيديا HTTPS لديها المزيد من المعلومات حول HTTPS.للمزيد من المعلومات حول OpenSSL، راجع الصفحة الرئيسية لموقع OpenSSL.أيضًا، كتاب «Network Security with OpenSSL» من O'Reilly هو مرجع معمّق.ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Certifications.