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

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

Let’s Encrypt هي سلطة شهادات مفتوحة ومؤتمتة تستعمل بروتوكول ACME ‏(Automatic Certificate Management Environment) لتوفير شهادات TLS/SSL مجانية لأي عميل يحقق الشروط المطلوبة، وتلك الشهادات يمكن أن تستعمل لتشفير الاتصالات بين خادوم الويب وزوار موقعك. هنالك الكثير من العملاء المتاحة لبروتوكول ACME المكتوبة بمختلف لغات البرمجة، مع قدرة على الدمج مع أدوات الإدارة والخدمات والخواديم الشهيرة. أشهر عميل ACME باسم Certbot يُطوَّر حاليًا من Electronic Frontier Foundation. ويمكن لعميل Certbot ضبط تشفير TLS/SSL في خودايم أباتشي و Nginx إضافةً إلى التحقق من ملكية النطاق والحصول على الشهادات. سيشرح هذا الدرس سلطات الشهادات باختصار وكيف تعمل خدمة Let’s Encrypt، ثم سنتحدث عن بعض عملاء ACME. ما هي سلطة الشهادات؟ سلطات الشهادات (certificate authorities اختصارًا CAs) هي الجهات التي توقِّع شهادات TLS/SSL رقميًا لضمان وكفالة موثوقيتها. إذ تملك المتصفحات وأنظمة التشغيل قائمةً بسلطات الشهادات الموثوقة التي يمكن استعمالها للتحقق من شهادات أحد المواقع. حتى وقتٍ قريب، كانت أغلبية سلطات الشهادات خاضعة لشركات تجارية والتي تتقاضى أموالًا للحصول على خدمات توقيع الشهادات، لكن أتت خدمة Let’s Encrypt وجعلت هذه العملية مجانية للمستخدمين عبر أتمتة العملية كليًّا، وبالاعتماد على نظام الرعاية والمساهمات المالية لتمويل البنية التحتية اللازمة لتشغيل مثل هذه الخدمة. لمزيدٍ من المعلومات حول الشهادات والأنواع المختلفة من سلطات الشهادات، فاقرأ مقالة A Comparison of Let’s Encrypt, Commercial and Private Certificate Authorities, and Self-Signed SSL Certificates. كيف تعمل خدمة Let’s Encrypt بروتوكول ACME يُعرِّف كيفية تواصل العملاء مع الخواديم لطلب الشهادات والتحقق من ملكية النطاقات وتنزيل الشهادات، وهذا البروتوكول في صدد تحويله إلى معيار IETF رسمي. توفِّر خدمة Let’s Encrypt شهادات لنطاقات موثوقة، وهذا يعني أنَّها ستتحقق أنَّ الشهادة تأتي من شخصٍ يتحكم فعليًا بالنطاق، وذلك عبر إرسال العميل لرمز فريد (unique token) ثم إجراء طلبية ويب أو DNS للحصول على مفتاح مأخوذ من ذاك الرمز. على سبيل المثال، لو كنا سنجري تحقق عبر HTTP، فسيحسب العميل المفتاح من الرمز الفريد (unique token) ورمز الحساب (account token)، ثم يضع الناتج في ملف مُخدَّم من خادوم الويب، ثم يمكن لخواديم Let’s Encrypt أن تنزِّل الملف الموجود في المسار http://example.com/.well-known/acme-challenge/token فإذا كان المفتاح صحيحًا، فهذا يعني أن العميل قادرٌ على التحكم بالموارد الموجودة في النطاق example.com وبالتالي سيوقِّع الخادوم الشهادة ويتيحها للعميل. يُعرِّف بروتوكول ACME عدِّة طرائق للتحقق أنَّ العميل يملك النطاق، فاختبار HTTPS شبيه باختبار HTTP، لكن بدلًا من استخدام ملف نصي فسيوفِّر العميل شهادة موقعة ذاتيًا وفيها مفتاح التحقق. أما التحقق عبر DNS فيتم عبر وضع المفتاح في سجل DNS TXT. عميل Certbot Certbot هو أشهر عميل Let’s Encrypt، وهو متوافر في أغلبية توزيعات لينكس ويتضمن القدرة على الضبط التلقائي لخادومَي أباتشي و Nginx. يمكنك الحصول على الشهادة وتحديث ضبط أباتشي بتنفيذ الأمر الآتي بعد تثبيت عميل Certbot: sudo certbot --apache -d www.example.com سيسألك Certbot بعض الأسئلة ثم يجري عملية التحقق وينزِّل الشهادات ويُحدِّث ضبط أباتشي ويعيد تحميل الخادوم، ويمكنك بعد ذلك أن تنتقل إلى https://www.example.com في متصفح الويب الخاص بك وستشاهد القفل الأخضر مشيرًا إلى أنَّ الشهادة صحيحة والاتصال مشفّر. ولأن شهادات Let’s Encrypt صالحة لتسعين يومًا فقط، فمن المهم ضبط عملية تجديد مؤتمة. الأمر الآتي سيُجدِّد كل الشهادات الموجودة على الحاسوب: sudo certbot renew ضع الأمر السابق في جدول cron وشغِّله يوميًا، وستُجدَّد الشهادات تلقائيًا قبل ثلاثين يومًا من انتهاء صلاحيتها، وإذا أُنشِئَت الشهادة بادئ الأمر مع أحد الخيارين ‎--apache أو ‎--nginx فسيعيد Certbot تحميل الخادوم بعد نجاح عملية التجديد. إذا أردتَ معرفة المزيد من المعلومات حول جداول cron فأحيلك إلى درس كيف نستخدم المهام المجدولة باستخدامCron في أنظمة لينكس ويونكس. عملاء آخرين لأن بروتوكول ACME مفتوح وموثّق جيدًا، فقد طوِّرَ الكثير من العملاء البديلين، وهنالك قائمة بعملاء ACME في موقع Let’s Encrypt، وأغلبية العملاء لا يملكون ميزة ضبط خادوم الويب تلقائيًا التي يملكها Certbot لكن هنالك ميزات أخرى لها قد تجذبك: - هنالك عميل مكتوب بكل لغات البرمجة تقريبًا، بما في ذلك سكربتات الصدفة (shell scripts) ولغة Go و Node.js، وقد تستفيد من ذلك إن كنتَ تُنشِئ شهادات في بيئة مغلقة لا يمكن تضمين بايثون فيها ولا بقية اعتماديات Certbot. - بعض العملاء يمكن أن يعملوا دون امتيازات الجذر، فمن المستحسن تقليل كمية الشيفرات التي تعمل بامتيازات الجذر إلى أقل قدر ممكن. - الكثير من العملاء يمكنها أتمتة عملية التحقق عبر DNS عبر استخدام الواجهة البرمجية المناسبة لموفِّر خدمة DNS لإنشاء سجلات TXT تلقائيًا، والتحقق عبر DNS يسمح بتوليد شهادات لحالات الاستخدام الغريبة مثل تشفير خواديم الويب التي لا يمكن للعموم الوصول إليها. - بعض العملاء يمكن أن يندمج مع خودايم الويب أو الخواديم الوسيطة (proxy) العكسية، أو موزّعات الحِمل (load balancers) مما يسهِّل عملية الضبط والتشغيل. بعض أشهر تلك العملاء: - lego المكتوب بلغة Go، والذي يُثبَّت عبر ملفٍ ثنائيٍ وحيد، والذي يدعم عدد من مزودي خدمة DNS لتسهيل التحقق عبر DNS. - acme.sh وهو سكربت صدفة بسيط يمكن أن يعمل دون امتيازات الجذر، ويستطيع أن يتواصل مع أكثر من 30 مزودًا لخدمة DNS. - Caddy وهو خادوم ويب كامل مكتوب بلغة Go والذي يملك دعمًا مدمجًا فيه لخدمة Let’s Encrypt. يتوافر الكثير من العملاء، وأصبحت العديد من الخدمات والخواديم تؤتمت عملية إعداد TLS/SSL بدعم خدمة Let’s Encrypt فيها. الخلاصة لقد شرحنا أساسيات عمل خدمة Let’s Encrypt، وناقشنا أشهر العملاء المتوافرين، وإذا أردتَ معرفة كيفية إعداد هذه الخدمة مع بقية البرمجيات فأنصحك بالاطلاع على درس تنصيب شهادة SSL مجانية عبر خدمة Let’s encrypt على خادوم لينكس. ترجمة –وبتصرّف– للمقال An Introduction to Let’s Encrypt لصاحبه Brian Boucheron

