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

يعد مولد الأرقام العشوائية لـ Go طريقة رائعة لإنشاء كلمات مرور يصعب تخمينها. يمكنك استخدام مولد الأرقام العشوائية الذي توفره لغة البرمجة Go لإنشاء كلمات مرور يصعب تخمينها تتكون من رموز ASCII. على الرغم من أن الكود المقدَّم في هذا المقال سهل القراءة، إلا أنّه يُفضَّل أن تكون على معرفةٍ سابقة بأساسيات Go لفهمها. إذا كنت حديث العهد بلغات البرمجة، فاختر مدخل إلى لغة البرمجة Go لمعرفة المزيد حول Go، ثم عد إلى هنا. قبل التعمُّق في الأدوات المساعدة والكود الخاص بـ Go، ألقِ نظرة على هذه المجموعة الفرعية من جدول ASCII كما هو موجود في ناتج الأمر man ascii: 30 40 50 60 70 80 90 100 110 120 --------------------------------- 0: ( 2 < F P Z d n x 1: ) 3 = G Q [ e o y 2: * 4 > H R \ f p z 3: ! + 5 ? I S ] g q { 4: " , 6 @ J T ^ h r | 5: # - 7 A K U _ i s } 6: $ . 8 B L V ` j t ~ 7: % / 9 C M W a k u DEL 8: & 0 : D N X b l v 9: ' 1 ; E O Y c m w القيم العشرية لرموز ASCII تتراوح من 33 إلى 126؛ لا توجد قيم ASCII أخرى مناسبة لتتواجد ضمن كلمات المرور. لذلك، سوف تنتج الأدوات المساعدة المقدَّمة في هذا المقال أحرف ASCII في هذا النطاق. خلق أعداد صحيحة عشوائية الأداة المساعدة الأولى تُدعى random.go، وتقوم بإنشاء عدد محدد من الأعداد الصحيحة العشوائية ضمن نطاق معين. الجزء الأكثر أهمية في random.go هو هذه الدالة: func random(min, max int) int { return rand.Intn(max-min) + min } تقوم هذه الدالّة بإنشاء أعداد صحيحة عشوائية تنتمي إلى نطاق معين باستخدام ()rand.intn. لاحظ أنّ rand.intn()‎ تقوم بإرجاع رقم عشوائي غير سالب ينتمي إلى المجال [0,n)، إذ n هو العدد المُمرَّر إلى الدالة. ستخرب الدالة إذا كان مُعاملها عددًا سالبًا وستكون رسالة الخطأ كما يلي: panic: invalid argument to Intn يُمكنك إيجاد توثيق المجموعة math/rand في هذا الرابط: math/rand Documentation. تقبل الدالة random.go ثلاثًا من عوامل سطر الأوامر (Command Line Parameters): الحد الأدنى لقيمة الأعداد الصحيحة المراد توليدها. والقيمة القصوى. وعدد الأعداد الصحيحة التي سيتم توليدها. تجميع وتنفيذ random.go سيخلق هذا النوع من الناتج: $ go build random.go $ ./random Usage: ./random MIX MAX TOTAL $ ./random 1 3 10 2 2 1 2 2 1 1 2 2 1 إذا كنت ترغب في إنشاء أرقام عشوائية أكثر أمانًا في Go، فاستخدم حزمة crypto / rand من مكتبة Go. إنشاء كلمات مرور عشوائية الأداة المساعدة الثانية randomPass.go، تنشئ كلمات مرور عشوائية. يستخدم randomPass.go الدالة ()random لإنشاء أرقام عشوائية سيتم تحويلها إلى رموز ASCII باستخدام كود Go التالي: for { myRand := random(MIN, MAX) newChar := string(startChar[0] + byte(myRand)) fmt.Print(newChar) if i == LENGTH { break } i++ } قيمة MIN هي 0 وقيمة MAX هي 94، في حين أن قيمة startChar هي !، وهو أول حرف قابل للطباعة في جدول ASCII (برمز ASCII العشري وهو 33). لذلك، توجد جميع أحرف ASCII التي سيتم إنشاؤها بعد ! وقبل الحرف ~، الذي يحتوي على رمز ASCII العشري لـلرقم 126. لذلك، كل رقم عشوائي يتم إنشاؤه أكبر من MIN، وأصغر من MAX، ويتم تحويله إلى رمز ASCII. تستمر العملية حتى تصبح كلمة المرور التي تم إنشاؤها لها بالطول المطلوب. تقبل randomPass.go معامل سطر أوامر واحد (اختياري) يُحدد طول كلمة المرور التي تم إنشاؤها. القيمة الافتراضية هي ثمانية، وهو طول كلمة مرور شائع جدًا. سيؤدي تنفيذ randomPass.go إلى الناتج التالي: $ go run randomPass.go 1 Z $ go run randomPass.go 10 #Cw^a#IwkT $ go run randomPass.go Using default values! [PP8@'Ci تفصيل أخير: لا تنس استعمال ()rand.seed مع قيمة أولية لتهيئة مولد الأرقام العشوائية. إذا استخدمت نفس القيمة الأولية في كل وقت، فسيقوم مُولِّد الأرقام العشوائية بإنشاء نفس تسلسل الأعداد الصحيحة العشوائية. تستطيع إيجاد كلًا من random.go و randomPass.go على GitHub. وتستطيع أيضًا تنفيذ هذه الدوال على play.golang.org ترجمة -وبتصرف- للمقال Creating random, secure passwords in Go لصاحبه Mihalis Tsoukalos.

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

تمهيد إنَّ MySQL هي أشهر نظام مفتوح المصدر لإدارة قواعد البيانات العلاقية في العالم؛ وحاولت برمجيات إدارة الحزم تقليل الجهد اللازم لتثبيت خادوم MySQL وتشغيله، لكن ما يزال عليك إجراء بعض عمليات الضبط بعد التثبيت. وأنصحك بقضاء بعض الوقت محاولًا زيادة حماية وأمان قواعد بياناتك. تُضبَط MySQL مبدئيا لقبول الاتصالات المحلية فقط، فلو أردتَ السماح بالاتصالات «البعيدة» فمن المهم أن تكون تلك الاتصالات آمنة؛ وسنشرح في هذا الدرس كيفية السماح بالاتصالات البعيدة إلى خادوم MySQL على أوبنتو 16.04 مع تشفير SSL/TLS. المتطلبات المسبقة إذا أردتَ المتابعة مع هذا الدرس، فستحتاج إلى خادومَي أوبونتو 16.04، إذ سنستخدم أحدها لاستضافة خادوم MySQL وسيلعب الآخر دور العميل. عليك أيضًا إنشاء مستخدم ليس جذرًا لكنه يمتلك امتيازات الجذر عبر الأمر sudo، راجع درس الإعداد الابتدائي لخادوم أوبنتو 14.04 للمزيد من المعلومات حول الضبط المبدئي لخادومك. يجب أن تثبّت على الجهاز الأول خادوم MySQL وتضبطه؛ يمكنك العودة إلى درستثبيت وإعداد نظامي إدارة قواعد البياناتMySQL وPostgreSQL على أوبنتو لمزيدٍ من المعلومات حول تثبيت وضبط هذه البرمجية. أما على الجهاز الثاني، فعليك تثبيت حزمة عميل MySQL، إذ تستطيع استخدام الأمر apt لتحديث فهرس الحزم ثم تثبيت البرمجيات الضرورية وذلك بتنفيذ الأمرين الآتيين: sudo apt-get update sudo apt-get install mysql-client يُفتَرَض أن يعمل خادومك وعمليك عملًا سليمًا. التحقق من حالة تشفير SSL/TLS الراهنة على خادوم MySQL علينا قبل البدء أن نتحقق من الحالة الراهنة لتشفير SSL/TLS على خادومنا. سجِّل دخولك إلى خادومك MySQL عبر المستخدم root التابع لقواعد MySQL. سنستخدم في الأمر الآتي الخيار ‎-h لتحديد عنوان IP للجهاز المحلي لكي يتصل العميل باستخدام بروتوكول TCP بدلًا من استخدام ملف socket محلي؛ وهذا سيُمكننا من التحقق من حالة تشفير SSL لاتصالات TCP: mysql -u root -p -h 127.0.0.1 ستُسأل عن كلمة مرور مستخدم root التي اخترتها أثناء عملية تثبيت خادوم MySQL؛ وبعدئذٍ ستنتقل إلى جلسة MySQL تفاعلية. يمكننا إظهار حالة متغيرات SSL/TLS عبر كتابة التعليمة الآتية: SHOW VARIABLES LIKE '%ssl%'; الناتج: +---------------+----------+ | Variable_name | Value | +---------------+----------+ | have_openssl | DISABLED | | have_ssl | DISABLED | | ssl_ca | | | ssl_capath | | | ssl_cert | | | ssl_cipher | | | ssl_crl | | | ssl_crlpath | | | ssl_key | | +---------------+----------+ 9 rows in set (0.01 sec) لاحظ أنَّ قيمة المتغيرين have_openssl و have_ssl تساوي DISABLED، وهذا يعني أنَّ دعم تشفير SSL مبنيٌ داخل الخادوم لكنه ليس مفعلًا بعد. لنتحقق من حالة الاتصال الحالي للتأكد من النتائج السابقة، وذلك بإدخال: \s الناتج: -------------- mysql Ver 14.14 Distrib 5.7.17, for Linux (x86_64) using EditLine wrapper Connection id: 30 Current database: Current user: root@localhost SSL: Not in use Current pager: stdout Using outfile: '' Using delimiter: ; Server version: 5.7.17-0ubuntu0.16.04.1 (Ubuntu) Protocol version: 10 Connection: 127.0.0.1 via TCP/IP Server characterset: latin1 Db characterset: latin1 Client characterset: utf8 Conn. characterset: utf8 TCP port: 3306 Uptime: 3 hours 38 min 44 sec Threads: 1 Questions: 70 Slow queries: 0 Opens: 121 Flush tables: 1 Open tables: 40 Queries per second avg: 0.005 -------------- يمكننا أن نلاحظ من الناتج السابق أنَّ الاتصال غير مشفر عبر SSL، حتى لو كنّا قد اتصلنا عبر بروتوكول TCP. أغلق جلسة MySQL عندما تنتهي: exit يمكننا الآن البدء بضبط MySQL لتستعمل تشفير SSL للاتصالات القادمة إليها. توليد شهادات ومفاتيح SSL/TLS لتفعيل اتصالات مشفرة عبر SSL إلى MySQL، فعلينا أولًا توليد الشهادات والمفاتيح المناسبة. هنالك أداةٌ باسم mysql_ssl_rsa_setup متوافرة مع MySQL 5.7 وما بعدها مهمتها تبسيط هذه العملية؛ وهنالك إصدار MySQL متوافق معها متوافر في أوبنتو 16.04، لذا سنستخدم هذا الأمر لتوليد الملفات اللازمة. ستُنشَأ الملفات في مجلد ملفات MySQL الموجود في المسار ‎/var/lib/mysql؛ وعلينا السماح لعملية MySQL (أي MySQL process) بقراءة الملفات المولّدة، لذا سنُمرِّر القيمة mysql اسمًا للمستخدم الذي سيملك الملفات المولّدة: sudo mysql_ssl_rsa_setup –uid=mysql سيكون ناتج عملية التوليد مشابهًا لما يلي: Generating a 2048 bit RSA private key ...................................+++ .....+++ writing new private key to 'ca-key.pem' ----- Generating a 2048 bit RSA private key ......+++ .................................+++ writing new private key to 'server-key.pem' ----- Generating a 2048 bit RSA private key ......................................................+++ .................................................................................+++ writing new private key to 'client-key.pem' ----- تحقق من إنشاء الملفات الذي جرت عملية توليدها بالأمر find: sudo find /var/lib/mysql -name '*.pem' -ls الناتج: 256740 4 -rw-r--r-- 1 mysql mysql 1078 Mar 17 17:24 /var/lib/mysql/server-cert.pem 256735 4 -rw------- 1 mysql mysql 1675 Mar 17 17:24 /var/lib/mysqlsql/ca-key.pem<^> 256739 4 -rw-r--r-- 1 mysql mysql 451 Mar 17 17:24 /var/lib/mysqlsql/public_key.pem<^> 256741 4 -rw------- 1 mysql mysql 1679 Mar 17 17:24 /var/lib/mysqlsql/client-key.pem<^> 256737 4 -rw-r--r-- 1 mysql mysql 1074 Mar 17 17:24 /var/lib/mysqlsql/ca.pem<^> 256743 4 -rw-r--r-- 1 mysql mysql 1078 Mar 17 17:24 /var/lib/mysqlsql/client-cert.pem<^> 256736 4 -rw------- 1 mysql mysql 1675 Mar 17 17:24 /var/lib/mysqlsql/private_key.pem<^> 256738 4 -rw------- 1 mysql mysql 1675 Mar 17 17:24 /var/lib/mysqlsql/server-key.pem<^> آخر عمود من الناتج السابق يُظهِر أسماء الملفات المولّدة، أما العمود الرابع والخامس فيؤكدان أنَّ المستخدم المالك والمجموعة المالكة هو mysql. تُمثِّل هذه الملفات مفاتيح وشهادات لسلطة الشهادات Certificate authority (للملفات التي تبدأ بالسابقة «ca»)، ولعملية خادوم MySQL (للملفات التي تبدأ بالسابقة «server»)، ولعملاء MySQL (للملفات التي تبدأ بالسابقة «client»). إضافةً إلى ما سبق، هنالك الملفان private_key.pem و public_key.pem اللذان تستعملهما MySQL لنقل كلمة المرور بأمان دون استخدام SSL. تفعيل اتصالات SSL الآمنة على خادوم MySQL ستبحث الإصدارات الحديثة من MySQL عن ملفات الشهادات الملائمة ضمن مجلد بيانات MySQL عندما يبدأ الخادوم. ولهذا السبب، لن نحتاج إلى تعديل ضبط MySQL لتفعيل تشفير SSL. كل ما علينا فعله هو إعادة تشغيل خدمة MySQL: sudo systemctl restart mysql بعد إعادة التشغيل، افتح اتصالًا إلى خادوم MySQL بالأمر الذي ذكرناه في بداية هذا الدرس؛ وسيحاول عميل MySQL الاتصال عبر تشفير SSL إن كان مدعومًا من الخادوم: mysql -u root -p -h 127.0.0.1 لننظر مرةً أخرى إلى المعلومات التي طلبناها أوّل مرة، ولنلاحظ القيم المرتبطة بالمتغيرات المتعلقة بتشفير SSL: SHOW VARIABLES LIKE '%ssl%'; الناتج: +---------------+-----------------+ | Variable_name | Value | +---------------+-----------------+ | have_openssl | YES | | have_ssl | YES | | ssl_ca | ca.pem | | ssl_capath | | | ssl_cert | server-cert.pem | | ssl_cipher | | | ssl_crl | | | ssl_crlpath | | | ssl_key | server-key.pem | +---------------+-----------------+ 9 rows in set (0.00 sec) نجد أنَّ قيم المتغيرات have_openssl و have_ssl أصبحت YES بدلًا من DISABLED؛ وسنلاحظ وجود قيم مرتبطة بالمتغيرات ssl_ca و ssl_cert و ssl_key وهي أسماء ملفات الشهادات المولَّدة. لنتحقق مجددًا من معلومات الاتصال بتنفيذ: \s الناتج: -------------- . . . SSL: Cipher in use is DHE-RSA-AES256-SHA . . . Connection: 127.0.0.1 via TCP/IP . . . -------------- أصبح الناتج هذه المرة يشير إلى استخدام تشفير SSL لجعل اتصالنا مع الخادوم آمنًا. لنعد إلى سطر الأوامر بالخروج من MySQL: exit أصبح بإمكان خادومنا الآن تشفير الاتصالات، لكن ما يزال علينا إجراء بعض الضبط الإضافي للسماح بالاتصالات البعيدة وإجبار العملاء على استخدام الاتصالات الآمنة. ضبط الاتصالات الآمنة للاتصالات البعيدة بعد أن أصبح تشفير SSL متاحًا على الخادوم، يمكننا البدء بضبط الوصول البعيد، وعلينا فعل ما يلي لتحقيق ذلك: جعل استخدام SSL ضروريًا للاتصال. ربط الخادوم ببطاقة شبكية عامة. إنشاء مستخدم MySQL للاتصالات البعيدة. تعديل قواعد الجدار الناري للسماح بالاتصالات الخارجية. جعل استخدام SSL ضروريًا لإجراء الاتصال أصبح خادوم MySQL مضبوطًا لقبول اتصالات SSL من العملاء؛ لكنه ما يزال يسمح بإجراء اتصالات غير مشفرة إذا طلب العميل ذلك. يمكننا حل هذه المشكلة بتفعيل الخيار require_secure_transport الذي لا يسمح إلا بالاتصالات المشفرة عبر SSL أو عبر مقبس Unix محلي؛ ولعدم إتاحة الاتصال عبر المقبس المحلي إلا ضمن الخادوم نفسه، فالحل الوحيد لاتصال العملاء البعيدين هو استخدام SSL للتشفير. عدِّل ملف ‎/etc/mysql/my.cnf باستعمال محررك النصي المفضل لتفعيل هذا الخيار: sudo nano /etc/mysql/my.cnf ستجد داخل الملف تعليمتَي ‎!includedir التي تستخدم لقراءة ملفات الضبط الإضافية، علينا وضع الضبط الخاص بنا تحت تلك الأسطر لتجاوز أيّة تعليمات ضبط موجودة داخل ملفات الضبط الإضافية. ابدأ بإنشاء قسم [mysqld] لاستهداف عملية خادوم MySQL، واضبط تحت ترويسة هذا القسم الخيار require_secure_transport إلى ON: . . . !includedir /etc/mysql/conf.d/ !includedir /etc/mysql/mysql.conf.d/ [mysqld] # Require clients to connect either using SSL # or through a local socket file require_secure_transport = ON لن نحتاج إلى أكثر من هذا السطر لجعل استخدام الاتصالات المشفرة ضروريًا. إنَّ خادوم MySQL مضبوطٌ مبدئيًّا للاستماع إلى الاتصالات الآتية من الحاسوب المحلي فقط، وللاستماع إلى الاتصالات البعيدة، فيمكننا ضبط قيمة التعليمة bind-address للإشارة إلى بطاقة شبكية مختلفة. للسماح لخادوم MySQL بقبول الاتصالات من جميع البطاقات الشبكية، فيمكننا ضبط قيمة التعليمة bind-address إلى 0.0.0.0: . . . !includedir /etc/mysql/conf.d/ !includedir /etc/mysql/mysql.conf.d/ [mysqld] # Require clients to connect either using SSL # or through a local socket file require_secure_transport = ON bind-address = 0.0.0.0 احفظ الملف وأغلقه بعد أن تنتهي من تعديله. أعد تشغيل خادوم MySQL لتطبيق الضبط الجديد: sudo systemctl restart mysql تأكد أنَّ خادوم MySQL يستمع على 0.0.0.0 بدلًا من 127.0.0.1 بكتابة: 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:3306 0.0.0.0:* LISTEN 4330/mysqld tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1874/sshd tcp6 0 0 :::22 :::* LISTEN 1874/sshd القيمة 0.0.0.0 في الناتج السابق تُشير إلى أنَّ خدمة MySQL تستمع إلى الاتصالات في جميع البطاقات الشبكية المتاحة. علينا بعدئذٍ السماح لاتصالات MySQL عبر الجدار الناري، وذلك بإنشاء استثناء كما يلي: sudo ufw allow mysql الناتج: Rule added Rule added (v6) يجب أن تتمكن الاتصالات البعيدة من الوصول إلى خادوم MySQL. إنشاء مستخدم MySQL للاتصالات البعيدة أصبح خادوم MySQL جاهزًا للاستماع إلى الاتصالات البعيدة، لكننا لا نملك حاليًا أيّ مستخدم مضبوط لكي يتصل من حاسوبٍ آخر. سجِّل دخولك إلى خادوم MySQL عبر المستخدم root: mysql -u root -p يمكننا الآن إنشاء حساب للمستخدم البعيد عبر الأمر CREATE USER، وسنستخدم عنوان IP لجهاز العميل في قسم المضيف من تعليمة تعريف المستخدم الجديد لجعل الاتصال عبر هذا المستخدم محصورًا بذاك الجهاز. ولضمان الاتصال عبر SSL حتى لو عُطِّلَ الخيار require_secure_transport مستقبلًا، فسنُحدِّد في تعليمة تعريف الحساب أنَّه يجب استعمال SSL عند الاتصال باستخدام هذا الحساب بتضمين REQUIRE SSL: CREATE USER 'remote_user'@'mysql_client_IP' IDENTIFIED BY 'password' REQUIRE SSL; علينا بعد ذلك أن نمنح المستخدم صلاحيات على قواعد البيانات أو الجداول التي ينبغي له الوصول إليها؛ وسنُنشِئ قاعدة بيانات لشرح هذه الفكرة باسم example وسنمنح مستخدمنا ملكيتها: CREATE DATABASE example; GRANT ALL ON example.* TO 'remote_user'@'mysql_client_IP'; علينا تحديث جداول الصلاحيات لتطبيق التعديلات مباشرةً: FLUSH PRIVILEGES; أغلِق جلسة MySQL بعد أن تنتهي من تنفيذ الأوامر السابقة: exit اختبار الاتصالات البعيدة لاختبار إمكانية إجراء اتصال من جهاز العميل إلى الخادوم بنجاح، فاستخدم الخيار ‎-u لتحديد اسم المستخدم البعيد، والخيار ‎-h لتحديد عنوان IP لخادوم MySQL: mysql -u remote_user -p -h mysql_server_IP بعد كتابتك لكلمة المرور، فستسجل دخولك إلى الخادوم البعيد. نفذ الأمر الآتي للتأكد من أنَّ اتصالك آمن: \s الناتج: -------------- . . . SSL: Cipher in use is DHE-RSA-AES256-SHA . . . Connection: mysql_server_IP via TCP/IP . . . -------------- اخرج من عميل MySQL وعد إلى سطر الأوامر: exit جرِّب الآن الاتصال بطريقة غير آمنة إلى الخادوم: mysql -u remote_user -p -h mysql_server_IP –ssl-mode=disabled بعد أن يُطلَب منك إدخال كلمة المرور، فستجد أنَّ الاتصال قد رُفِض: ERROR 1045 (28000): Access denied for user 'remote_user'@'mysql_server_IP' (using password: YES) هذا ما بدأنا درسنا محاولين إنجازه: فالاتصالات المشفرة عبر SSL إلى الخادوم مسموحة، والاتصالات غير المشفرة ممنوعة. لهذا الحد، أصبح خادوم MySQL مضبوطًا للسماح بالاتصالات البعيدة الآمنة؛ ويمكنك أن تتوقف عند هذه النقطة إذا كان ذلك يلبي احتياجاتك الأمنية، لكن هنالك المزيد من الأمور التي يمكنك فعلها لزيادة الحماية. ضبط التحقق من الاتصالات الآتية إلى خادوم MySQL إنَّ خادوم MySQL مضبوطٌ حاليًا مع شهادة SSL موقعة من سلطة شهادات محلية (Local certificate authority)؛ والشهادة والمفتاح الخاصَين بالخادوم كافيان لتشفير الاتصالات القادمة إلى الخادوم. لكننا لم نستفد من «الثقة» التي يمكن لسلطة الشهادات توفيرها، فعند توزيع شهادة سلطة الشهادات إلى العملاء، إضافةً إلى شهادة ومفتاح خاصَين بالعميل، فيمكن لكلا الطرفين التأكد أنَّ الشهادات موقعة من سلطة شهادات موثوقة. يمكن أن يساعد ذلك بمنع الاتصالات المزورة إلى أجهزة خبيثة. لتطبيق هذا النوع من الحماية الإضافية، فسنحتاج إلى: نقل ملفات SSL الملائمة إلى جهاز العميل إنشاء ملف ضبط للعميل تعديل حساب المستخدم البعيد لطلب وجود شهادة موثوقة نقل شهادات العميل إلى جهازه علينا بادئ الأمر الحصول على شهادة سلطة الشهادات التابعة لخادوم MySQL مع ملفات شهادات العميل ووضعها في جهاز العميل. سنبدأ بفعل ذلك بإنشاء مجلد باسم client-ssl في جهاز العميل في مجلد المنزل للمستخدم الذي ستستعمله للاتصال: mkdir ~/client-ssl ولأنَّ مفتاح الشهادة هو ملفٌ حساس، فعلينا قفل الوصول إلى المجلد لكي لا يتمكن أي شخصٍ سوى المستخدم المالك له من الوصول إليه: chmod 700 ~/client-ssl يمكننا الآن نسخ معلومات الشهادة إلى مجلدٍ جديد. اعرض محتوى شهادة سلطة الشهادات في خادوم MySQL بكتابة الأمر الآتي: sudo cat /var/lib/mysql/ca.pem الناتج: -----BEGIN CERTIFICATE----- . . . -----END CERTIFICATE----- انسخ جميع المحتوى بما فيه الأسطر التي فيها BEGIN CERTIFICATE و END CERTIFICATE إلى الحافظة. أنشِئ ملفًا جديدًا في جهاز العميل باستعمال الأمر الآتي: nano ~/client-ssl/ca.pem ألصق محتوى الشهادة المنسوخ في ذاك الملف، ثم احفظه وأغلق الملف عندما تنتهي منه. علينا الآن عرض محتوى شهادة العميل في خادوم MySQL: sudo cat /var/lib/mysql/client-cert.pem الناتج: -----BEGIN CERTIFICATE----- . . . -----END CERTIFICATE----- انسخ محتوياته مجددًا، واحرص على تضمين أول وآخر سطر. أنشِئ ملفًا جديدًا في عميل MySQL بالاسم نفسه ضمن مجلد client-ssl: nano ~/client-ssl/client-cert.pem ألصق محتويات الحافظة إلى الملف، ثم احفظه وأغلقه. ثم اعرض محتويات مفتاح العميل على خادوم MySQL: sudo cat /var/lib/mysql/client-key.pem الناتج: -----BEGIN RSA PRIVATE KEY----- . . . -----END RSA PRIVATE KEY----- انسخ محتوياته مجددًا إلى حافظتك، واحرص على تضمين أول وآخر سطر. أنشِئ ملفًا جديدًا في عميل MySQL بالاسم نفسه ضمن مجلد client-ssl: nano ~/client-ssl/client-key.pem ألصق محتويات الحافظة إلى الملف، ثم احفظه وأغلقه. يجب يكون في جهاز العميل جميع الشهادات اللازمة للوصول إلى خادوم MySQL؛ وعلينا الآن تعديل حساب المستخدم. تعديل حساب المستخدم البعيد لطلب وجود شهادة موثوقة أصبح لدى عميل MySQL الملفات اللازمة للتحقق من الشهادة عند الاتصال بخادوم MySQL، لكن الخادوم ليس مضبوطًا بعد لطلب وجود شهادة للعميل من سلطة شهادات موثوقة. لتعديل ذلك، علينا تسجيل الدخول عبر المستخدم root في خادوم MySQL: mysql -u root -p سنحتاج إلى تعديل المتطلبات الخاصة بالمستخدم البعيد، فبدلًا من استعمال عبارة REQUIRE SSL علينا استعمال عبارة REQUIRE X509 والتي ستُطبِّق الإجراءات الأمنية نفسها، لكنها ستتطلب أيضًا أن يملك العميل شهادةً موقعةً من سلطة شهادات يثق بها خادوم MySQL. علينا استعمال الأمر ALTER USER لتعديل المتطلبات الخاصة بالمستخدم: ALTER USER 'remote_user'@'mysql_client_IP' REQUIRE X509; ثم حدِّث جداول الصلاحيات لتأخذ التعديلات مجراها مباشرةً: FLUSH PRIVILEGES; اخرج من سطر أوامر MySQL عندما تنتهي بالأمر: exit سنتأكد في الخطوة التالية أننا ما زلنا نستطيع الاتصال. تجربة التحقق من الشهادة عند الاتصال من المناسب الآن معرفة أنَّ كلا الطرفين سيستطيع التحقق من شهادة الآخر عند الاتصال. لنحاول أولًا الاتصال من عميل MySQL دون توفير شهادات له: mysql -u remote_user -p -h mysql_server_IP الناتج: ERROR 1045 (28000): Access denied for user 'remote_user'@'mysql_client_IP' (using password: YES) سيرفض الخادوم الاتصال إذا لم نوفِّر شهادة للعميل. حاول الآن الاتصال مع توفير الخيارات ‎--ssl-ca و ‎--ssl-cert و ‎--ssl-key للإشارة إلى الملفات الموافقة لها والموجودة في مجلد ‎~/client-ssl: mysql -u remote_user -p -h mysql_server_IP --ssl-ca=~/client-ssl/ca.pem --ssl-cert=~/client-ssl/client-cert.pem –ssl-key=~/client-ssl/client-key.pem يجب أن تستطيع تسجيل الدخول إلى خادوم MySQL بنجاح. يمكنك العودة إلى سطر الأوامر بتنفيذ: exit لقد تأكدنا الآن من القدرة على الوصول إلى الخادوم، لكن يمكننا تحسين قابلية الوصول إليه بإنشاء ملف ضبط. إنشاء ملف ضبط لعميل MySQL لتجنب تحديد ملفات الشهادات في كل مرة نتصل فيها إلى الخادوم، فيمكننا إنشاء ملف ضبط بسيط لعميل MySQL. أنشِئ ملفا مخفيًا في مجلد المنزل في عميل MySQL باسم ‎~/.my.cnf: nano ~/.my.cnf أنشِئ في بداية ذاك الملف قسمًا باسم [client]، ويمكننا بعد ذلك السطر إضافة الخيارات ssl-ca و ssl-cert و ssl-key للإشارة إلى الملفات التي نسخناها من الخادوم؛ يجب أن يبدو شكل الملف كالآتي: [client] ssl-ca = ~/client-ssl/ca.pem ssl-cert = ~/client-ssl/client-cert.pem ssl-key = ~/client-ssl/client-key.pem يُخبِر الخيار ssl-ca العميل أن يتحقق أنَّ الشهادة التي وفرها خادوم MySQL موقعةٌ من سلطة الشهادات التي أشرنا إلى شهادتها. وهذا يجعل العميل متأكدًا أنه يتصل بخادوم MySQL موثوق. أما الخياران ssl-cert و ssl-key فيشيران إلى الملفات اللازمة لإثبات أنَّ العميل يملك شهادة موقعة من سلطة الشهادات نفسها. سنحتاج إلى ذلك إذا أردنا في خادوم MySQL التحقق أنَّ العميل موثوق من سلطة الشهادات أيضًا. احفظ الملف وأغلقه عندما تنتهي من التعديلات عليه. يمكنك الآن الاتصال إلى خادوم MySQL دون إضافة الخيارات ‎--ssl-ca و ‎--ssl-cert و ‎--ssl-key في سطر الأوامر: mysql -u remote_user -p -h mysql_server_ip يجب أن يملك الخادوم والعميل الآن الشهادات اللازمة للاتصال بأمان، وضبطنا كلا الطرفين للتحقق أنَّ الشهادة موقعة من سلطة الشهادات الموثوقة. الخلاصة يجب أن يكون خادومك مضبوطًا لقبول الاتصالات الآمنة من العملاء البعيدين. وإذا اتبعتَ الخطوات اللازمة للتحقق من الشهادات عبر سلطة الشهادات فسيتأكد كلا الطرفين من وثوقية الطرف الآخر. ترجمة –وبتصرّف– للمقال How To Configure SSL/TLS for MySQL on Ubuntu 16.04 لصاحبه Justin Ellingwood

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

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

ينصبّ الاهتمام عند إعداد بنية تحتيّة 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.

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

سنتعلّم في هذا الدّرس المفاهيم الأساسيّة التي نحتاجها قبل الحصول على شهادة SSL من سلطة شهادات تجاريّة Commercial Certificate Authority CA، تسمح شهادات SSL لخواديم الويب بتشفير حركة مرور بياناتها traffic وتُوفِّر آليّة للتحقّق من هويّات الخواديم من أجل الزوّار، إنّ الميزة الأساسيّة لشراء شهادة SSL من سلطة شهادات تجاريّة (CA) موثوقة عن الشهادات المُوقَّعة ذاتيًّا self-signed أنّه لن يتم عرض تحذير مُخيف للزوّار حول عدم القدرة على التحقّق من هويّة موقعنا. يغطّي هذا الدرس المتطلبات الأساسيّة التي يجب التأكد منها قبل الحصول على شهادة SSL، ويشرح الأنواع المختلفة للشهادات. المتطلبات الأساسيةهنالك العديد من المتطلبات التي يجب التأكد منها قبل محاولة الحصول على شهادة SSL من سلطة شهادات تجاريّة، سيغطي هذا القسم الأمور التي نحتاجها ليتم إصدار شهادة SSL لنا من معظم سلطات الشهادات التجارية. الماليجب علينا شراء شهادات SSL الصادرة عن سلطات الشهادات التجاريّة، تتضمّن البدائل المجانيّة لها الشهادات المُوقَّعة ذاتيًّا self-signed أو شهادات StartSSL، ومع ذلك فإنّ الشهادات المُوقَّعة ذاتيًّا غير موثوقة من قبل أيّة برمجيات، ولا يُمكِن استخدام شهادات StartSSL لأغراض تجاريّة. اسم نطاق Domain مسجلينبغي قبل الحصول على شهادة SSL أن نملك اسم نطاق مُسجَّل والذي نرغب باستخدام الشهادة معه، إن كُنّا لا نمتلك اسم نطاق مُسجَّل فبإمكاننا تسجيله باستخدام أحد مُسجِّلات اسم النطاق المتوفِّرة (مثل Namecheap، GoDaddy، إلخ..). حقوق التحقق من النطاقيجب من أجل العمليّة الأساسيّة للتحقّق من النطاق أن نملك نفاذًا إلى أحد عناوين البريد الإلكتروني على تسجيل WHOIS لنطاقنا أو إلى عنوان بريد إلكتروني من نمط مُدير admin على النطاق نفسه، تقوم سلطات الشهادات التي تُصدِر شهادات SSL نموذجيًّا بالتحقّق من التحكم بالنطاق عن طريق إرسال بريد إلكتروني للتحقّق إلى أحد عناوين البريد الإلكتروني على تسجيل WHOIS لنطاقنا، أو إلى عنوان بريد إلكتروني من نمط مدير عام على النطاق ذاته، توفّر بعض سلطات الشهادات طرق بديلة للتحقّق من النطاق، مثل DNS أو التحقّق المعتمد على HTTP والتي هي مواضيع خارج نطاق درسنا. إن كنت ترغب في إصدار شهادة SSL مع تحقّق من المنظّمة (Organization Validation (OV أو تحقّق مُوسَّع (Extended Validation (EV فيجب عليك تزويد سلطات الشهادات بأوراقك لتأسيس هوية قانونيّة لمالك الموقع من بين الأشياء الأخرى. خادوم الويبسنحتاج بالإضافة للنقاط المذكورة سابقًا إلى خادوم ويب لتثبيت شهادة SSL عليه، وهو الخادوم القابل للوصول إليه عبر اسم النطاق الذي سنصدر شهادة SSL له، سيكون نموذجيًّا خادوم Apache HTTP، Nginx، HAProxy، أو Varnish، إن كنت تحتاج المساعدة في إعداد خادوم ويب قابل للوصول من خلال اسم النطاق المُسجَّل لديك فقم باتباع الخطوات التالية: إعداد خادوم ويب من اختيارك، على سبيل المثال خادوم (LEMP (Nginx أو (LAMP (Apache.إعداد النطاق ليستخدم أسماء الخواديم nameservers الملائمة.إضافة تسجيلات DNS records لخادوم الويب إلى أسماء الخواديم لديك.اختيار سلطة الشهاداتإن لم تكن متأكّدًا من سلطة الشهادات التي تريد استخدامها فهنالك القليل من العوامل المهمّة التي يجب أن تأخذها بعين الاعتبار، وكنظرة عامّة فإنّ الشيء الأكثر أهمية أن تكون سلطة الشهادات التي تختارها تعطيك الميزات التي تريدها بالسعر الذي يناسبك، يُركّز هذا القسم بشكل أكبر على الميزات التي يجب أن يعلم بها مشترو شهادات SSL أكثر من الأسعار. عضويات برنامج الشهادات الجذرية Rootإنّ النقطة الأهم هي أن تكون سلطة الشهادات التي نختارها عضوًا في برامج الشهادات الجذريّة لأنظمة التشغيل ومتصفحات الويب الأكثر استخدامًا، أي بمعنى أن تكون سلطة شهادات موثوقة وشهادتها الجذريّة موثوقة من قبل معظم المتصفّحات والبرمجيات الأخرى، فإن كانت شهادة SSL لموقعنا مُوقَّعة من قبل سلطة شهادات موثوقة فستعتبر هويتها صالحة من قبل البرمجيّات التي تثق بسلطة الشهادات، وهي على النقيض تمامًا من شهادات SSL المُوقَّعة ذاتيًّا والتي تُزوّدنا أيضًا بقدرات التشفير ولكنّها مصحوبة بتحذيرات التحقّق من الهوية التي لا تسر معظم زوّار موقعنا. إنّ أغلب سلطات الشهادات التي سنصادفها هي عضو من برامج الشهادات الجذريّة الشائعة، وستكون متوافقة مع 99% من المتصفحات، ولكن لن يضرّنا أن نتحقّق من ذلك قبل شراء الشهادة، تزوّدنا شركة Apple على سبيل المثال بلائحة من شهادات SSL الجذريّة الموثوقة لأجل IOS8 هنا. أنواع الشهاداتيجب أن نتأكّد من اختيار سلطة شهادات تزوّدنا بنوع الشهادة الذي نريده، تُقدّم العديد من سلطات الشهادات أشكال مختلفة من أنواع الشهادات في إطار مجموعة من الأسماء والأسعار والتي كثيرًا ما تكون مربكة، وهذا وصف مختصر لكل نوع: نطاق مُفرَد Single Domain: يُستخدَم من أجل النطاق المُفرَد، مثل example.com، نلاحظ أنّه لا يتم تضمين النطاقات الفرعيّة subdomains مثل www.example.comWildcard: تُستخدَم من أجل النطاق وأي نطاقات فرعيّة له، على سبيل المثال يُمكِن استخدام شهادة wildcard لِـ *.example.com أيضًا من أجل www.example.com وstore.example.comالنطاقات المُتعدّدة Multiple Domain: وهي معروفة باسم شهادة SAN أو UC، ويمكن استخدامها مع النطاقات المُتعدّدة والنطاقات الفرعيّة التي تتم إضافتها إلى حقل الاسم البديل للموضوع Subject Alternative Name، فعلى سبيل المثال يُمكِن استخدام شهادة نطاقات متعدّدة مُفرَدة مع example.com، www.example.com، و example.netوبالإضافة لأنواع الشهادات المذكورة آنفًا تُوجَد مستويات مختلفة من التحقّق التي توفّرها سلطات الشهادات، وسنتحدّث عنها هنا: التحقّق من النطاق (Domain Validation (DV: يتم إصدار شهادات DV بعد أن تتحقّق سلطة الشهادات أنّ طالب الشهادة يملك أو يتحكّم بالنطاق المطلوب.التحقّق من المُنظّمة (Organization Validation (OV: يُمكِن إصدار شهادات OV فقط بعد أن تتحقّق سلطة الشهادات من الهوية القانونية لطالب الشهادة.التحقّق المُوسَّع (Extended Validation (EV: يُمكِن إصدار شهادات EV فقط بعد أن تتحقّق سلطة الشهادات من الهوية القانونيّة لطالب الشهادة مع عدّة أشياء أخرى وفق مجموعة صارمة من الإرشادات، إنّ الغرض من هذا النوع من الشهادات هو توفير ضمان إضافي عن قانونيّة هوية مُنظّمتك بالنسبة لزوّار موقعك، يُمكِن أن تكون شهادات EV مُفردة أو متعدّدة النطاقات ولكن لا يمكن أن تكون wildcard.ميزات إضافيةتوفّر العديد من سلطات الشهادات مجموعة كبيرة ومتنوعة من الميزات الإضافيّة لتمييز نفسها عن بقيّة بائعي شهادات SSL، بعض هذه الميزات قد توفّر عليك المال، لذا من المهم أن تعرف احتياجاتك مقابل العروض قبل أن تقوم بالشراء، على سبيل المثال تشمل الميزات التي يجب البحث عنها إعادة إصدار شهادة مجانيّة أو شهادة بسعر شهادة نطاق مُفرَد وتعمل من أجل www. والاسم الأساسي للنطاق، مثل www.example.com مع شهادة SAN من example.com الخاتمةتعلّمنا في هذا الدّرس المفاهيم الأساسيّة للحصول على شهادات SSL من سلطة شهادات تجاريّة، والمتطلّبات الأساسيّة التي نحتاجها قبل شرائها، وتحدّثنا عن العوامل التي يجب أن نأخذها بعين الاعتبار عند اختيار سلطة شهادات تجاريّة. ترجمة -وبتصرّف- لـ How To Install an SSL Certificate from a Commercial Certificate Authority لصاحبه Mitchell Anicas.

إن eCryptfs هو نظام ملفات للتشفير متوافق مع معايير POSIX ومن فئة الشركات لنظام لينُكس؛ وبتشكيل طبقة فوق طبقة نظام الملفات، فإن eCryptfs يحمي الملفات بغض النظر عن نظام الملفات المُستخدَم أو نوع القسم ...إلخ. هنالك خيار أثناء التثبيت لتشفير قسم ‎/home، هذا سيضبط تلقائيًا كل شيء يحتاج له النظام لتشفير ووصل ذاك القسم. سنشرح هنا طريقة الضبط لتشفير ‎/srv باستخدام eCryptfs. استخدام eCryptfsأولًا، ثبِّت الحزم اللازمة، بإدخال الأمر الآتي من الطرفية: sudo apt-get install ecryptfs-utilsالآن صِل القسم الذي تريد تشفيره: sudo mount -t ecryptfs /srv /srvستُسأل الآن عن بعض التفاصيل حول كيفية تشفير البيانات. لاختبار أن الملفات الموجودة في ‎/srv هي مشفرة، فانسخ المجلد ‎/etc/default إلى ‎/srv: sudo cp -r /etc/default /srvثم افصل القسم ‎/srv، وحاول عرض الملف: sudo umount /srv cat /srv/default/cronإعادة وصل ‎/srv باستخدام ecryptfs ستجعل البيانات قابلةً للعرض مرةً أخرى. وصل الأقسام المشفرة تلقائياهنالك طريقتان لوصل نظام ملفات مُشفَّر باستخدام ecryptfs أثناء الإقلاع؛ سيستخدم هذا المثال الملف ‎/root/.ecryptfsrc الذي يحتوي على خيارات الوصل، بالإضافة إلى ملف مرور موجود على قرص USB. أنشِئ أولًا الملف ‎/root/.ecryptfsrc الذي يحتوي على: key=passphrase:passphrase_passwd_file=/mnt/usb/passwd_file.txt ecryptfs_sig=5826dd62cf81c615 ecryptfs_cipher=aes ecryptfs_key_bytes=16 ecryptfs_passthrough=n ecryptfs_enable_filename_crypto=nملاحظة: عدِّل ecryptfs_sig إلى التوقيع في ‎/root/.ecryptfs/sig-cache.txt. ثم أنشِئ ملف المرور ‎/mnt/usb/passwd_file.txt: passphrase_passwd=[secrets]أضف الآن الأسطر الضرورية إلى ملف ‎/etc/fstab: /dev/sdb1 /mnt/usb ext3 ro 0 0 /srv /srv ecryptfs defaults 0 0تأكد أن قرص USB سيوصل قبل القسم المشفر. في النهاية، أعد الإقلاع ويجب أن يوصل ‎/srv باستخدام eCryptfs. أدوات أخرىالحزمة ecryptfs-utils تحتوي على أدواتٍ أخرى مفيدة: الأداة ecryptfs-setup-private تُنشِئ مجلد ‎~/Private الذي يحتوي على المعلومات المشفرة؛ يمكن تنفيذ هذه الأداة من المستخدمين العاديين للحفاظ على بياناتهم من المستخدمين الآخرين على النظام.الأداة ecryptfs-mount-private والأداة ecryptfs-umount-private ستصل أو تفصل مجلد ‎~/Private على التوالي وبالترتيب.ecryptfs-add-passphrase: إضافة عبارة مرور لما يسمى «kernel keyring».ecryptfs-manager: إدارة كائنات eCryptfs مثل المفاتيح.ecryptfs-stat: السماح لك بعرض معلومات eCryptfs الوصفية لملفٍ ما.مصادرللمزيد من المعلومات حول eCryptfs، راجع صفحة المشروع على Lanuchpad.هنالك مقالة في Linux Journal تشرح eCryptfs.للمزيد من خيارات eCryptfs، راجع صفحة الدليل man ecryptfs.لدى صفحة ويكي أوبنتو «eCryptfs» المزيد من التفاصيل.ترجمة -وبتصرف- للمقال Ubuntu Server Guide: eCryptfs.

واحدة من أكثر الأشكال الشائعة للتشفير في وقتنا الراهن هي التشفير وفق المفتاح العمومي (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.

عند إعداد خادوم ويب توجد غالبًا أقسام من الموقع نرغب بتقييد الوصول إليها، تُوفِّر تطبيقات الويب عادةً طرق التصريح authorization والاستيثاق authentication الخاصّة بها، ولكن يُمكِن استخدام خادوم الويب بذاته لتقييد الوصول إن كانت هذه الطّرق غير كافية أو غير متوفّرة. سنشرح في هذا الدّرس كيف نحمي الممتلكات assets باستخدام كلمة سر على خادوم ويب Nginx يعمل على Ubuntu. المتطلبات الأساسيةنحتاج للوصول إلى بيئة خادوم Ubuntu لكي نبدأ، نحتاج أيضًا لمستخدم غير جذري non-root مع صلاحيّات sudo من أجل تنفيذ مهام إداريّة administrative، لكي تتعلّم كيفيّة إعداد مستخدم بامتيازات sudo اتبع دليلنا للإعداد الأولي لخادوم Ubuntu 14.04. إن لم نقم مُسبقًا بتثبيت Nginx نستطيع تثبيته على جهازنا بكتابة ما يلي: sudo apt-get update sudo apt-get install nginxإنشاء ملف كلمات السرللبدء نحتاج لإنشاء الملف الذي سيحمل تركيبات أسماء المستخدمين وكلمات السّر، نستطيع فعل ذلك باستخدام أدوات OpenSSL المساعدة التي ربّما تكون متوفّرة مُسبقًا على خادومنا، وبشكلٍ بديل نستطيع استخدام الأداة المساعدة htpasswd المُصمّمة لهذا الغرض والمُضمّنة في الحِزمة apache2-utils (تستخدم ملفّات كلمات سر Nginx نفس الصّيغة التي تستخدمها Apache)، بإمكانك اختيار الطّريقة التي تفضّلها. إنشاء ملف كلمات السر باستخدام أدوات OpenSSL المساعدةإن كُنّا نملك OpenSSL مُثبتًا على خادومنا فبإمكاننا إنشاء ملف كلمات سر بدون أي حِزَم إضافيّة. سنقوم بإنشاء ملف مخفي يُدعى htpasswd. في دليل الإعدادات etc/nginx/ لتخزين تركيبات أسماء المستخدمين وكلمات السّر. نستطيع إضافة اسم مستخدم إلى هذا الملف باستخدام هذا الأمر، سنختار الاسم sammy ليكون اسم مستخدم لدينا، ولكن تستطيع استخدام أي اسم ترغب به: sudo sh -c "echo -n 'sammy:' >> /etc/nginx/.htpasswd"سنقوم بعد ذلك بإضافة كلمة سر مُشفّرة encrypted لاسم المستخدم بكتابة ما يلي: sudo sh -c "openssl passwd -apr1 >> /etc/nginx/.htpasswd"نستطيع إعادة هذه العمليّة من أجل أسماء مستخدمين آخرين، وبإمكاننا أن نرى كيف يتم تخزين أسماء المستخدمين وكلمات السّر المُشفّرة داخل الملف بكتابة ما يلي: cat /etc/nginx/.htpasswd sammy:$apr1$wI1/T0nB$jEKuTJHkTOOWkopnXqC1d1إنشاء ملف كلمات السر باستخدام الأدوات المساعدة لـ Apacheفي حين أنّ OpenSSL تستطيع تشفير كلمات السّر من أجل استيثاق Nginx، يجد معظم المستخدمين أنّه من الأسهل استخدام أداة مُساعِدة مبنيّة لهذا الغرض، تقوم الأداة المُساعِدة htpasswd الموجودة في الحزمة apache2-utils بتخديم هذا الأمر بشكل جيّد. نُثبِّت الحِزمة apache2-utils على خادومنا بكتابة ما يلي: sudo apt-get update sudo apt-get install apache2-utilsوالآن بعد أن أصبح بإمكاننا الوصول للأمر htpasswd نستطيع استخدامه لإنشاء ملف كلمات السّر الذي يستخدمه خادوم Nginx من أجل استيثاق المستخدمين، سنقوم بإنشاء ملف مخفي لهذا الغرض يُدعى htpasswd. بداخل دليل الإعدادات etc/nginx/. عند استخدام هذه الأداة لأوّل مرّة نحتاج لإضافة الخيار c- لإنشاء الملف المُحدَّد، نقوم بتحديد اسم مستخدم (في هذا المثال sammy) في نهاية الأمر لإنشاء مُدخَل جديد بداخل الملف: sudo htpasswd -c /etc/nginx/.htpasswd sammyسيتم سؤالنا عن تزويد كلمة سر وتأكيدها للمستخدم. نترك الوسيط c- لأي مستخدمين آخرين نرغب في إضافتهم: sudo htpasswd /etc/nginx/.htpasswd another_userإن قمنا بمشاهدة محتويات الملف نستطيع رؤية اسم المستخدم وكلمة السّر المُشفّرة لكل تسجيل record: cat /etc/nginx/.htpasswdsammy:$apr1$lzxsIfXG$tmCvCfb49vpPFwKGVsuYz. another_user:$apr1$p1E9MeAf$kiAhneUwr.MhAE2kKGYHK.إعداد استيثاق كلمة السر لخادوم Nginxالآن وبعد أن أصبحنا نمتلك ملف لأسماء المستخدمين وكلمات السّر في صيغة يستطيع خادوم Nginx قراءتها، نحتاج لإعداد Nginx لكي يتفحّص هذا الملف قبل تخديم محتوانا المحمي. نبدأ بفتح ملف إعدادات الحجب للخادوم والذي نرغب في إضافة تقييد restriction له، سنستخدم في مثالنا هذا ملف الخادوم الافتراضي default للحجب والمُثبَّت عبر حزمة Nginx في Ubuntu: sudo nano /etc/nginx/sites-enabled/defaultينبغي أن يبدو المحتوى داخل الملف مُشابِهًا لما يلي بعد إزالة التّعليقات: /etc/nginx/sites-enabled/default server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /usr/share/nginx/html; index index.html index.htm; server_name localhost; location / { try_files $uri $uri/ =404; } }نحتاج لإعداد الاستيثاق أن نقرّر السياق context الذي نريد تقييده، يسمح لنا Nginx من بين الخيارات الأخرى بتعيين التقييد على مستوى الخادوم أو بداخل موقع مُحدَّد، سنقوم في مثالنا بتقييد كامل المستند root بحجب على المكان، ولكن بإمكانك تعديل هذه القائمة لكي تستهدف فقط دليل مُحدَّد ضمن مجال الويب. نستخدم ضمن هذا الحجب على المكان الأمر التوجيهي auth_basic لتشغيل الاستيثاق واختيار اسم نطاق ليتم عرضه للمستخدم عند المطالبة بالاعتمادات credentials، سنستخدم الأمر التوجيهي auth_basic_user_file لكي يشير لخادوم Nginx إلى ملف كلمات السّر الذي أنشأناه: /etc/nginx/sites-enabled/default server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /usr/share/nginx/html; index index.html index.htm; server_name localhost; location / { try_files $uri $uri/ =404; auth_basic "Restricted Content"; auth_basic_user_file /etc/nginx/.htpasswd; } }بعد أن ننتهي نحفظ ونغلق الملف، نعيد تشغيل خادوم Nginx لتنفيذ سياسة policy كلمات السّر لدينا: sudo service nginx restartيجب أن يكون الدليل الذي حددناه محميًّا الآن بكلمة سر. تأكيد استيثاق كلمة السرللتأكّد من أنّ المحتوى محمي لدينا نُجرِّب النفاذ إلى المحتوى المُقيَّد من متصفّح إنترنت، يجب أن يتم عرض مُحث prompt لاسم المستخدم وكلمة السّر يُشبه ما يلي: إن أدخلنا الاعتمادات الصحيحة سيتم السماح لنا بالنفاذ إلى المحتوى، وإن أدخلنا الاعتمادات الخاطئة أو ضغطنا على إلغاء Cancel سنشاهد صفحة الخطأ "Authorization Required": الخاتمةيجب أن يكون لدينا الآن كل ما نحتاجه لإعداد استيثاق أساسي لموقعنا، فلنضع في اعتبارنا أنّ حماية كلمة السّر يجب أن تكون جنبًا إلى جنب مع تشفير SSL كي لا يتم إرسال اعتماداتنا إلى الخادوم في شكل نص مُجرَّد plain text، يمكنك الإطلاع أيضا على كيفيّة إنشاء شهادة SSL موقّعة ذاتيًّا لاستخدامها مع Nginx. ترجمة -وبتصرّف- للمقال: How To Set Up Password Authentication with Nginx on Ubuntu 14.04 لصاحبه Justin Ellingwood. حقوق الصورة البارزة: Designed by Freepik.

TLS، أو حماية طبقة النقل (Transport Layer Security)، وسلفها SSL أو طبقة الحِزَم الآمنة (Secure Sockets Layer) هما عبارة عن بروتوكولات آمنة يتم إنشاؤها بهدف توجيه تدفّق البيانات العادية (traffic) ضمن طريق مشفّر وآمن أثناء تنقّلها، وقد قمنا سابقا بشرح كيفية إعداد SSL على خادوم Apache، سنقوم في هذا الدرس بشرح كيفية إعداده مع خادوم nginx. باستخدام هذه التكنولوجيا، يمكن للخواديم أن تقوم بإرسال تدفّق البيانات بشكل آمن بينها وبين الزائر دون الحاجة إلى القلق بخصوص وجود إمكانية لاعتراض تدفّق البيانات بينها وقراءتها بواسطة شخص ما من الخارج. يساعد نظام الشهادات المستخدمين على التحقق من هوية المواقع التي يزورونها أيضًا. في هذا الدرس، سنشرح كيفيّة إنشاء شهادة SSL موقّعة ذاتيًا لخادوم Nginx على Ubuntu 14.04، لن تسمح الشهادة الموقّعة ذاتيًا لمستخدميك من أن يتحققوا من هوية موقعك بما أنّها ليست موقّعة بواسطة واحدة من الجهات التي يثق بها متصفّحك، ولكنّها ستسمح لك بتشفير الاتصالات مع زوّارك. المتطلباتقبل أن تبدأ، يجب أن تهتم ببعض الإعدادات بالطبع. سنستخدم مستخدمًا غير مستخدم الجذر مع صلاحيات sudo في هذا الدرس. يمكنك إعداد واحد عبر اتباع الخطوات المذكورة في درسنا حول إعداد خادوم أوبونتو 14.04 الابتدائي. ستحتاج أيضًا إلى تثبيت خادوم Nginx. إذا كنت تريد إعداد خادوم LEMP كامل (Linux, Nginx, MySQL, PHP) فإنّه يمكنك مراجعة درسنا حول تثبيت LEMP على أوبونتو 14.04. إذا كنت تريد خادوم Nginx فقط، فيمكنك تثبيته بواسطة: sudo apt-get update sudo apt-get install nginxالخطوة الأولى: إنشاء شهادة SSLفلنبدأ عبر إنشاء مسار فرعي ضمن مجلّد إعدادات خادوم Nginx لنضع ملفّات الشهادة التي سنقوم بإنشائها فيه: sudo mkdir /etc/nginx/sslوالآن وبعد أن قمنا بإنشاء ذلك المسار، يمكننا أن نقوم بإنشاء تلك الملفّات بأمر واحد وهو: sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/nginx/ssl/nginx.key -out /etc/nginx/ssl/nginx.crtسيتم سؤالك عدّة أسئلة. قبل أن نتعرّف عليها، فلنتعرّف على ما يعنيه الأمر السابق: openssl: هذا هو الأمر الأساسي الذي يتم توفيره بواسطة OpenSSL لإنشاء وإدارة الشهادات، المفاتيح وطلبات التوقيع.. إلخ.req: يحدد هذا الأمر الفرعي أننا نريد استخدام إدارة طلبات توقيع الشهادة X.509. X.509 هو عبارة عن معيار بنية تحتية للمفتاح العمومي يحتاجه كلٌّ من SSL وTLS لإدار الشهادات. نريد أن نقوم بإنشاء شهادة X.509 جديدة، ولذلك فإننا سنستخدم هذا الأمر الفرعي.x509-: يقوم هذا أيضًا بتعديل الأمر السابق عبر إخبار الأداة أننا نريد إنشاء شهادة موقّعة ذاتيًا عوضًا عن إنشاء طلب توقيع شهادة، والذي كان ليحدث بالحالة العادية.nodes-: يخبر هذا الخيار OpenSSL بأننا لا نريد تأمين ملفّ المفتاح الخاصّ بنا بجملة مرور، لأنّ استخدام هذا الخيار سيعترض طريق خادوم nginx عندما يتم تشغيله تلقائيًا حيث أنّه يجب علينا إدخال جملة المرور في كلّ مرّة يبدأ فيها الخادوم وفي كلّ مرّة يتم فيها إعادة تشغيله.days 365-: يحدد هذا أنّ الشهادة التي سنقوم بإنشائها صالحة لمدّة 365 يومًا.newkey rsa:2048-: سينشئ هذا الخيار طلب الشهادة ومفتاحًا خاصًّا جديدًا في الوقت ذاته. هذا ضروري جدًا بما أننا لم نقم بإنشاء مفتاح خاصّ مسبقًا. يقوم rsa:2048 بإخبار OpenSSL بأن يقوم بتوليد مفتاح RSA بطول 2048 بت.keyout-: يسمّي هذا المُعامِل الملفّ الناتج لملفّ المفتاح الخاصّ الذي يتم إنشاؤه.out-: يسمّي هذا الخيار ملفّ الشهادة الناتج الذي نقوم بإنشائه.كما وضّحنا أعلاه، ستقوم هذه الخيارات بإنشاء ملفّ مفتاح وشهادة. سيتم سؤالنا بضع أسئلة عن خادومنا بهدف تضمين المعلومات بشكل صحيح في تلك الشهادة. قم بكتابة الأجوبة بشكل صحيح، أهمّ واحد منها هو جواب ذاك السؤال الذي يسألك عن: "Common Name (e.g. server FQDN or YOUR name)". يجب أن تقوم بإدخال اسم نطاقك الذي تريد استخدامه مع خادومك، أو عنوان الـIP العام إذا كنتَ لا تمتلك نطاقًا بعد. أجوبة الأسئلة ستبدو شيئًا كهذا: Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:New York Locality Name (eg, city) []:New York City Organization Name (eg, company) [Internet Widgits Pty Ltd]:Bouncy Castles, Inc. Organizational Unit Name (eg, section) []:Ministry of Water Slides Common Name (e.g. server FQDN or YOUR name) []:your_domain.com Email Address []:admin@your_domain.comسيتم إنشاء الشهادة والمفتاح في مسار etc/nginx/ssl/. الخطوة الثانية: إعداد Nginx ليستخدم SSLالآن وبعد أن أصبح ملفّا الشهادة والمفتاح متوفّرين في مسار إعدادات Nginx، نحتاج الآن فقط إلى تعديل إعدادات خادوم Nginx الخاصّة بنا ليستفيد من التغييرات الجديدة. يمكنك تعلّم المزيد عن إعدادات خادوم Nginx من خلال قراءة تصنيف nginx على أكاديمية حسوب. يستطيع الإصدار 0.7.14 والأعلى منه من Nginx (تأتي أوبونتو 14.04 بالإصدار 1.4.6) أن يقوم بتفعيل SSL في نفس كتلة الخادوم (Server Block) كتدفّق HTTP عادي. يسمح لنا هذا بإعداد الوصول إلى نفس الموقع بطريقةٍ مختصرة بشكل أكبر. قد تبدو إعدادات الخادوم الخاصّة بك كالتالي: server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /usr/share/nginx/html; index index.html index.htm; server_name your_domain.com; location / { try_files $uri $uri/ =404; } }الشيء الوحيد الذي يجب علينا فعله لنجعل SSL تعمل على نفس الخادوم مع السماح باتصالات HTTP العادية هو إضافة السطور التالية: server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; listen 443 ssl; root /usr/share/nginx/html; index index.html index.htm; server_name your_domain.com; ssl_certificate /etc/nginx/ssl/nginx.crt; ssl_certificate_key /etc/nginx/ssl/nginx.key; location / { try_files $uri $uri/ =404; } }عندما تنتهي، احفظ الملفّ وأغلقه. الآن ستحتاج إلى إعادة تشغيل خادوم Nginx فقط لكي تأخذ التغييرات مجراها: sudo service nginx restartسيقوم هذا بإعادة تحميل إعدادات موقعك، وسيصبح قادرًا على الاستجابة إلى كل من طلبات HTTP وHTTPS. الخطوة الرابعة: اختبر إعداداتكيجب الآن أن تعمل وظيفة SSL بشكلٍ جيّد معك، ولكن يجب علينا اختبارها لنتأكّد من ذلك. أولًا، دعنا نتحقق أنّه ما يزال بإمكاننا الوصول إلى الموقع عبر بروتوكول HTTP العادي. في متصفّحك، قم بزيارة اسم نطاق الخادوم الخاصّ بك أو عنوان الـIP: http://اسم_النطاق_أو_عنوان_الآي_بييجب أن ترى الموقع العادي. في حالتي، سأرى رسالة Nginx الافتراضية فقط: إذا وصلت إلى هذه الصفحة، فهذا يعني أنّ خادومك ما يزال يخدم طلبات HTTP بشكل صحيح. الآن يمكننا التحقق مما إذا كان خادومنا قادرًا على استخدام SSL للتواصل أم لا. قم بذلك عبر كتابة بروتوكول https عوضًا عن http: https://اسم_النطاق_أو_عنوان_الآي_بيسترى رسالة تنبيه أن متصفّحك لم يتمكّن من التحقق من هوية خادومك لأنّه لم يتم توقيع الشهادة الخاصّة به من قبل جهة من الجهات التي يثق بها ذلك المتصفّح. هذه رسالة متوقّعة بمّا أنّ شهادتنا هي شهادة موقّعة ذاتيًا (self-signed). صحيح أّنّه لن يكون من الممكن استخدام شهادتنا للتحقق من هوية خادومنا، إلّا أنّ الخادوم سيزال قادرا على التواصل المشفّر. بمّا أنّ هذه الرسالة هي رسالة متوقّعة، فيمكنك الضغط على زرّ "المتابعة على كلّ حال" أو "Proceed anyway" أو أيّ خيار مشابه تجده أمامك للمتابعة. يجب أن ترى صفحة موقعك مجددًا: قد يظهر لك متصفّحك اسم بروتوكول "https" مشطوبًا في شريط العنوان أو محطّمًا أو بجانبه إشارة قفل مشطوبة. إذا ضغطت على أيقونة القفل، ستجد بعض المعلومات عن الاتصال: كما يمكنك أن ترى، المشكلة هي أنّ المتصفّح غير قادر على التحقق من هوية الخادوم بسبب أنّ شهادته ليست موقّعة من جهة إصدارات شهادات موثوقة بالنسبة إلى المتصفّح لا أكثر. يُظهر لك القسم الذي بالمنتصف أنّ الاتصال مشفّر، وهذا يعني أننا حققنا هدفنا على كلّ حال. الخاتمةلقد قمتَ الآن بإعداد خادوم Nginx الخاصّ بك ليعالج كلًّا من طلبات HTTP وSSL. سيساعدك هذا على التواصل مع زوّارك بشكل أأمن بالإضافة إلى جعل الجهات الخارجية غير قادرة على قراءة تدفّق البيانات الخاصّ بك. إذا كنتَ تخطط لإطلاق موقعٍ للعموم وتحتاج SSL، فإنّه يجب عليك شراء شهادة SSL من جهة شهادات موثوقة لموقعك لتجنّب ظهور رسالة التحذير الصفراء لزوّاك موقعك. ترجمة -وبتصرف- للمقال: How To Create an SSL Certificate on Nginx for Ubuntu 14.04 لصاحبه: Justin Ellingwood. حقوق الصورة البارزة: Designed by Freepik.

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