تمهيد إنَّ 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.

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

تعرفنا في الدرس السابق على كيفية تثبيت وضبط خادوم openldap على أوبنتو، سنتعرف في هذا الدرس على التناسخ في خادوم OpenLDAP. التناسختتزايد أهمية خدمة LDAP عندما تزداد أنظمة الشبكات المُعتَمِدة عليها؛ تكون الممارسات العملية القياسية -في مثل هذه البيئة- هي بناء redundancy في LDAP لمنع توقف الخدمات إذا لم يعد يستجيب خادوم LDAP؛ يتم ذلك باستخدام تناسخ LDAP؛ نصل إلى التناسخ باستخدام محرك Syncrepl؛ الذي يسمح بمزامنة التغيرات باستخدام موديل «مستهلك-مزود»؛ نوع التناسخ الذي سنستخدمه في هذا الدرس هو دمج للنوعين الآتيين: refreshAndPersist، و delta-syncrepl؛ الذي يُرسِل فيه المزود القيود إلى المستهلك عند إنشائهم مباشرةً؛ بالإضافة إلى أنه لا تُرسَل جميع القيود، وإنما التغيرات التي حصلت فقط. ضبط المزودسنبدأ بضبط المزود (Provider) أنشِئ ملف LDIF بالمحتويات الآتية وسمِّه provider_sync.ldif: # Add indexes to the frontend db. dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: entryCSN eq - add: olcDbIndex olcDbIndex: entryUUID eq #Load the syncprov and accesslog modules. dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov - add: olcModuleLoad olcModuleLoad: accesslog # Accesslog database definitions dn: olcDatabase={2}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcRootDN: cn=admin,dc=example,dc=com olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart # Accesslog db syncprov. dn: olcOverlay=syncprov,olcDatabase={2}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE # syncrepl Provider for primary db dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE # accesslog overlay definitions for primary db dn: olcOverlay=accesslog,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogSuccess: TRUE # scan the accesslog DB every day, and purge entries older than 7 days olcAccessLogPurge: 07+00:00 01+00:00غيّر قيمة rootDN في ملف LDIF ليُطابِق الذي عندك في الدليل. لا يجب تعديل إعدادات apparmor لبرمجية slapd لتحديد موقع قاعدة بيانات accesslog، لأن الملف ‎/etc/apparmor/local/usr.sbin.slapd يحتوي على الأسطر الآتية: /var/lib/ldap/accesslog/ r, /var/lib/ldap/accesslog/** rwk,أنشِئ مجلدًا، وهيّء ملف ضبط قاعدة البيانات، وأعد تحميل apparmor: sudo -u openldap mkdir /var/lib/ldap/accesslog sudo -u openldap cp /var/lib/ldap/DB_CONFIG /var/lib/ldap/accesslog sudo service apparmor reloadأضف المحتويات الجديدة؛ وأعد تشغيل العفريت بسبب التعديل في apparmor: sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f provider_sync.ldif sudo service slapd restartلقد ضُبِطَ المزود بنجاح. ضبط المستهلكعليك الآن ضبط المستهلك. تثبيت البرمجية باتباع تعليمات قسم «التثبيت»؛ وتأكد أن قاعدة بيانات slapd-config مماثلة للمزود؛ وتحديدًا تأكد من أن المخططات ولاحقة قاعدة البيانات هي نفسها. أنشِئ ملف LDIF بالمحتويات الآتية وسمِّه consumer_sync.ldif: dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: entryUUID eq - add: olcSyncRepl olcSyncRepl: rid=0 provider=ldap://ldap01.example.com bindmethod=simple binddn="cn=admin,dc=exa credentials=secret searchbase="dc=example,dc=com" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog - add: olcUpdateRef olcUpdateRef: ldap://ldap01.example.comتأكد أن قيم الخاصيات الآتية صحيحة: provider (اسم مضيف المزود –ldap01.example.com في هذا المثال– أو عنوان IP).binddn (الاسم الفريد للمدير الذي تستخدمه).credentials (كلمة مرور المدير الذي تستخدمه).searchbase (لاحقة قاعدة البيانات التي تستخدمها).olcUpdateRef (اسم مضيف أو عنوان IP لخادوم المزود).rid عدد من ثلاثة أرقام يعرف النسخة، يجب أن يكون لكل مستهلك رقم rid واحد على الأقل).أضف المحتويات الجديدة: sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f consumer_sync.ldifلقد انتهيت، يجب أن يبدأ الآن تزامن قاعدتَيّ البيانات (ذاتَيّ اللاحقة dc=example,dc=com). الاختباربعد بدء الاستنساخ، تستطيع مراقبته بتشغيل الأمر: ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base contextCSN dn: dc=example,dc=com contextCSN: 20120201193408.178454Z#000000#000#000000عندما تتوافق المخرجات في المزود والمستهلك (20120201193408.178454Z#000000#000#000000 في المثال السابق) في كلا الجهازين؛ فستكون عملية الاستنساخ قد تمَّت؛ وفي كل مرة يُجرى فيها تعديل في المزود، فإن القيمة ستُعدَّل وكذلك يجب أن تُعدَّل قيمة ناتج الأمر السابق في المستهلك أو المستهلكين. إذا كان اتصالك ضعيفًا، أو كان حجم قاعدة بيانات ldap كبيرًا، فربما يحتاج contextCSN في المستهلك وقتًا ليطابق مثيله في المزود؛ لكنك تعلم أن العملية قيد الإجراء لأن contextCSN في المستهلك يزداد مع الزمن. إذا كان contextCSN في المستهلك مفقودًا، أو كان لا يطابق المزود؛ فعليك إيقاف العملية والبحث عن سبب المشكلة قبل الإكمال، جرب التحقق من سجلات slapd‏ (syslog) وملفات auth في المزود للتأكد فيما إذا كانت طلبات الاستيثاق من المستهلك قد نجحت أم لا؛ وفيما إذا أعادت طلبياته للحصول على بيانات (ستشبه عبارات ldapsearch كثيرًا) أيّة أخطاء. لاختبار إذا كان يعمل؛ جرب طلب DN في قاعدة البيانات في المستهلك: sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b dc=example,dc=com dnيجب أن تشاهد المستخدم «john» والمجموعة «miners» بالإضافة إلى عقدتَيّ «People» و «Groups». التحكم في الوصولإدارة أي نوع من الوصول (قراءة، أو كتابة ...إلخ.) التي يجب أن يحصل عليها المستخدمون للموارد تدعى «التحكم في الوصول» (access control)؛ تعليمات الضبط المستخدمة تسمى «قوائم التحكم في الوصول» (access control lists) أو ACL. عندما نُثبِّت حزمة slapd، فستُضبَط قوائم مختلفة للتحكم في الوصول؛ سنلقي نظرةً على بعض نتائج هذه القيم الافتراضية؛ وسنحصل بذلك على فكرة عن كيفية عمل قوائم التحكم بالوصول وكيفية ضبطها. لكي نحصل على ACL فعال لطلبية LDAP، فسنحتاج إلى أن ننظر إلى سجلات قوائم التحكم بالوصول لقاعدة البيانات التي تُجرى الطلبيات عليها، بالإضافة إلى واجهة أمامية (frontend) خاصة لقاعدة البيانات؛ قوائم التحكم بالوصول المتعلقة بالنقطة الأخيرة تسلك سلوكًا افتراضيًا في حالة لم تتطابق النقطة الأولى؛ الواجهة الأمامية لقاعدة البيانات هي ثاني ما «تنظر» إليه قوائم التحكم بالوصول؛ وأول ما ستُطبِّقه قوائم التحكم بالوصول هو أول ما سُيطابَق («first match wins») بين مصدرَيّ قوائم التحكم بالوصول السابقَين؛ ستعطي الأوامر الآتية، على التوالي وبالترتيب، قيم ACL لقاعدة بيانات hdb ‏(«dc=example,dc=com») والقيم المتعلقة بالواجهة الأمامية لقاعدة البيانات: sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcDatabase={1}hdb)' olcAccess dn: olcDatabase={1}hdb,cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=example,dc=com" write by * none lcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by self write by dn="cn=admin,dc=example,dc=com" write by * readملاحظة: يملك rootDN دائمًا جميع الحقوق لقاعدة بياناته؛ تضمينها في قوائم التحكم بالوصول يوفر توضيحًا للضبط؛ لكنه يؤدي إلى تخفيض في أداء slapd. sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcDatabase={-1}frontend)' olcAccess dn: olcDatabase={-1}frontend,cn=config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred, cn=external,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=Subschema" by * readأول قائمة تحكم بالوصول هي مهمة ومحورية: olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=example,dc=com" write by * noneيمكن أن يعبر عنها بطريقة أخرى لتسهيل فهمها: to attrs=userPassword by self write by anonymous auth by dn="cn=admin,dc=example,dc=com" write by * none to attrs=shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=example,dc=com" write by * noneتركيبة قوائم التحكم بالوصول (هنالك قاعدتين) تجبر ما يلي: الوصول المجهول 'auth' موفر إلى خاصية userPassword لكي يتم الاتصال الابتدائي؛ ربما هذا عكس البديهي، نحتاج إلى 'by anonymous auth' حتى لو لم نكن نريد الوصول المجهول إلى شجرة بيانات الدليل. بعد أن تتصل النهاية البعيدة، فعندها يمكن أن يقع الاستيثاق (انظر النقطة الآتية).يمكن أن يحدث الاستيثاق لأن جميع المستخدمين لديهم وصول 'read' (بسبب 'by self write') لخاصية userPassword.عدا ذلك، فلا يمكن الوصول إلى خاصية userPassword من أي مستخدمين آخرين؛ مع استثناء rootDN، الذي يملك وصولًا كاملًا إليها.لكي يغير المستخدمون كلمات مرورهم، باستخدام passwd أو غيرها من الأدوات، فإن خاصية shadowLastChange يجب أن تكون متاحةً بعد الاستيثاق من المستخدم.يمكن البحث في شجرة DIT السابقة بسبب 'by * read' في: to * by self write by dn="cn=admin,dc=example,dc=com" write by * readإذا لم يكن هذا مرغوبًا فعليك تعديل ACL؛ ولكي يكون الاستيثاق جبريًا أثناء طلب bind، فيمكنك بشكل بديل (أو بالمشاركة مع ACL المعدلة) استخدام التعليمة 'olcRequire: authc'. وكما ذُكِر سابقًا، لا يوجد حساب إدارة مُنشَأ لقاعدة بيانات slapd-config. لكن هنالك هوية SASL التي تملك الوصول الكامل إليها؛ والتي تمثل root أو sudo؛ ها هي ذا: dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=authسيعرض الأمر الآتي قوائم التحكم بالوصول (ACLs) لقاعدة بيانات slapd-config: sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcDatabase={0}config)' olcAccess dn: olcDatabase={0}config,cn=config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred, cn=external,cn=auth manage by * breakولما كانت هذه هوية SASL، فإننا نحتاج إلى استخدام آلية SASL عندما نستخدم أداة LDAP كما رأينا ذلك للعديد من المرات في هذا الكتاب؛ هذه الآلية خارجية؛ انظر إلى الأمر السابق كمثال، لاحظ أنه: يجب أن تستخدم sudo لكي تصبح بهوية الجذر لكي تطابق قوائم التحكم بالوصول.الآلية الخارجية (EXTERNAL) تعمل باستخدام IPC (مقابل نطاقات UNIX) الذي يعني أنه عليك استخدام صيغة ldapi URI.طريقة موجزة للحصول على جميع قوائم التحكم بالوصول: sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcAccess=*)' olcAccess olcSuffixهنالك المزيد من الأمور التي يجب الحديث عنها في موضوع التحكم في الوصول؛ راجع صفحة الدليل man slapd.access. TLSعند الاستيثاق لخادوم OpenLDAP فمن الأفضل استخدام جلسة مشفرة؛ ويمكن أن يتم ذلك باستخدام أمن طبقة النقل (Transport Layer Security‏ [TLS]). هنا، سنكون «سلطة الشهادة» (Certificate Authority) الخاصة بنا وبعدها سنُنشِئ ونوقع شهادة خادوم LDAP؛ ولما كان slapd مُصَرَّفًا بمكتبة gnutls، فسنستخدم الأداة certtool لإكمال هذه المهام. ثبت حزمتَيّ gnutls-bin و ssl-cert: sudo apt-get install gnutls-bin ssl-certأنشِئ مفتاحًا خاصًا لسلطة الشهادة: sudo sh -c "certtool --generate-privkey > /etc/ssl/private/cakey.pem"أنشئ الملف/القالب ‎/etc/ssl/ca.info لتعريف سلطة الشهادة: cn = Example Company ca cert_signing_keyأنشِئ شهادة سلطة شهادات موقعة ذاتيًا: sudo certtool --generate-self-signed \ --load-privkey /etc/ssl/private/cakey.pem \ --template /etc/ssl/ca.info \ --outfile /etc/ssl/certs/cacert.pemاصنع مفتاحًا خاصًا للخادوم: sudo certtool --generate-privkey \ --bits 1024 \ --outfile /etc/ssl/private/ldap01_slapd_key.pemملاحظة: استبدل ldap01 في اسم الملف باسم مضيف خادومك؛ ستساعدك تسمية الشهادة والمفتاح للمضيف والخدمة التي تستخدمها في توضيح الأمور. أنشئ ملف المعلومات ‎/etc/ssl/ldap01.info الذي يحتوي: organization = Example Company cn = ldap01.example.com tls_www_server encryption_key signing_key expiration_days = 3650الشهادة السابقة صالحة لعشرة أعوام، عدِّل هذه القيمة وفقًا لمتطلباتك. أنشِئ شهادة الخادوم: sudo certtool --generate-certificate \ --load-privkey /etc/ssl/private/ldap01_slapd_key.pem \ --load-ca-certificate /etc/ssl/certs/cacert.pem \ --load-ca-privkey /etc/ssl/private/cakey.pem \ --template /etc/ssl/ldap01.info \ --outfile /etc/ssl/certs/ldap01_slapd_cert.pemأنشئ الملف certinfo.ldif بالمحتويات الآتية (عدلها وفقًا لمتطلباتك؛ حيث اعتبرت أمثلتنا أن الشهادات مُنشَأة باستخدام https://www.cacert.org): dn: cn=config add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/ldap01_slapd_cert.pem - add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/ldap01_slapd_key.pemاستخدم الأمر ldapmodify لإخبار slapd عن عمل TLS عبر قاعدة بيانات slapd-config: sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /etc/ssl/certinfo.ldifوعلى النقيض من الاعتقاد الشائع؛ لا تحتاج إلى استخدام ldaps‎://‎ في ‎/etc/default/slapd لكي تستخدم التشفير، كل ما عليك امتلاكه هو: SLAPD_SERVICES="ldap:/// ldapi:///"ملاحظة: أصبح LDAP عبر TLS/SSL‏ (dlaps://‎) مهجورًا لتفضيل StartTLS، يشير الأخير إلى جلسة LDAP (تستمع على منفذ TCP ذي الرقم 389) التي تصبح محميةً بواسطة TLS/SSl؛ حيث LDAPS -مثل HTTPS- هو بروتوكول منفصل مشفر منذ البداية (encrypted-from-the-start) الذي يعمل على منفذ TCP ذي الرقم 636. اضبط الملكية والأذونات: sudo adduser openldap ssl-cert sudo chgrp ssl-cert /etc/ssl/private/ldap01_slapd_key.pem sudo chmod g+r /etc/ssl/private/ldap01_slapd_key.pem sudo chmod o-r /etc/ssl/private/ldap01_slapd_key.pemأعد تشغيل خدمة OpenLDAP: sudo service slapd restartتحقق من سجلات المضيف (‎/var/log/syslog) لترى إن بدأ تشغيل الخادوم بنجاح. التناسخ و TLSإذا ضبَطت التناسخ بين الخواديم، فمن الممارسات الشائعة هي تشفير (StartTLS) بيانات النسخ المارة في الشبكة لتفادي التنصت عليها؛ وهذا منفصل عن استخدام التشفير والاستيثاق كما فعلنا سابقًا؛ سنبني في هذا القسم على استيثاق TLS. سنفترض هنا أنك ضبطت الاستنساخ بين المزود والمستهلك وفقًا للقسم «التناسخ»؛ وضبطت TLS للاستيثاق في المزود وفقًا للقسم «TLS». وكما ذكر سابقًا؛ هدف التناسخ (بالنسبة لنا) هو أن تكون خدمة LDAP ذات إتاحية كبيرةً؛ ولمّا كنا نستخدم TLS للاستيثاق في المزود فإننا نحتاج إلى نفس الأمر في المستهلك؛ بالإضافة إلى ذلك، نريد أن تكون بيانات الاستنساخ المنقولة مشفرةً، وما بقي ليُفعَل هو إنشاء مفتاح وشهادة للمستهلك ثم الضبط وفقًا لذلك، وسنولد المفتاح/الشهادة في المزود؛ لكي نتجنب إنشاء شهادة أخرى لسلطة الشهادات، ثم سننقل ما يلزمنا إلى المستهلك. في المزود: أنشِئ مجلدًا (الذي سيستخدم في النقل النهائي)، ثم ولِّد مفتاح المستهلك الخاص: mkdir ldap02-ssl cd ldap02-ssl sudo certtool --generate-privkey \ --bits 1024 \ --outfile ldap02_slapd_key.pemأنشئ ملف المعلومات ldap02.info للخادوم المستهلك، وعدِّل قيمه وفقًا لمتطلباتك: organization = Example Company cn = ldap02.example.com tls_www_server encryption_key signing_key expiration_days = 3650أنشِئ شهادة المستهلك: sudo certtool --generate-certificate \ --load-privkey ldap02_slapd_key.pem \ --load-ca-certificate /etc/ssl/certs/cacert.pem \ --load-ca-privkey /etc/ssl/private/cakey.pem \ --template ldap02.info \ --outfile ldap02_slapd_cert.pemاحصل على نسخة من شهادة سلطة الشهادات: cp /etc/ssl/certs/cacert.pem .لقد انتهينا الآن، انقل مجلد ldap02-ssl إلى المستهلك؛ حيث استخدمنا هنا scp (عدّل الأمر وفقًا لمتطلباتك): cd .. scp -r ldap02-ssl user@consumer:في المستهلك: ضبط استيثاق TLS: sudo apt-get install ssl-cert sudo adduser openldap ssl-cert sudo cp ldap02_slapd_cert.pem cacert.pem /etc/ssl/certs sudo cp ldap02_slapd_key.pem /etc/ssl/private sudo chgrp ssl-cert /etc/ssl/private/ldap02_slapd_key.pem sudo chmod g+r /etc/ssl/private/ldap02_slapd_key.pem sudo chmod o-r /etc/ssl/private/ldap02_slapd_key.pemأنشئ الملف ‎/etc/ssl/certinfo.ldif وفيه المحتويات الآتية (عدِّلها وفقًا لمتطلباتك): dn: cn=config add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/ldap02_slapd_cert.pem - add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/ldap02_slapd_key.pemاضبط قاعدة بيانات slapd-config: sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f certinfo.ldifاضبط ‎/etc/default/slapd في المزود (SLAPD_SERVICES). في المستهلك: اضبط TLS للتناسخ من جهة المستهلك، وعدِّل خاصية olcSyncrepl الموجودة مسبقًا بتتبع بعض خيارات TLS؛ وبفعل ذلك، سنرى للمرة الأولى كيف نعدل قيمة خاصية ما. أنشئ الملف consumer_sync_tls.ldif بالمحتويات الآتية: dn: olcDatabase={1}hdb,cn=config replace: olcSyncRepl olcSyncRepl: rid=0 provider=ldap://ldap01.example.com bindmethod=simple binddn="cn=admin,dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog starttls=critical tls_reqcert=demandالخيارات الإضافية تحدد، على التوالي وبالترتيب، أن على المستهلك استخدام StartTLS وأن شهادة CA مطلوبةٌ للتحقق من هوية المزود، ولاحظ أيضًا صيغة LDIF لتعديل قيم خاصية ما ('replace'). نفِّذ هذه التعديلات: sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f consumer_sync_tls.ldifثم أعد تشغيل slapd: sudo service slapd restartعلى المزود: تأكد من أن جلسة TLS قد بدأت؛ وذلك عبر السجل ‎/var/log/syslog، بافتراض أنك أعدت مستوى التسجيل إلى 'conns'، وعليه سترى رسائل شبيهة بالآتي: slapd[3620]: conn=1047 fd=20 ACCEPT from IP=10.153.107.229:57922 (IP=0.0.0.0:389) slapd[3620]: conn=1047 op=0 EXT oid=1.3.6.1.4.1.1466.20037 slapd[3620]: conn=1047 op=0 STARTTLS slapd[3620]: conn=1047 op=0 RESULT oid= err=0 text= slapd[3620]: conn=1047 fd=20 TLS established tls_ssf=128 ssf=128 slapd[3620]: conn=1047 op=1 BIND dn="cn=admin,dc=example,dc=com" method=128 slapd[3620]: conn=1047 op=1 BIND dn="cn=admin,dc=example,dc=com" mech=SIMPLE ssf=0 slapd[3620]: conn=1047 op=1 RESULT tag=97 err=0 textترجمة -وبتصرف- للمقال Ubuntu Server Guide: OpenLDAP Server.