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

هذا هو الجزء الأخير من سلسلة “مدخل إلى إطار العمل Ruby on Rails” وفي هذا الجزء سنعيد هيكلة الشيفرة التي كتبناها في الأجزاء السابقة من السلسلة، وسنتعرّف إلى نظام الاستيثاق البسيط الذي يقدّمه إطار العمل Rails. إعادة هيكلة الشيفرة بعد أن أصبحت المقالات والتعليقات تعمل بصورة جيدة، لنلقِ نظرة على القالب app/views/articles/show.html.erb . يبدو الملف طويلًا جدًّا، لذا سنستخدم الملفات الجزئية لتنظيف وترتيب الشيفرة البرمجية. تصيير مجموعة الملفات الجزئية في البداية سننشئ ملفًّا جزئيًا خاصًّا بالتعليقات وظيفته عرض جميع التعليقات الخاصّة بالمقالة. أنشئ الملف app/views/comments/_comment.html.erb وأضف إليه الشيفرة التالية: <p> <strong>Commenter:</strong> <%= comment.commenter %> </p> <p> <strong>Comment:</strong> <%= comment.body %> </p> والآن يمكنك تعديل الملف `app/views/articles/show.html.erb` كما يلي: <p> <strong>Title:</strong> <%= @article.title %> </p> <p> <strong>Text:</strong> <%= @article.text %> </p> <h2>Comments</h2> <%= render @article.comments %> <h2>Add a comment:</h2> <%= form_for([@article, @article.comments.build]) do |f| %> <p> <%= f.label :commenter %><br> <%= f.text_field :commenter %> </p> <p> <%= f.label :body %><br> <%= f.text_area :body %> </p> <p> <%= f.submit %> </p> <% end %> <%= link_to 'Edit', edit_article_path(@article) %> | <%= link_to 'Back', articles_path %> بهذه الطريقة سيتم تصيير الملف الجزئي في app/views/comments/_comment.html.erb لكلّ تعليق موجود في مجموعة @article.comments، وعندما يتنقّل التابع render بين عناصر مجموعة التعليقات فإنه يُسند كل تعليق إلى متغيّر محلي local variable يحمل اسم الملف الجزئي ذاته، وفي حالتنا هذه comment والذي يكون متوفّرًا في الملف الجزئي. تصيير الملف الجزئي الخاصّ بالاستمارة لنقم بإزالة قسم التعليقات الجديد إلى ملف جزئي خاصّ به، ومرة أخرى أنشئ ملفًّا باسم _form.html.erb في المجلد app/views/comments/ وأضف إليه ما يلي: <%= form_for([@article, @article.comments.build]) do |f| %> <p> <%= f.label :commenter %><br> <%= f.text_field :commenter %> </p> <p> <%= f.label :body %><br> <%= f.text_area :body %> </p> <p> <%= f.submit %> </p> <% end %> ثم عدّل الملف app/views/articles/show.html.erb ليصبح بالصورة التالية: <p> <strong>Title:</strong> <%= @article.title %> </p> <p> <strong>Text:</strong> <%= @article.text %> </p> <h2>Comments</h2> <%= render @article.comments %> <h2>Add a comment:</h2> <%= render 'comments/form' %> <%= link_to 'Edit', edit_article_path(@article) %> | <%= link_to 'Back', articles_path %> يعرّف تابع render الثاني القالب الجزئي الذي نرغب في تصييره وهو comments/form، ونظرًا لوجود المحرّف / ضمن هذه السلسلة النصّية سيعرف Rails بأنّك ترغب في تصيير الملف _form.html.erb الموجود في المجلد app/views/comments. أما الكائن @article فسيكون متوفّرًا لأيّ ملفّ جزئي يتم تصييره في العرض لأنّنا عرّفناه كمتغيّر من نوع instance. حذف التعليقات إن القدرة على حذف التعليقات المزعجة هي من الميزات المطلوب توفرها في المدوّنة، ولتنفيذ ذلك سنحتاج إلى إضافة رابط لحذف التعليقات ضمن العرض وإلى حدث destroy في المتحكّم CommentsController. لذا سنضيف أوّلًا رابط الحذف ضمن الملفّ الجزئي app/views/comments/_comment.html.erb وكما يلي: <p> <strong>Commenter:</strong> <%= comment.commenter %> </p> <p> <strong>Comment:</strong> <%= comment.body %> </p> <p> <%= link_to 'Destroy Comment', [comment.article, comment], method: :delete, data: { confirm: 'Are you sure?' } %> </p> سيؤدّي النقر على هذا الرابط إلى إرسال الفعل DELETE متمثّلًا بالرابط /articles/:article_id/comments/:id إلى المتحكّم CommentsController، والذي سيبحث بدوره - مستعينًا بهذا الرابط - عن التعليق المراد حذفه من قاعدة البيانات. لنضِف حدث destroy إلى المتحكّم في الملف app/controllers/comments_controller.rb: class CommentsController < ApplicationController def create @article = Article.find(params[:article_id]) @comment = @article.comments.create(comment_params) redirect_to article_path(@article) end def destroy @article = Article.find(params[:article_id]) @comment = @article.comments.find(params[:id]) @comment.destroy redirect_to article_path(@article) end private def comment_params params.require(:comment).permit(:commenter, :body) end end سيبحث الحدث destroy عن التعليق المراد حذفه، ثم يعيّن موقعه في مجموعة @article.comments ثم يحذفه من قاعدة البيانات ويعيد توجيهنا إلى حدث show الخاصّ بالمقالة. حذف الكائنات المترابطة من البديهي أنّه عند حذف مقالة معيّنة فإن من الواجب أن يتم حذف التعليقات المرتبطة بها، وإلا فستشغل هذه التعليقات مساحة ضمن قاعدة البيانات دون أيّ فائدة. يتيح لنا Rails استخدام الخيار dependent لتحقيق ذلك. توجّه إلى نموذج Article (app/models/article.rb) وعدّله بالصورة التالية: class Article < ApplicationRecord has_many :comments, dependent: :destroy validates :title, presence: true, length: { minimum: 5 } end الاستيثاق Authentication في Rails إن كنت ترغب في نشر المدوّنة على الإنترنت، سيكون بإمكان أي شخص إضافة وتعديل وحذف المقالات والتعليقات فيها. يقدّم Rails نظام استيثاق HTTP بسيط يمكن استخدامه في التطبيقات البسيطة كتطبيقنا هذا. سنحتاج في المتحكّم ArticlesController إلى وسيلة لمنع وصول الشخص غير المستوثق منه إلى الأحداث التي يتضمّنها هذا المتحكّم، ويمكن استخدام تابع http_basic_authenticate_with لتحقيق ذلك. ولاستخدام نظام الاستثياق سنقوم بالإفصاح عنه في بداية ملف المتحكّم ArticlesController in app/controllers/articles_controller.rb وسنستوثق من جميع الأحداث المتوفّرة في هذا المتحكّم عدا حدثي index وshow: class ArticlesController < ApplicationController http_basic_authenticate_with name: "dhh", password: "secret", except: [:index, :show] def index @articles = Article.all end # بقيّة الشيفرة ... كذلك سنسمح للمستخدمين المستوثق منهم فقط بحذف التعليقات، لذا أضف الشيفرة التالية إلى المتحكّم CommentsController في الملف app/controllers/comments_controller.rb: class CommentsController < ApplicationController http_basic_authenticate_with name: "dhh", password: "secret", only: :destroy def create @article = Article.find(params[:article_id]) # ... end # بقيّة الشيفرة ... والآن إن حاولت إنشاء مقالة جديدة، ستتلقّى طلب استيثاق كهذا: جدير بالذكر أنّ هناك العديد من وسائل الاستيثاق في تطبيقات Rails، أشهرها Devise rails engine و Authlogic. إطار العمل Rails ونظام الترميز UTF-8 إن أسهل طريقة للعمل مع Rails هي تخزين جميع البيانات الخارجية بنظام الترميز UTF-8، وإن لم تفعل ذلك فغالبًا ما تقوم مكتبات Ruby وإطار العمل Rails بتحويل البيانات الأصلية إلى هذا الترميز، ولكن لا يمكن الاعتماد على هذه المكتبات بصورة تامّة، ويفضّل التأكد من أنّ جميع البيانات الخارجية مرمّزة بهذا النظام. وفي حال حدوث أي خطأ في نظام الترميز فإن الحروف ستظهر في المتصفّح غالبًا على هيئة أشكال معينية سوداء بداخلها علامة استفهام، أو قد تظهر الحروف على هيئة رموز غريبة كأن يظهر الرمز “ü” بدلاً من الحرف “ü”. يتّخذ Rails بعض الإجراءات في نظامه الداخلي للتقليل من المسبّبات الشائعة لهذه المشاكل والتي يمكن الكشف عنها وتصحيحها بصورة تلقائية. ولكن، إن كنت تتعامل مع بيانات من مصادر خارجية غير مخزّنة بترميز UTF-8، لن يكون Rails قادرًا على الكشف بصورة تلقائية عن أسباب المشكلة أو تقديم حلّ لها. وهناك مصدران شائعان للبيانات غير المخزّنة بترميز UTF-8: محرر النصوص: تحفظ معظم محرّرات النصوص الملفات البرمجية بصيغة UTF-8، وإن لم يقم محرّر النصوص الذي تستخدمه في كتابة الشيفرات البرمجية بذلك، فقد ينتج عن ذلك تحوّل الحروف الخاصّة أو حروف اللغات الأخرى غير الإنكليزية إلى التحول في المتصفّح إلى أشكال معينية بداخلها علامة استفهام. ينطبق هذا الأمر كذلك على ملفات الترجمة i18n. تجدر الإشارة إلى أنّه تتيح معظم محررات النصوص التي لا تحفظ الملفات البرمجية بهذا الترميز افتراضيًّا (مثل Dreamweaver) إمكانية تغيير الترميز الافتراضي للملفات المحفوظة إلى نظام UTF-8، وننصح بالقيام بذلك. قاعدة البيانات: يحوّل Rails البيانات القادمة من قاعدة البيانات إلى ترميز UTF-8، ولكن إن لم يكن هذا نظام الترميز هذا مستخدمًا من طرف قاعدة البيانات فلن يكون بالإمكان تخزين جميع المحارف المدخلة من قبل المستخدم. فعلى سبيل المثال، إن كان نظام الترميز الداخلي لقاعدة البيانات هو Latin-1 وأدخل المستخدم كلمات باللغة الروسية أو العربية أو اليابانية، فستخسر البيانات إلى الأبد بمجرد دخولها إلى قاعدة البيانات. لذا ينصح دائمًا بتحويل نظام الترميز الداخلي في قاعدة البيانات إلى نظام UTF-8. المصدر: توثيقات Ruby on Rails.

توجد بعض الإعدادات التي يجب إجراؤها في البداية كجزء من عملية التثبيت الأولية عند إنشاء خادوم جديد. تؤدي هذه الخطوات إلى تعزيز أمان وقابلية استخدام Usability خادومك ممّا يعطيك أساسًا صلبا للإجراءات اللاحقة. الخطوة الأولى - الولوج Login إلى الحساب الجذر Root يتوجّب عليك، للولوج إلى خادومك، معرفة عنوان IP العمومي Public IP Address إضافةً إلى كلمة سر حساب المستخدم الجذر. إن لم تكن قمتَ بالولوج إلى خادومك من قبل فبإمكانك الاطّلاع على الدرس أساسيات وخيارات الاتصال بخادوم عن بعد باستخدام SSH (البرنامج المسؤول عن الاتصال بالخادوم عن بعد)، الذي يُغطي هذه العملية بالتفصيل. ابدأ بالاتصال بخادومك عن طريق الأمر التّالي (أبدِل الكلمة البارزة بعنوان IP خادومك العمومي): ssh root@SERVER_IP_ADDRESS أكمِل عملية الولوج بقبول التحذيرات حول موثوقية المستضيف Host authenticity في حال ظهورها، وإعطاء معلومات التحقق (كلمة السّر أو المفتاح السري). سيُطلب منك تبديل كلمة سر حساب المستخدِم الجذر إن كانت هذه أول مرة تلِج إلى الخادوم باستخدام كلمة السر. حول المستخدم الجذر المستخدم الجذر هو المُدير في أنظمة لينوكس، ولديه امتيازات Privileges واسعة جدًًا. عمليًا، يُنصَح بعدم استخدام الحساب الجذر في الأمور الاعتيادية، فالصلاحيات الواسعة التي يتمتع بها تُتيح إحداث تغييرات - قد تكون مدمِّرة - في النظام . وليسَ نادرا أن يحدث ذلك بشكل غير مقصود. الخطوة الموالية ستكون إنشاء حساب مستخدم بديل بمجال تأثير محدود للقيام بالعمل اليومي. ستتعلّم أيضًا كيفية الحصول على امتيازات أكبر عندما تحتاج إليها. الخطوة الثانية - إنشاء مستخدم جديد بعد الولوج باستخدام الحساب الجذر تُصبِح على استعداد لإضافة الحساب الجديد الذي سنلِج باستخدامه من الآن فصاعدا. يُنشئ المثال التالي مستخدما باسم "demo"، أبدِلهُ باسم المستخدم الذي تراه مناسِبا: adduser demo ستُطرَح عليك بعض الأسئلة، بدءًا بكلمة سرالحساب. أدخِل كلمة سر قوية. يُمكنك تعبئة بقية المعلومات الإضافية حسب رغبتك. اضغط على زر Enter في لوحة المفاتيح لتجاوز أي حقل لا تودّ تعبئته. الخطوة الثالثة - امتيازات الجذر لدينا الآن حساب مستخدم جديد بامتيازات حساب عادي. سنحتاج في بعض الأحيان إلى القيام ببعض الأعمال الإدارية التي تتطلّب امتيازات الجذر. نستطيع إعداد "مستخدم أعلى" Super user لتجنب الخروج من الحساب العادي والولوج بالحساب الجذر أثناء القيام بالمهام الإدارية. المستخدم الأعلى هو مستخدم عادي ولكنه يستطيع الحصول على امتيازات المستخدم الجذر مؤقتا عن طريق كتابة sudo أمام الأوامر التي يطلب تنفيذها. يتوجّب علينا إضافة المستخدم الجديد إلى مجموعة المستخدمين Users group sudo حتى يتسنى له الحصول على الامتيازات الإدارية. يُسمَح - في الإعداد الافتراضي لأوبنتو 14.04 - للمستخدمين الأعضاء في مجموعة sudo باستخدام أمر sudo. نفّذ باستخدام الحساب الجذر، الأمر التالي لإضافة المستخدم الجديد إلى المجموعة sudo (أبدِل الكلمة البارزة بالاسم الذي اخترتَه للمستخدم الجديد): gpasswd -a demo sudo يُمكِن للمستخدِم الجديد الآن تنفيذ أوامر بامتيازات المستخدِم الأعلى. الخطوة الرابعة - إضافة الاستيثاق عن طريق المفتاح العمومي Public Key Authentication (يوصى بهذه الخطوة) الخطوة التالية في تأمين خادومك هي إعداد مفتاح عمومي Public Key للمستخدم الجديد. هذا الإعداد سيرفع من أمان خادومك بطلب مفتاح SSH سري للولوج. توليد زوج من المفاتيح سيتوجّب عليك توليد زوج مفاتيح (مفتاح عمومي وآخر سرّي). إن كان لديك مفتاح عمومي ترغب في استخدامه تجاوز إلى خطوة نسخ المفتاح العمومي. لتوليد زوج مفاتيح جديدة نفِّذ الأمر التالي على الطّرفيةTerminal محليًّا (على حاسوبك الشخصي): ssh-keygen ستظهر لك مُخرجات شبيهة بما يلي (localuser هنا هو اسم المستخدم الذي يُنفِّذ الأمر): Generating public/private rsa key pair. Enter file in which to save the key (/Users/localuser/.ssh/id_rsa): اضغط زر Enter على لوحة المفاتيح لقبول اسم ومسار حفظ الملف، أو أدخل مسارا لملف جديد. سيُطلب منك بعدها إدخال عبارة سر Passphrase لتأمين المفتاح. عبارة السّر اختيارية ويُمكنك تجاوزها وتركها خاوية. ملحوظة: عند ترك عبارة السر خاوية يُمكن استخدام المفتاح السري للاستيثاق دون الحاجة لإدخال عبارة سر، أما في حال إنشاء عبارة سر فستحتاج للإثنين (عبارة السر والمفتاح السري) للولوج. إنشاء عبارة سر يُعطي أمانا أكبر ولكن لكل من الطريقتين (المفتاح السري وحده أو مع عبارة سر) استخداماتُها، كما أنهما أكثر أمانا من الاستيثاق الأساسي عن طريق كلمة سر. حصلنا الآن على مفتاح سري (id_rsa)، وآخر عمومي (id_rsa.pub) يوجدان في المجلَّد ssh. الموجود في المجلّد الشخصي للمستخدم localuser. تذكَّر أنه لا يجوز على الإطلاق مُشاركة المفتاح السري مع أي شخص لا يحق له الاتصال بخواديمك. نسخ المفتاح العمومي بعد توليد المفتاح العمومي محليًّا ننقلهُ إلى الخادوم. استخدم الأمر التالي لإظهار مفتاحك العمومي (أبدِل مسار الملف في حال غيّرت مسار الحفظ أثناء توليد المفتاح) cat ~/.ssh/id_rsa.pub سيظهر مفتاحك العمومي الذي يُشبه شكلُه التالي: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBGTO0tsVejssuaYR5R3Y/i73SppJAhme1dH7W2c47d4gOqB4izP0+fRLfvbz/tnXFz4iOP/H6eCV05hqUhF+KYRxt9Y8tVMrpDZR2l75o6+xSbUOMu6xN+uVF0T9XzKcxmzTmnV7Na5up3QM3DoSRYX/EP3utr2+zAqpJIfKPLdA74w7g56oYWI9blpnpzxkEd3edVJOivUkpZ4JoenWManvIaSdMTJXMy3MtlQhva+j9CgguyVbUkdzK9KKEuah+pFZvaugtebsU+bllPTB0nlXGIJk98Ie9ZtxuY3nCKneB+KjKiXrAvXUPCI9mWkYS/1rggpFmu3HbXBnWSUdf localuser@machine.local حدّد المفتاح العمومي وانسخه إلى الحافِظة Clipboard. إضافة المفتاح العمومي إلى المستخدم الجديد على الخادوم يجب إضافة مفتاح SSH إلى ملف خاص يوجد بالمجلد الشخصي للمستخدِم على الخادوم حتى يتسنى له استعمالُه للاستيثاق. استعمل الأمر التالي - على الخادوم - للانتقال من المستخدِم الجذر إلى المستخدِم الذي أنشأناه في الخطوات الأولى من هذا الدّليل (أبدِل demo باسم المستخدِم الذي اخترتَه): su - demo ستُنقَل بعدَ الولوج إلى الخادوم إلى ملف المستخدم الشخصي. أنشئ مجلَّدا فرعيا جديدا في المجلّد الشخصي باسم ssh. (النقطة جزء من الاسم) مع تقييد الأذون Permissions عن طريق الأوامر التالية: mkdir .ssh chmod 700 .ssh سنُنشئ الآن ملفًا باسم authorized_keys مع فتحه عن طريق محرِّر نصوص. سنستخدِم محرِّر Nano للتعديل على الملف، كما في الأمر التالي: nano .ssh/authorized_keys ثم نأتي لإدراج المفتاح العمومي في الملف عن طريق لصقه في المحرِّر. اضغط على الزريْن CTRL و X معًا في لوحة المفاتيح للخروج من المحرِّر ثم زر Y لحفظ التغييرات وEnter لتأكيد اسم الملف. نُقيّد الأذون على الملف authorized_keys عن طريق الأمر: chmod 600 .ssh/authorized_keys للعودة إلى المستخدِم الجذر ننفِّذ الأمر التالي: exit بإمكانك الآن الولوج إلى حساب المستخدم الجديد عن طريق SSH باستخدام المفتاح السري. الخطوة الخامسة - إعداد SSH يُمكننا، بعد أن أنشأنا حسابَ مستخدم جديدًا، زيادة تأمين الخادوم عن طريق تغيير إعداد SSH . نبدأ بفتح ملف الإعدادات بواسطة محرِّر نصوص مع استعمال المستخدِم الجذر: nano /etc/ssh/sshd_config تغيير منفذ Port الاتصال عن طريق SSH (اختياري) أولى التغييرات ستكون تعديل المنفذ الذي يستخدمه SSH للاتصال بالخادوم. ابحث عن السّطر التالي: Port 22 عند تغيير هذا الرقم إلى آخر بين 1025 و 65536 فإن خدمة SSH ستستخدم المنفذ الجديد للاتصال بالخادوم بدلا من المنفذ الافتراضي (22). يُحاول بعض المستخدمين غير المسموح لهم بالولوج استعمال منفذ SSH الافتراضي الوصول إلى الخادوم. تغيير المنفذ يعني إضافة خطوات جديدة أمام هذا النوع من المستخدمين لأنه يضطرهم إلى تجربة منافذ عديدة لمعرفة أيها يُستخدم من طرف SSH. يجب عند تغيير منفذ SSH تذكر رقم المنفذ الجديد حتى يُمكن الاتصال عن بعد بالخادوم. سنُغيِّر منفذ SSH إلى 4444. يعني هذا أنه يتوجب إخبار الخادوم عند الاتصال برقم المنفذ المُستخدَم لكي لا يستخدم المنفذ الافتراضي، وهو ما سنشرحه لاحقا. Port 4444 تقييد ولوج المستخدم الجذر عبر SSH بعد تغيير منفذ SSH نبحث عن السّطر التالي: PermitRootLogin yes يُتيح هذا السطر إمكانية السماح للمستخدم الجذر أو منعه من الولوج عن طريق SSH. يُعتبَر هذا الإجراء أكثر أمانا حيثُ يمكن الولوج بالمستخدم العادي عن طريق SSH ثم استخدام صلاحيات المستخدم الجذر عن الحاجة. نُغيّر السطر بإبدال yes ب no لمنع المستخدم الجذر من الولوج عن بعد. PermitRootLogin no يُنصَح دائما، من أجل أمان أكبر، بتقييد ولوج المستخدم الجذر عبر SSH. بعد إنهاء التعديلات احفَظ الملف وأغلقه باستخدام الطريقة التي رأيناها سابقا (CTRL+X، ثم Y و ENTER بعد ذلك). الخطوة السادسة - إعادة تحميل SSH انتهينا الآن من تحرير الإعدادات. لأخذها في الاعتبار نُعيد تشغيل خدمة SSH عن طريق الأمر التالي: service ssh restart يجب أن نتأكد من أن الإعداد الجديد يعمل بشكل جيّد قبل الخروج، حتى لا نجد أنفسَنا في وضعية لا يُمكن فيها الولوج عن بعد إلى الخادوم. افتح نافذة جديدة لواجهة الأوامر على حاسوبك الشخصي. سنجري في النافذة الجديدة اتصالا مع الخادوم باستعمال حساب المستخدم العادي الذي أنشأناه بدلا من المستخدِم الجذر. يجب ذكر رقم منفذ الولوج إلى خادوم لا يستخدم المنفذ الافترضي للاتصال عن طريق SSH وذلك بإضافة العبارة "p 4444-" إلى أمر الاتصال حيثُ 4444 هو رقم المنفذ الجديد. للولوج إلى الخادوم عن طريق المنفَذ الذي أعددناه في الخطوة السابقة نستخدم الأمر التالي (أبدِل SERVER_IP_ADDRESS بعنوان خادومك و demo باسم المستخدِم): ssh -p 4444 demo@SERVER_IP_ADDRESS ملحوظة: لا تنسَ، إن كنت تستخدم برنامج PuTTY، تغيير إعداد المنفَذ في البرنامج حتى يتوافق مع الإعداد الحالي لخادومك. سيُطلب منك إدخال كلمة سر المستخدم الجديد ثم، بعد التحقق، ستلِج إلى المجلد الشخصي للمستخدم على الخادوم. تذكّر إضافة sudo أمام الأوامر التي ترغي في تنفيذها بصلاحيات المستخدِم الجذر: sudo command_to_run حيثُ command_to_run هو الأمر المُراد تنفيذه. إذا جرت الخطوات السّابقة كما وصفناها فإن كل شيء على ما يُرام ويُمكنك الخروج عن طريق الأمر exit ماذا بعد هذا الدرس؟ بالوصول إلى هذه النقطة فإن لدى خادومك أساسا قويا، ويُمكنك تثبيت أي برنامج ترغب فيه عليه. يُمكنك المُتابعة مع هذه السلسة بقراءة مقال خطوات إضافية موصى بها لخواديم أوبنتو 14.04 الجديدة الذي يشرح أمورا من قبيل تفعيل fail2ban للحد من فعاليّة هجمات القوة العمياء Brute force attacks، الإعدادات الأساسية للجدار الناري Firewall، بروتكول NTP وملفات الإبدال Swap. كما أنّ به روابطَ لشروح حول كيفية تثبيت وإعداد بعض تطبيقات الويب الشائعة. مقالات مثل إعداد حِزم LAMP أو LEMP جيّدة لمن يُريد استكشاف المزيد. ترجمة -وبتصرّف- للمقال: Initial Server Setup with Ubuntu 14.04 لصاحبه Justin Ellingwood.

هل تبحث عن وسيلة لتجنّب عمليات الاحتيال التي تتم بواسطة البريد الإلكتروني؟ هل ترغب في تحسين قابلية تسليم رسائلك الإلكترونية Email deliverability، وأن تضمن وصولها بشكل مستمر إلى صناديق بريد المستلمين؟ ما تبحث عنه إذًا هو استيثاق البريد الإلكتروني Email authentication. للوهلة الأولى، تبدو عملية استيثاق البريد الإلكتروني وكأنها مرتبطة بموضوع الحماية والأمان وحسب، ولكنّها في الواقع ترتبط بقابلية تسليم الرسائل الإلكترونية أيضاً، فمن خلال استخدام سجلات DKIM وSPF ثم توثيق رسائلك الإلكترونية، تستطيع حماية علامتك التجارية وستضمن حينها وصول رسائلك الإلكترونية إلى صندوق البريد الوارد بنجاح. سنتعرف معًا في هذا المقال على الأسباب التي جعلت من توثيق الرسائل الإلكترونية جزءًا لا يتجزّأ من عملية تسليم الرسائل، وسننظر بتمعّن إلى ما سيحدث لرسالتك الإلكترونية بعد أن تضغط زرّ الإرسال. ما هي الرسالة الإلكترونية الموثقة؟ تحاول خواديم استقبال الرسائل الإلكترونية، كجزء من عملية تسليم هذه الرسائل، تحديد مدى موثوقية الرسالة المُستقبلة، وذلك من خلال طرح الأسئلة التالية من قبل الخادوم: "هل هذه الرسالة آتية من مرسلها الحقيقي؟ كيف يمكن لي أن أتحقّق من ذلك؟ وماذا أفعل إن لم أفلح في توثيق هذه الرسالة؟". ويبحث خادوم استقبال الرسائل كذلك عن سمعة الإرسال sending reputation المرتبطة بنطاق domain المرسل وعنوان IP الخاص به. وهناك عوامل أخرى تلعب دورًا مهمّاً في نجاح عملية تسليم الرسائل التي ترسلها، ومنها: المحتوى، تفاعل المستلمين مع الرسائل السابقة، الخ. لقد تحدّثنا سابقًا عن كيفية تحسين الحملات التسويقية، وعن تأثير جودة القائمة البريدية أو المحتوى على قابلية تسليم الرسائل الإلكترونية. إذًا، ما المقصود بنجاح عملية توثيق الرسالة الإلكترونية؟ باختصار، نجاح هذه العملية يعني أن الخادوم الذي يستقبل الرسائل الإلكترونية قد قام بالتحقق من سجلّات SPF المتعلقة بتلك الرسالة، ومفتاح DKIM المرتبط بالرسالة وبالنطاق المرسل، وأن الرسالة المرسلة قد تجاوزت هذه الاختبارات بنجاح. عند استخدام Campaign Monitor في إرسال الرسائل التسويقية، يتم تهيئة سجلات SPF بشكل تلقائي لجميع العملاء في سجلات DNS الخاصة بـ Campaign Monitor، ويُجري خادوم استقبال الرسائل عملية التحقق آنفة الذكر في هذه السجلات. يمتلك كلّ مستخدم في Campaign Monitor مفتاح DKIM خاصًّا به، تتم استضافته في سجلات DNS الموجودة في النطاق الخاص بالمستخدم، ويتطلّب استعمال هذا المفتاح ضبط بعض الإعدادات من قبل مالك النطاق. لنتحدث الآن عن الطريقة التي يختار بها خادوم البريد بين أن يقبل أو يرفض حملتك البريدية بالاستناد إلى كيفية تحديده لمدى موثوقية الحملة وصحّتها. قد تلتزم في رسالتك الإلكترونية بجميع قواعد مكافحة الرسائل المزعجة، ويكون مضمون الرسالة جيّدًا، وتكون مرسلة من النطاق المسجل باسم مشروعك التجاري، ولكن هذا كلّه ليس كافياً لتتمكن هذه الرسالة من المرور عبر خادوم استقبال الرسائل الإلكترونية. ما تحتاجه في هذه الحالة، هو توثيق رسالتك الإلكترونية لكي يكون لدى خادوم استقبال الرسائل السجلات المطلوبة للتحقق من أن عنوان البريد الإلكتروني الذي تم من خلاله إرسال هذه الرسالة تابع لـ Campaign Monitor بالفعل، وليس عائدًا لأحد المتصيدين أو القراصنة الذين ينتحلون شخصية هذه الشركة. عمّ يبحث خادوم استقبال الرسائل الإلكترونية؟ يبحث خادوم استقبال الرسائل الإلكترونية عن معلومات معينة في الرسالة الإلكترونية وفي سجلات DNS الخاصة بنطاقك، وذلك لتحديد ما إذا كانت الرسالة الإلكترونية موثوقة وآمنة بالنسبة للمستلم، ومن ثَمَّ التأكُّد من أن الرسالة قد أُرسلت من مصدر موثوق. يشير الاختصار DNS إلى مصطلح نظام أسماء النطاقات Domain Name System، ويمكن تشبيه هذا النظام بدليل الهاتف الخاص بالويب الذي يعمل على تنظيم النطاقات وتمييزها عن بعضها البعض. فكما يتضمن دليل الهاتف أسماء (مثل: زيد عمرو) ورقم الهاتف الخاص بهذا الاسم، فإن نظام أسماء النطاقات يتضمن عناوين ويب (مثل: academy.hsoub.com) إلى عنوان IP الفيزيائي (مثل: 74.125.19.147) الخاص بالحاسوب الذي يستضيف هذا الموقع. SPF هي عبارة عن ميكانيكية يتحقق النطاق المستقبل من خلالها مما إذا كانت الرسالة الإلكترونية قد أرسلت من عنوان IP مخوّل لإرسال الرسائل الإلكترونية باسم مدراء نطاق معيّن. عندما تنشئ سجلّ SPF، فإنّك تضع قائمة بعناوين IP أو الاستضافات المرسلة للرسائل والتي تخوّلها إرسال رسائل تحمل اسم نطاقك الخاصّ. قد يبدو الأمر معقدًا، ولكن إليك المثال التالي لتوضيح الصورة: لنفترض أن أحد الأشخاص حاول اختراق Campaign Monitor عن طريق إرسال رسالة إلكترونية بعنوان مرسل مزيّف. بالنسبة إلى مستلم الرسالة، ستبدو وكأنّها رسالة موثّقة، ولكنّها تحتوي على محتوى ضارّ ومن مصدر غير موثوق. في حالة وجود سجلّات SPF، يمكن لصندوق بريد المستلم أن يحدّد ما إذا كانت الرسالة التي تبدو وكأنّها أرسلت من Campaign Monitor قد أرسلت من عنوان IP مخوّل لإرسال الرسائل بهذا الاسم. إن تطابق عنوان IP المرسل وعنوان استضافته مع سجلّات SPF الخاصّ بنطاق المرسل، فإن الرسالة تكون موثّقة بالاعتماد على سجلّات SPF. أما في حال كانت الرسالة مرسلة من استضافة أو عنوان IP لا يطابق ما هو موجود في سجلات SPF الخاصة بـ Campaign Monitor، فسيعرف الخادوم المستقبل للرسائل أن الرسالة الإلكترونية ليست قادمة من عنوان IP موثّق من قبل Campaign Monitor وأن هذه الرسالة قد تكون مزوّرة. تضاف سجلات SPF بشكل تلقائي لجميع عملاء Campaign Monitor في سجلاتها الخاصّة، أما في حال كنت تملك سجلات SPF خاصّة بك، فتأكد من إضافة تفاصيل حسابك في Campaign Monitor إليها. "يعدّ مفتاح الـ DKIM طريقة للاستيثاق تعتمد على إضافة توقيع مشفّر Encrypted signature للرسالة الإلكترونية، وهو أحد أكثر الوسائل فعّالية لمكافحة إساءة استعمال الرسائل الإلكترونية ويمكن أن يُسهم بشكل كبير في تحسين قابلية استلامها." لتحصل على استيثاق DKIM، فإنك بحاجة للوصول إلى سجلات DNS الخاصّة بالنطاق المرسِل وذلك لإضافة مفتاح DKIM إليها، وهذا من شأنه أن يضمن موثوقية البريد الإلكتروني؛ ذلك لأنّ مالك النطاق هو الشخص الوحيد القادر على إجراء التعديلات على هذه السجلات، وهذا هو أهمّ جزء من طريقة عمل مفاتيح DKIM. وعلى الرغم من أن الآلية الكامنة وراء عمل هذه المفاتيح معقدة نوعًا ما، فإن استخدامها ليس بالأمر الصعب، فبمجرد أن تستخدم DKIM ضمن سجلات DNS الخاصّة بنطاقك، فإن قابلية وصول رسائلك الإلكترونية ستكون أكبر، إلى جانب أنك ستحمي نفسك والمستخدمين من الرسائل المزعجة وعمليات الاحتيال. إليك طريقة عمل هذه المفاتيح بشكل موجز: ما إن يتم استخدام سجلات DKIM وإثبات صحّتها، يصبح لبريدك الإلكتروني توقيع DKIM يضاف إلى ترويسة الرسالة الإلكترونية خلال عملية الإرسال. يتم توليد التوقيع المشفّر هذا بالاعتماد على مفتاح DKIM الذي قمت بإضافته إلى سجلات DNS الخاصة بنطاقك، إلى جانب سلسلة التجزئة hash string المبنية على عناصر معيّنة في الرسالة الإلكترونية المرسلة، وهذا يعني أن كل رسالة إلكترونية تقوم بإرسالها تحمل توقيع DKIM فريدًا. عندما يستلم خادوم استقبال الرسائل رسالتك الإلكترونية، فإنه يفكّ تشفير توقيع DKIM باستخدام المفتاح العام المستضاف في سجلات DNS الخاصّة بك، وسيقوم في الوقت نفسه بتوليد سلسلة تجزئة جديدة بالاعتماد على نفس العناصر التي تم استخدامها في الرسالة الإلكترونية. إن حصل تطابق بين التوقيع الذي تمّ فكّ تشفيره وسلسلة التجزئة الجديدة، فإن الرسالة الإلكترونية قد اجتازت بنجاح عملية استيثاق DKIM. وهذا يعني أن خادوم استقبال الرسائل قادر على القيام بأمرين، هما: أن يحدّد وبأمان أنّ مرسِل الرسالة الإلكترونية هو نفسه مالك النطاق الذي يتواجد فيه مفتاح DKIM. أن يحدّد أن محتويات الرسالة الإلكترونية لم تتعرض للتعديل أو التبديل أثناء انتقالها من المرسل إلى المستلم. ولهذا السبب، تعدّ مفاتيح DKIM إحدى أقوى أدوات الاستيثاق التي يمكنك الاستفادة منها، والتي يمكن أن تضمن من خلالها نجاحًا طويل الأمد لحملتك التسويقية. لماذا يجدر بك الاهتمام باستيثاق البريد الإلكتروني إن ازدياد أهمّية استيثاق البريد الإلكتروني ما هو إلا نتيجة مباشرة لاستغلال هذه المنصّة وبشكل مستمر كوسيلة للاحتيال والتصيّد، الأمر الذي يدفع مزودي خدمات الإنترنت وخدمات البريد الإلكتروني إلى اعتماد معايير أكثر قوة لحماية المستخدمين من الرسائل المزعجة ورسائل الاحتيال الإلكتروني. وكلّما اعتمد مزوّدو خدمات الإنترنت سياسات أكثر صرامة في هذا المجال، فإن مرسلي الرسائل الذين لم يوثّقوا حساباتهم سيواجهون صعوبات أكبر في إرسال رسائلهم الأمر الذي يهدّد بشكل جدّي نجاح حملاتهم التسويقية عبر هذه المنصّة. إن استيثاق البريد الإلكتروني يعدّ من الأمور المهمّة لتحقيق نجاح طويل الأمد في حملتك التسويقية، شأنه في ذلك شأن العناصر الأخرى المطلوبة لتحقيق هذا النجاح كجودة القائمة البريدية أو قوة تصميم الرسالة الإلكترونية ومضمونها. ختامًا إن توثيق البريد الإلكتروني يسهم في تقليل احتمالية تعرّض علامتك التجارية لعمليات احتيال أو سرقة، إلى جانب أنه يساعد رسائلك الإلكترونية للوصول إلى المشتركين بصورة أفضل. إن لم تقم بعد بتوثيق حملتك التسويقية عبر البريد الإلكترونيّ، فقد حان الآن الوقت المناسب للقيام بذلك. ترجمة - وبتصرّف - للمقال Solving the mystery that is email authentication لصاحبه James Smart.

يأتي Laravel، وهذه إحدى ميزاته الكثيرة، مضمنّا بآليات استيثاق Authentication جاهزة للاستخدام. سنطبق في هذا الدرس آلية الاستيثاق على صفحة الدفع checkout بحيث يُسمح بالدخول للمستخدمين المسجلين فقط. هذا الدرس جزء من سلسلة تعلم Laravel والتي تنتهج مبدأ "أفضل وسيلة للتعلم هي الممارسة"، حيث ستكون ممارستنا عبارة عن إنشاء تطبيق ويب للتسوق مع ميزة سلة المشتريات. يتكون فهرس السلسلة من التالي: مدخل إلى Laravel 5. تثبيت Laravel وإعداده على كلّ من Windows وUbuntu. أساسيات بناء تطبيق باستخدام Laravel. إنشاء روابط محسنة لمحركات البحث (SEO) في إطار عمل Laravel. نظام Blade للقوالب. تهجير قواعد البيانات في Laravel. استخدام Eloquent ORM لإدخال البيانات في قاعدة البيانات، تحديثها أو حذفها. إنشاء سلة مشتريات في Laravel. الاستيثاق في Laravel. (هذا الدرس) إنشاء واجهة لبرمجة التطبيقات API في Laravel. إنشاء مدوّنة باستخدام Laravel. استخدام AngularJS واجهةً أمامية Front end لتطبيق Laravel. الدوّال المساعدة المخصّصة في Laravel. استخدام مكتبة Faker في تطبيق Laravel لتوليد بيانات وهمية قصدَ الاختبار. يغطي الدرس المواضيع التالية: إعداد الاستيثاق في Laravel 5. أساسيات الاستيثاق في Laravel 5. تغيير رابط تسجيل الدخول المبدئي. إعدادات الاستيثاق في Laravel 5 يوجد ملف إعداد الاستيثاق على المسار config/auth.php. في ما يلي جزء من الملف: 'model' => App\User::class, 'table' => 'users', 'password' => [ 'email' => 'emails.password', 'table' => 'password_resets', 'expire' => 60, ], يحدّد الملف: اسم نموذج الاستيثاق. اسم جدول المستخدمين. خيارات إعادة تعيين كلمة السر. سنستخدم النموذج User لاستيثاق المستخدمين. افتح الملف User.php وعدّله على النحو التالي: <?php namespace App; use Illuminate\Auth\Authenticatable; use Illuminate\Database\Eloquent\Model; use Illuminate\Contracts\Auth\Authenticatable as AuthenticatableContract; class User extends Model implements AuthenticatableContract { use Authenticatable; /** * The database table used by the model. * * @var string */ protected $table = 'users'; /** * The attributes that are mass assignable. * * @var array */ protected $fillable = ['name', 'email', 'password']; /** * The attributes excluded from the model's JSON form. * * @var array */ protected $hidden = ['password', 'remember_token']; } فلنعرّج قليلا على الأصناف الجديدة علينا: use Illuminate\Contracts\Auth\Authenticatable as AuthenticatableContract; توجد في Laravel أصناف يطلق عليها اسم العقود Contracts. العقود هي مجموعة واجهات Interfaces تعرّف خدمات يوفّرها إطار العمل. تعرّف العقود دوال يحتاجها إطار العمل لتأدية الخدمة. يستورد السطر أعلاه العقد Authenticatable وهي واجهة تعرّف الدوال الضرورية لاستيثاق المستخدمين. عند استيراد الواجهة أعطيناها الاسم AuthenticatableContract حتى لا تختلط مع السمة Trait الذي يحمل نفس الاسم (نستعمله في نموذج المستخدم كما سنرى لاحقا). يجب على الكائن الذي يستوثق من المستخدمين (نموذج المستخدم في حالتنا) أن ينجز Implement هذه الواجهة: class User extends Model implements AuthenticatableContract لإنجاز دوال الواجهة (تعرّف واجهة Authenticatable الدوال دون أن تنجزها) نستخدم السمة Illuminate\Auth\Authenticatable. نستورده أولا: use Illuminate\Auth\Authenticatable; ثم نستخدمه: use Authenticatable; يحدّد النموذج جدول البيانات المستخدم لتخزين بيانات المسجَّلين، ويفعّل الإسناد الشامل لبعض الحقول. تعيّن مصفوفة hidden$ بيانات المستخدم التي لا نودّ عرضها عند الإجابة على طلب عبر واجهة تطبيقات برمجية API (يجب إخفاء كلمة سر المستخدم password ورمز الأمان remember_token عن الخارج). يأتي مع Laravel مبدئيا ملف تهجير لإنشاء جدول المستخدمين. افتح ملف التهجير 2014_10_12_000000_create_users_table.php (قد يختلف الختم الزمني في اسم الملف حسب إصدار Laravel): <?php use Illuminate\Database\Schema\Blueprint; use Illuminate\Database\Migrations\Migration; class CreateUsersTable extends Migration { /** * Run the migrations. * * @return void */ public function up() { Schema::create('users', function (Blueprint $table) { $table->increments('id'); $table->string('name'); $table->string('email')->unique(); $table->string('password', 60); $table->rememberToken(); $table->timestamps(); }); } /** * Reverse the migrations. * * @return void */ public function down() { Schema::drop('users'); } } يعرّف ملف التهجير حقول جدول المستخدمين. تعيّن الدالة rememberToken رمز حماية لتأمين المستخدمين ضدّ هجمات تزوير الطلب عبر الموقع CSRF. استمارات التسجيل والولوج Login يوجد في عرض الدخول login.blade.php استمارتان، واحدة لتسجيل المستخدمين Registration والأخرى لدخولهم Login. افتح ملف العرض login وحدّثه على النحو التالي: @extends('layouts.layout') @section('content') <section id="form"><!--form--> <div class="container"> <div class="row"> <div class="col-sm-4 col-sm-offset-1"> <div class="login-form"><!--login form--> <h2>Login to your account</h2> <form method="POST" action="{{url('auth/login')}}"> {!! csrf_field() !!} <input type="email" name="email" id="email" placeholder="Email Address" /> <input type="password" name="password" id="password" placeholder="Password" /> <span> <input name="remember" id="remember" type="checkbox" class="checkbox"> Keep me signed in </span> <button type="submit" class="btn btn-default">Login</button> </form> </div><!--/login form--> </div> <div class="col-sm-1"> <h2 class="or">OR</h2> </div> <div class="col-sm-4"> <div class="signup-form"><!--sign up form--> <h2>New User Signup!</h2> <form method="POST" action="{{url('register')}}"> {!! csrf_field() !!} <input type="text" name="name" id="name" placeholder="Name"> <input type="email" name="email" placeholder="Email Address"/> <input type="password" name="password" placeholder="Password"> <button type="submit" class="btn btn-default">Signup</button> </form> </div><!--/sign up form--> </div> </div> </div> </section><!--/form--> @endsection التغييرات الأساسية هنا هي: تعريف رابط مناسب لاستمارتي التسجيل والدخول مع تحديد أن البيانات تُرسَل بإجراء POST: // دخول المستخدمين <form method="POST" action="{{url('auth/login')}}"> // تسجيل المستخدمين <form method="POST" action="{{url('register')}}"> تُرسل بيانات الدخول إلى الرابط larashop.dev/auth/login وبيانات التسجيل إلى الرابط larashop.dev/register. تضيف التعليمة ()csrf_field حقلا أمنيا في الاستمارتين للحيلولة دون هجمات CSRF. مسارات الدخول، الخروج والتسجيل نضيف الآن المسارات الخاصة بالاستيثاق. افتح ملف المسارات routes.php وأضف المسارات التالية: // مسارات الدخول والخروج Route::get('auth/login', 'Front@login'); Route::post('auth/login', 'Front@authenticate'); Route::get('auth/logout', 'Front@logout'); // مسار التسجيل Route::post('/register', 'Front@register'); نعرّف المسار الذي يعرض استمارتي التسجيل والدخول: Route::get('auth/login', 'Front@login'); نعرّف إجراء HTTP POST الذي يوثّق المستخدمين: Route::post('auth/login', 'Front@authenticate'); نعرّف مسار خروج المستخدم: Route::get('auth/logout', 'Front@logout'); نعرف مسار تسجيل المستخدمين الجدد (إجراء HTTP POST): Route::post('/register', 'Front@register'); المسارات المَحمِيّة مسار محمي هو مسار يطلُب من الزائر الدخول قبل الوصول إليه. سنحمي في هذه الفقرة الرابط http://larashop.dev/checkout. يعني هذا أن المستخدمين المسجّلين فقط يمكنهم رؤية صفحة الدفع. عدّل مسار checkout/ في ملف المسارات ليصبح على النحو التالي: Route::get('/checkout', [ 'middleware' => 'auth', 'uses' => 'Front@checkout' ]); تُنفّذ التعليمة 'middleware' => 'auth', قبل دالة Front@checkout؛ وتتحقق من دخول الزائر. فإن لم يكن سجّل دخوله توجّهه إلى الرابط auth/login/، وتعرض له صفحة الدفع بعد الدخول. دوال التسجيل والاستيثاق نعدّل ملف المتحكّم لإضافة دوال تجيب على الطلبات القادمة من المسارات السابقة. افتح ملف المتحكم Front.php لتعديله. نبدأ باستيراد فضاءات الأسماء التي نحتاجها: use App\User; use Illuminate\Support\Facades\Auth; استوردنا نموذج المستخدم User وفضاء الأسماء الخاص بالاستيثاق Auth. توجد في فضاء الأسماء Auth الدوال والكائنات التي نحتاجها للاستيثاق من المستخدمين. تسجيل مستخدم جديد public function register() { if (Request::isMethod('post')) { User::create([ 'name' => Request::get('name'), 'email' => Request::get('email'), 'password' => bcrypt(Request::get('password')), ]); } return Redirect::away('login'); } تستخدم دالة التسجيل المعلومات المذكورة في استمارة التسجيل New User Signup! لإنشاء مستخدم جديد عبر طلب الدالة User::create (تعرّفنا على هذه الدالة خلال درس Eloquent ORM). ثم نوجّه الزائر بعد إلى صفحة الدخول. لاحظ استخدام الدالة bcrypt أثناء تسجيل المستخدم. تعمّي هذه الدالة كلمة السر قبل تخزينها في جدول البيانات. الاستيثاق من المستخدمين تستوثق الدالة التالية من المستخدمين: public function authenticate() { if (Auth::attempt(['email' => Request::get('email'), 'password' => Request::get('password')])) { return redirect()->intended('checkout'); } else { return view('login', array('title' => 'Welcome', 'description' => '', 'page' => 'home')); } } ستوثق الدالة Auth::attempt من المستخدم بناء على عنوان البريد email وكلمة السر password الذين أرسلتهما استمارة الدخول. في حال نجاح دخول المستخدم يُعاد توجيهه إلى صفحة الدفع checkout عبر الدالة ()redirect. تسجيل خروج المستخدمين يؤدي طلب الدالة Auth::logout إلى تسجيل خروج المستخدمين بعد دخولهم عبر الدالة السابقة. عدّل دالة logout الموجودة في ملف المتحكم لتصبح كالتالي: public function logout() { Auth::logout(); return Redirect::away('auth/login'); } تخرج الدالة المستخدم وتوجهه إلى صفحة الدخول. إظهار بيانات الدخول في العرض نحتاج، قبل اختبار التسجيل والدخول، إجراء تغيير أخير. تُظهر الصورة التالية الشريط العلوي الأيمن من الموقع: نريد أن يظهر الشريط على النحو التالي بعد دخول المستخدم: نريد أن يظهر اسم المستخدم بعد الدخول، وإبدال رابط Login بـLogout. افتح ملف العرض layout.blade.php للتعديل عليه. تذكر أن هذا هو العرض الرئيس الذي تمدّده بقية العروض. نغيّر جزئية الترويسة (header) من ملف العرض لتصبح كالتالي: <header id="header"><!--header--> <div class="header_top"><!--header_top--> <div class="container"> <div class="row"> <div class="col-sm-6"> <div class="contactinfo"> <ul class="nav nav-pills"> <li><a href="#"><i class="fa fa-phone"></i> +2 95 01 88 821</a></li> <li><a href="#"><i class="fa fa-envelope"></i> info@domain.com</a></li> </ul> </div> </div> <div class="col-sm-6"> <div class="social-icons pull-right"> <ul class="nav navbar-nav"> <li><a href="#"><i class="fa fa-facebook"></i></a></li> <li><a href="#"><i class="fa fa-twitter"></i></a></li> <li><a href="#"><i class="fa fa-linkedin"></i></a></li> <li><a href="#"><i class="fa fa-dribbble"></i></a></li> <li><a href="#"><i class="fa fa-google-plus"></i></a></li> </ul> </div> </div> </div> </div> </div><!--/header_top--> <div class="header-middle"><!--header-middle--> <div class="container"> <div class="row"> <div class="col-sm-4"> <div class="logo pull-left"> <a href="{{url('')}}"><img src="{{asset('images/home/logo.png')}}" alt="" /></a> </div> </div> <div class="col-sm-8"> <div class="shop-menu pull-right"> <ul class="nav navbar-nav"> <li><a href="#"><i class="fa fa-user"></i> {{Auth::check() ? Auth::user()->name : 'Account'}}</a></li> <li><a href="{{url('checkout')}}"><i class="fa fa-crosshairs"></i> Checkout</a></li> <li><a href="{{url('cart')}}"><i class="fa fa-shopping-cart"></i> Cart</a></li> <li><a href="{{Auth::check() ? url('auth/logout') : url('auth/login')}}"><i class="fa fa-lock"></i> {{Auth::check() ? 'Logout' : 'Login'}}</a></li> </ul> </div> </div> </div> </div> </div><!--/header-middle--> <div class="header-bottom"><!--header-bottom--> <div class="container"> <div class="row"> <div class="col-sm-9"> <div class="navbar-header"> <button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".navbar-collapse"> <span class="sr-only">Toggle navigation</span> <span class="icon-bar"></span> <span class="icon-bar"></span> <span class="icon-bar"></span> </button> </div> <div class="mainmenu pull-left"> <ul class="nav navbar-nav collapse navbar-collapse"> <li><a href="{{url('')}}" {{$page == 'home' ? 'class=active' : ''}}>Home</a></li> <li><a href="{{url('products')}}" {{$page == 'products' ? 'class=active' : ''}}>Products</a></li> <li><a href="{{url('blog')}}" {{$page == 'blog' ? 'class=active' : ''}}>Blog</a></li> <li><a href="{{url('contact-us')}}" {{$page == 'contact_us' ? 'class=active' : ''}}>Contact Us</a></li> </ul> </div> </div> <div class="col-sm-3"> <div class="search_box pull-right"> <input type="text" placeholder="Search"/> </div> </div> </div> </div> </div><!--/header-bottom--> </header><!--/header--> أضفنا التغييرين التاليين على ترويسة العرض: إبدال Account بالتعليمة: {{Auth::check() ? Auth::user()->name : ‘Account’}} نستعمل الدالة Auth::check للتحقق من دخول المستخدم؛ في حال الإيجاب نظهر اسمه بالدالة Auth::user وإلا نبقي على عبارة Account. نفس المبدأ مع عبارة Login التي تصبح بعد الدخول Logout، وتغيير الرابط بما يُناسب (larashop.dev/auth/login للدخول وlarashop.dev/logout للخروج). افتح الرابط http://larashop.dev/auth/login وسجل مستخدما جديد عبر الاستمارة New User Signup. بالضغط على زر Signup تستدعي المسار http://laravel.dev/register مع الإجراء POST. تتولى دالة register في المتحكم تلقي الطلب واستدعاء النموذج الذي ينشئ تسجيلة جديدة في جدول البيانات ثم تعيد الدالة توجيه المستخدم إلى صفحة الدخول. يمكنك التأكد من إنشاء المستخدم في الجدول users ضمن قاعدة البيانات. نجرّب الدخول بالمستخدم الجديد بإدخال عنوانه البريدي وكلمة السر في استمارة التسجيل. إن أدخل بيانات مستخدم صالحة فستُنقل إلى صفحة الدفع. لاحظ أن اسم المستخدم وعبارة Logout يظهران في الشريط العلوي. ترجمة -وبتصرّف- للمقال Laravel 5 Authentication لصاحبه Rodrick Kazembe.

في حين أنه من الممكن إدارة خواديمك باستخدام تسجيلات الدخول القائمة على كلمات المرور إلا أنه غالبا يكون إنشاء واستخدام زوج مفاتيح SSH فكرة أفضل، لأن هذه المفاتيح أكثر أمانا من كلمات المرور ويمكنها مساعدتك على تسجيل الدخول دون الحاجة إلى تذكر كلمات المرور الطويلة. على Digital Ocean، يمكنك رفع مفتاحك ليكون جزءا من خواديمك عند إنشائها وهذا سيسمح لك بتسجيل دخولك إلى الخواديم بدون كلمات مرور بينما تظل آمنة للغاية. في العادة، يستعمل مستخدمو ويندوز برنامج PuTTY لإنشاء جلسات Session SSH والتي ستسمح لك بالاتصال بخادومك، كما يوفر لك هذا البرنامج إمكانية إنشاء مفاتيح SSH وتذكر مفتاح كل خادوم. في هذا الدّرس، ستتعلم كيف تستخدم PuTTY لإنشاء زوج مفاتيح SSH، وكيف ترفع مفتاحك العام (public key) إلى واجهة الويب الخاصة بـDigital Ocean، وكيف تنشئ droplets جديدة (VPS) مع تضمين مفتاحك العام، وفي النهاية سنريك كيف تتصل بخواديمك بدون استخدام كلمة مرور باستخدام مفتاحك الخاص. كيف يعمل زوج مفاتيح SSH نستخدم زوجًا من مفاتيح SSH كطريقة للاستيثاق (authentication method) وذلك عن طريق إنشاء مفتاحين مرتبطين. المفتاح الأول يدعى بالمفتاح الخاص (private key) وهذا المفتاح سري ويجب على من أنشأه أن يحتفظ به في مكان آمن، لأنه يُستخدم للتعرف عليك بطريقة تشبه شمع الأختام التي كانت تُستخدم لإغلاق الرسائل في الماضي، فهو يُستعمل لإثبات أن الاتصال قادم منك. يجب ألا تسمح بأي شخص أن يحصل على مفتاحك الخاص، لأنه سيتمكن من تسجيل الدخول إلى أي حساب مرتبط بهذا المفتاح، وإذا أردت مشاركة الوصول معه، فتوجد طرق أفضل لفعل ذلك. أما المفتاح الآخر فيدعى بالمفتاح العام (public key)، هذا المفتاح يرتبط بشكل حقيقي مع المفتاح الخاص، الفرق أنه يمكنك مشاركة هذا المفتاح بحرية مع أي شخص على الإنترنت. الشيء الوحيد الذي يمكن لشخص آخر أن يفعله بهذا المفتاح هو أن يسمح لك بتسجيل الدخول إلى جهازه، وهذا ما سنقوم بإعداده في هذا الدّرس، بإنشاء خواديم جديدة متضمنة مفاتيحنا العامة. تنزيل وتثبيت PuTTY و PuTTYgen بداية، سنحتاج إلى تنزيل وتثبيت كل من PuTTY وهي أداة للاتصال بخواديم بعيدة عن طريق SSH (صدفة آمنة - secure shell) و PuTTygen وهي أداة تُستخدم لإنشاء مفاتيح SSH. يمكنك إيجاد روابط تحميل كلا الأداتين على موقع المشروع. أسهل طريقة للحصول على جميع الأدوات الضرورية هي عن طريق زيارة الرابط أعلاه ومن ثم الضغط على رابط بعنوان “A Windows installer for everything except PuTTYtel" كما في الصورة التالية: نزّل التّطبيق ونصّبه، بإمكانك الإبقاء على الخيارات الافتراضية (في عملية التّنصيب) أو التّعديل عليها كيفما شئت. إنشاء زوج مفاتيح SSH سنبدأ بإنشاء زوج مفاتيح SSH. سنبدأ بتشغيل PuTTYgen وذلك عن طريق استخدام قائمة ابدأ أو بالضغط على مفتاح ويندوز وكتابة "PuTTYgen" والذي سيشغل برنامج مولد المفاتيح وسيبدو كما في الصورة التالية: لإنشاء مفتاح جديد، يمكنك اختيار المعاملات الموجودة في الأسفل حسبت متطلباتك: تقريبا في أغلب الحالات، ستكون القيم الافتراضية خيارًا جيّدًا، لذلك يمكنك إبقاؤها كما هي. عندما تنتهي، اضغط على زر "Generate" الموجود على الجانب الأيمن: يتم إنشاء مفاتيح SSH باستخدام بيانات عشوائية لأسباب أمنية، لذلك ستحتاج إلى توليد بعض البيانات العشوائية من خلال تحريك الفأرة في النافذة، هذه العشوائية والتي تدعى أيضا بـ "entropy" تُستخدم لإنشاء مفاتيح بطريقة آمنة حتى لا يتمكن الآخرين من تقليدها. عندما يستقبل نظام التشغيل عددًَا كافيًا من البيانات العشوائية سيوّلد زوج مفاتيح، وستظهر مخرجات مفتاح العام في صندوق نصي على الشاشة. يمكنك استخدام هذه المعلومات عن طريق نسخها ولصقها من صندوق النصوص، لكننا سنحفظها لاستخدامها لاحقا عن طريق الواجهة المتوفرة. اضغط على كل من زر حفظ المفتاح العام "Save public key" والخاص "Save private key" واختر مكانًا آمنًا لحفظها: يمكنك تسمية مفاتيحك بأي اسم تريده، وبشكل افتراضي سيتم إعطاء مفتاح الخاص امتداد ppk. أما بالنسبة للمفتاح العام فأنصحك باختيار امتداد مثل txt. حتى تتمكن من فتحه لاحقا باستخدام محرر نصوص عادي، فستحتاج فيما بعد إلى قراءة البيانات الموجودة في هذا الملف. قمنا الآن بتوليد زوج مفاتيح وحفظناه على الجهاز وهو الآن جاهزة للاستخدام. رفع مفتاحك العام إلى حساب Digital Ocean كما ذكرنا سابقا، يمكنك نشر مفتاحك العام بحرية لأنه يمكن أن يُستخدم لتأكيد المستخدم الذي يملك المفتاح الخاص المرتبط به، بالإضافة إلى أنه لا يمكن استخدامه لإعادة إنشاء مفتاح خاص لذلك سيكون من الآمن رفعه. داخل حساب Digital Ocean الخاص بك، اضغط على رابط "SSH Keys" الموجود على قائمة التصفح على اليسار: سيتم نقلك إلى صفحة إدارة مفاتيح SSH. في الجانب الأيمن العلوي اضغط على زر "Add SSH Key": ستظهر لك شاشة جديدة وسيطلب منك تحديد اسم لهذا المفتاح الذي ستنشئه، اختر اسمًا سهلًا لتتمكن من التعرف عليه لاحقا. بعد ذلك، يجب عليك لصق محتويات المفتاح العام الخاص بك في المساحة الموجودة في الأسفل، إذا أغلقت جلسة أداة PuTTYgen فيجب عليك في هذه الحالة فتح الملف المحتوي على المفتاح العام الخاص بك باستخدام محرر نصي (مثل Notepad)، ومن ثم اختيار كامل النص الموجودة في الملف ومن ثم لصقه في الحقل الموجود على الموقع، وسيبدو كما في المثال التالي: عندما تنتهي، اضغط على زر "Create SSH Key"، وسيكون المفتاح متوفرًا في لوحة تحكم Digital Ocean. نحتاج الآن فقط إلى إنشاء خادوم جديد باستخدام هذا المفتاح. إنشاء خادوم VPS يتضمن مفتاح SSH العام والآن، بعد أن حصلنا على مفتاحنا العام في واجهتنا، يمكننا تضمينه في خواديمنا الجديدة، وهذا سيسمح لنا بالاستيثاق وتسجيل الدخول إلى خادومنا الجديد باستخدام المفتاح الخاص بدون الحصول على كلمة مرور إضافية. لإنشاء خادوم جديد، اضغط على زر "Create" في الجانب الأيسر العلوي من لوحة التحكم: اختر اسمًا لـ Droplet الخاصة بك، ومن ثم املأ بقية المعلومات مثل الحجم وموقع البيانات كالمعتاد. في الأسفل، يوجد قسم بعنوان "Add optional SSH Keys" وستجد داخله أزرار لكل مفاتيح SSH التي رفعتها إلى الواجهة. يمكنك اختيار مفتاح واحد أو أكثر لتضمينها مع خادومك: إذا كنت معتادا على إنشاء الخواديم عن طريق Digital Ocean، فأنت متعود على استقبال رسالة عند الإنشاء بها معلومات التوثيق وكلمة المرور، وعند اختيار تضمين مفتاح SSH إلى خادومك لجديد، لن تُرسل لك هذه الرسالة. بدلا من ذلك، يجب استخدام مفتاحك الخاص لتسجيل الدخول، والتي لا تحتاج إلى كلمة مرور. إعداد جلسة SSH مع مفاتيح SSH في PuTTY نملك الآن droplet تتضمن مفتاحًا عامًا، ويمكننا استخدام PuTTY للاتصال بها، وسنفعل ذلك بإعداد وحفظ الجلسة، وبهذه الطريقة يمكننا إعادة الاتصال لاحقا بسرعة مع حفظ جميع إعداداتنا. افتح برنامج PuTTY الرئيسي وذلك عن طريق الضغط المزدوج، أو بالضغط على مفتاح ويندوز وكتابة PuTTY. ستُفتح لك شاشة الجلسة الرئيسية. الخطوة الأول هي إدخال عنوان IP للـ droplet الخاصة بك إلى صفحة الجلسة. يمكننك الحصول على هذا العنوان من خلال لوحة تحكم Digital Ocean: بشكل افتراضي، يستخدم SSH منفذ 22، ويجب اختيار SSH كنوع اتصال، وهذه كل القيم التي نحتاجها. بعد ذلك، نحتاج إلى الذّهاب إلى "Data" في قسم "Connection" في الجانب الأيسر من قائمة التصفح: هنا، سندخل اسم المستخدم للخادوم، وسيكون "root" للإعداد الأولي والذي هو المُستخدم الجذر لخادومك، وهذا هو الحساب الذي تم إعداده مع مفتاحك العام، أدخل "root" في الحقل Auto-login username: بعد ذلك، نحتاج إلى الضغط على تصنيف SSH في قائمة التصفح: داخل هذا التصنيف، اضغط على التصنيف الفرعي "Auth". ستجد حقل في الشاشة يطلب منك إدخال المفتاح الخاص من أجل الاستيثاق "Private key file for authentication"، اضغط على زر "Browse": ابحث عن ملف المفتاح الخاص الذي حفظته، هذا المفتاح الذي ينتهي بـ ppk.، جدْه ثم اضغط على "Open" في نافذة الملف: الآن، في نافذة التصفح، نحتاج إلى الرجوع نحو شاشة "Session" التي بدئنا بها. هذه المرة، نحتاج إلى اسم الجلسة التي سنحفظها، ويمكنك تسميتها بأي اسم تريده، لذلك اختر اسمًا سهلًا لكي تستطيع تذكره لاحقا. عندما تنتهي، اضغط على زر "Save". الآن، لقد حفظت جميع بيانات الإعداد التي تحتاجها للاتصال بخادومك. الاتصال بخادومك باستخدام جلسة PuTTY مسجلة الآن، بعد أن حفظت جلستك، يمكنك استدعاء هذه القيم في أي وقت بالعودة إلى شاشة "Session"، واختيار الشاشة التي ترغب باستخدامها في جزء "Saved Session"، ومن ثم الضغط على "Load" لاستعادة جميع الإعدادات، وهذا سيملأ جميع الحقول بالخيارات التي اخترتها سابقا. عندما ترغب بالاتصال بخادومك، اضغط على زر "Open" في شاشة "Sessions" بعد أن تُحمّل جلستك: في المرة الأولى التي تتصل بها بمضيفك عن بعد (remote host)، سيطلب منك التأكد من هوية الخادوم البعيد (remote server)، وهذا الإجراء عادي متوقع في المرة الأولى التي تتصل بها بخادوم جديد، لذلك اختر "Yes" للاستمرار. بعد ذلك، ستجد أنه قد قام بتسجيل دخولك إلى خادومك بدون أن يسأل على كلمة المرور: وبهذا، نجحت في إعداد مفاتيح SSH مع Digital Ocean. الخاتمة يمكنك الآن إنشاء خواديم على Digital Ocean باستخدام مفتاح SSH العام بكل سهولة، ويمكنك استخدام مفاتيح SSH التي أنشئاها على العديد من الخواديم كما تشاء. ترجمة -وبتصرف- للمقال: How To Use SSH Keys with PuTTY on DigitalOcean Droplets for Windows users لصاحبه Justin Ellingwood.

إذا كان لديك أكثر من حاسوب في نفس الشبكة، فعند حدٍّ معيَّن ستحتاج إلى مشاركة الملفات بين تلك الحواسيب. خادوم FTPبروتوكول نقل الملفات (File Transfer Protocol اختصارًا FTP) هو بروتوكول TCP لتنزيل الملفات بين الحواسيب؛ في الماضي، كان يُستخدم أيضًا لرفع الملفات، لكن هذه الطريقة لا توفر إمكانية التشفير، وستُنقَل معلومات المستخدم مع البيانات في صيغة سهلة التفسير؛ إذا كنت تبحث هنا عن طريقة آمنة لرفع أو تنزيل الملفات، فألقِ نظرةً على خادوم OpenSSH. يعمل FTP وفق نمط «عميل/خادوم»؛ حيث تُسمى مكونة FTP في الخادوم «عفريت FTP»، الذي يستمع بشكل متواصل لطلبات FTP من العملاء البعيدين؛ وعند وصول طلب، فإنه يجري عملية الدخول ويُهيِّء الاتصال، وستُنفَّذ الأوامر المُرسَلة من عميل FTP أثناء مدة عمل الجلسة. يمكن الوصول إلى خادوم FTP بإحدى الطريقتين: مستخدم مجهول.مستخدم موثوق.في نمط المستخدم المجهول (Anonymous)؛ يمكن للعملاء البعيدين الوصول إلى خادوم FTP بحساب المستخدم الافتراضي المُسمى «anonymous» أو «ftp» ويرسلون عنوان بريد إلكتروني ككلمة مرور؛ أما في نمط المستخدم الموثوق، فيجب على المستخدم امتلاك حساب وكلمة مرور؛ الخيار الثاني غير آمن أبدًا ولا يجب أن يستخدم إلا في الحالات الخاصة؛ إذا كنت تبحث عن طريقة آمنة لنقل الملفات، فانظر إلى SFTP في OpenSSH-Server. وصول المستخدم إلى مجلدات وملفات خادوم FTP يتعلق بالأذونات المعطية للحساب أثناء تسجيل الدخول؛ وكقاعدة عامة، سيخفي عفريت FTP المجلد الجذر لخادوم FTP وسيحول المستخدم إلى مجلد منزل FTP؛ وهذا سيخفي بقية نظام الملفات من الجلسات البعيدة. تثبيت خادوم FTP‏ ‎«vsftpd»‎إن vsftpd هو عفريت FTP متوفر في أوبنتو، ومن السهل تثبيته وإعداده وصيانته؛ لتثبيت vsftpd، عليك تنفيذ الأمر الآتي في الطرفية: sudo apt-get install vsftpdضبط الوصول المجهول لخادوم FTPافتراضيًا، لم يُضبَط vsftpd للسماح للمستخدمين المجهولين بالتنزيل؛ إذا كنت تريد السماح لهم بالتنزيل، فعدِّل الملف ‎/etc/vsftpd.conf مغيّرًا: anonymous_enable=Yesسيُنشَأ مستخدم باسم ftp مع مجلد المنزل ‎/srv/ftp أثناء التثبيت؛ هذا هو مجلد FTP الافتراضي. إذا أردت تغيير هذا المسار إلى ‎/srv/files/ftp على سبيل المثال، فببساطة أنشِئ مجلدًا في مكانٍ آخر، وغيّر مجلد المنزل للمستخدم ftp: sudo mkdir /srv/files/ftp sudo usermod -d /srv/files/ftpأعد تشغيل الخدمة vsftpd بعد عمل التغيرات السابقة: sudo restart vsftpdفي النهاية، انسخ أيّة ملفات ومجلدات تريد للمستخدمين المجهولين تنزيلها عبر ftp إلى ‎/srv/files/ftp أو إلى ‎/srv/ftp إذا أبقيت على الإعدادات الافتراضية. ضبط FTP للاستيثاق من المستخدمينافتراضيًا، يكون vsftpd مضبوطًا على الاستيثاق من مستخدمي النظام والسماح لهم بتنزيل الملفات؛ إذا أردت السماح للمستخدمين برفع الملفات، فعدِّل الملف ‎/etc/vsftpd.conf: write_enable=YESثم أعد تشغيل vsftpd: sudo restart vsftpdالآن عندما يتصل مستخدمو النظام عبر FTP، فسيبدؤون في مجلد المنزل الخاص بهم، حيث يستطيعون تنزيل أو رفع الملفات أو إنشاء المجلدات ...إلخ. وبشكلٍ مشابه، لا يُسمَح افتراضيًا للمستخدمين المجهولين برفع الملفات إلى خادوم FTP؛ لتغيير ذلك الإعداد عليك أن تُزيل التعليق عن السطر الآتي وتُعيد تشغيل خدمة vsftpd: anon_upload_enable=YESتحذير: إن السماح للمستخدمين المجهولين برفع الملفات إلى الخادوم هو أمرٌ خطيرٌ جدًا، ولا يُفضَّل أبدًا أن يُسمَح للمستخدمين المجهولين برفع الملفات مباشرةً من الإنترنت. يحتوي ملف الضبط على العديد من خيارات الضبط؛ توجد معلومات حول كل خيار في ملف الضبط؛ ويمكنك مراجعة صفحة الدليل man 5 vsftpd.conf للمزيد من التفاصيل حول كل إعداد. تأمين FTPهنالك خيارات في ‎/etc/vsftpd.conf للمساعدة في جعل vsftpd أكثر أمانًا؛ فمثلًا يمكن أن يقيّد وصول المستخدمين إلى مجلدات المنزل الخاصة بهم بإزالة التعليق عن السطر: chroot_local_users=YESيمكنك أن تقيّد قائمة محددة من المستخدمين إلى مجلدات المنزل الخاصة بهم فقط: chroot_list_enable=YES chroot_list_file=/etc/vsftpd.chroot_listبعد إزالة التعليق عن الخيارات السابقة؛ أنشِئ ملف ‎/etc/vsftpd.chroot_list الذي يحتوي على قائمة بالمستخدمين المسموح لهم واحدًا في كل سطر؛ ثم أعد تشغيل vsftpd: sudo restart vsftpdيحتوي الملف ‎/etc/ftpusers أيضًا على قائمة بالمستخدمين غير المسموح لهم بالوصول إلى FTP؛ القائمة الافتراضية تتضمن root، و daemon، و nobody ...إلخ. لتعطيل الوصول إلى FTP لمستخدمين آخرين، فأضفهم ببساطة إلى القائمة. يمكن أن يُشفَّر FTP باستخدام FTPS، الذي يختلف عن SFTP؛ FTPS هو FTP عبر طبقة المقابس الآمنة (SSL)؛ إن SFTP هو مثل جلسة FTP عبر اتصال SSH مشفر؛ اختلاف رئيسي هو أن مستخدمي SFTP يجب أن يملكوا حساب «shell» على النظام، بدلًا من صدفة nologin؛ قد لا يكون توفير صدفة لكل المستخدمين أمرًا ملائمًا في بعض البيئات مثل خادوم ويب مشترك؛ لكن من الممكن تقييد مثل هذه الحسابات إلى SFTP فقط وتعطيل التعامل مع الصدفة، راجع درس OpenSSH لمزيدٍ من المعلومات. لضبط FTPS، عدِّل الملف ‎/etc/vsftpd.conf وأضف في النهاية: ssl_enable=Yesأيضًا، لاحظ الخيارات المتعلقة بالشهادة والمفتاح: rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.keyضُبِطَت هذه الخيارات افتراضيًا إلى الشهادة والمفتاح الموفر من الحزمة ssl-sert؛ لكن يجب استبدالهما في البيئات الإنتاجية بالشهادة والمفتاح المُولَّد لمضيف محدد؛ للمزيد من المعلومات حول الشهادات، راجع الدرس الخاص بها في هذه السلسلة. أعد الآن تشغيل vsftpd، وسيُجبر المستخدمون غير المجهولين على استخدام FTPS: sudo restart vsftpdللسماح للمستخدم بصدفة ‎/usr/sbin/nologin بالوصول إلى FTP، لكن عدم امتلاك وصول للصدفة، فعدِّل ملف ‎/etc/shells مضيفًا الصدفة nologin: # /etc/shells: valid login shells /bin/csh /bin/sh /usr/bin/es /usr/bin/ksh /bin/ksh /usr/bin/rc /usr/bin/tcsh /bin/tcsh /usr/bin/esh /bin/dash /bin/bash /bin/rbash /usr/bin/screen /usr/sbin/nologinهذا ضروريٌ لأن vsftpd يستخدم PAM افتراضيًا للاستيثاق؛ والملف ‎/etc/pam.d/vsftpd يحتوي على: auth required pam_shells.soالصدفات التي تسمح الوحدة PAM لها بالوصول هي الصدفات المذكورة في ملف ‎/etc/shells. يمكن ضبط أغلبية عملاء FTP الشهيرين ليتصلوا عبر FTPS. الأداة lftp التي تعمل من سطر الأوامر لها إمكانية استخدام FTPS أيضًا. مصادرراجع موقع vsftpd الرسمي لمزيدٍ من المعلومات.لتفاصيل الخيارات في ‎/etc/vsftpd.conf راجع صفحة دليل vsftpd.conf.ترجمة -وبتصرف- للمقال Ubuntu Server Guide: FTP Server.

يشرح هذا الدرس استخدام SSSD للاستيثاق من تسجيلات دخول المستخدم باستخدام Active Directory بطريقة «ad»؛ أما في الإصدارات القديمة من sssd، كان من الممكن أن يتم الاستيثاق بطريقة «ldap»، لكن عندما يتم الاستيثاق باستخدام مايكروسوفت ويندوز Active Directory، فكان من الضروري تثبيت إضافات POSIX AD في المتحكم بالنطاق؛ لكن طريقة «ad» تبسِّط الضبط ولا تتطلب أيّة تغيرات في بنية المتحكم بالنطاق. الشروط المسبقة والافتراضات والمتطلباتنفترض أن لديك Active Directory مضبوط وجاهز للعمل.نفترض أن المتحكم بالنطاق يعمل كخادوم DNS.نفترض أن المتحكم بالنطاق هو خادوم DNS الرئيسي المحدد في ‎/etc/resolv.conf.نفترض أن قيود ‎_kerberos، و ‎_ldap، و ‎_kpasswd ...إلخ. مضبوطة في منطقة DNS.نفترض أن الوقت مُزامَنٌ على المتحكم بالنطاق.النطاق المستخدم في هذا المثال هو myubuntu.example.com.التثبيتيجب تثبيت الحزم krb5-user ،samba ،sssd و ntp؛ نحتاج إلى تثبيت سامبا حتى لو لم يُقدِّم الخادوم أيّة مشاركات. هنالك حاجة لحقل Kerberos والاسم الكامل أو عنوان IP للمتحكمات بالنطاق. أدخِل الأمر الآتي لتثبيت تلك الحزم: sudo apt-get install krb5-user samba sssd ntpانظر إلى القسم التالي لطريقة الإجابة عن الأسئلة التي يسألها السكربت المشغَّل بعد تثبيت حزمة krb5-user. ضبط Kerberosستُسأل عند تثبيت حزمة krb5-user عن اسم الحقل (realm name) بأحرفٍ كبيرة؛ وعن خادوم مركز توزيع المفاتيح (أي المتحكم بالنطاق) وعن الخادوم المدير (المتحكم بالنطاق أيضًا في هذا المثال)؛ وهذا ما سيكتب القسمين [realm] و [domain_realm] في ملف ‎/etc/krb5.conf؛ هذه الأقسام ليست ضرورية إن كان الاكتشاف التلقائي للنطاق مفعّلًا، خلا ذلك فكلاهما ضروريٌ. إذا كان اسم النطاق myubuntu.example.com، فأدخِل اسم الحقل كما يلي: MYUBUNTU.EXAMPLE.COM. وبشكل اختياري، عدِّل الملف ‎/etc/krb5.conf مضيفًا بعض الخيارات لتحديد مدة صلاحية بطاقة Kerberos (هذه القيم جيدة لتستخدم قيمًا افتراضيةً): [libdefaults] default_realm = MYUBUNTU.EXAMPLE.COM ticket_lifetime = 24h # renew_lifetime = 7dإذا لم تُحدَّد قيمة default_realm، فربما من الضروري تسجيل الدخول باستخدام «username@domain» بدلًا من «username». يجب أن يكون وقت النظام في عضو نطاق Active Directory متوافقًا مع مثيله في المتحكم بالنطاق، وإلا فستفشل عملية الاستيثاق باستخدام Kerberos؛ فمثلًا، يمكن أن يُوفِّر خادوم المتحكم بالنطاق خدمة NTP؛ عدِّل الملف ‎/etc/ntp.conf: server dc.myubuntu.example.comضبط سامبايجب أن يُستخدَم سامبا لتوفير خدمات netbois/nmbd المتعلقة بالاستيثاق من Active Directory، حتى وإن لم تُشارَك أيّة ملفات. عدِّل الملف ‎/etc/samba/smb.conf وأضف ما يلي إلى قسم [global]: [global] workgroup = MYUBUNTU client signing = yes client use spnego = yes kerberos method = secrets and keytab realm = MYUBUNTU.EXAMPLE.COM security = adsملاحظة: بعض المراجع تقول أنه يجب تحديد «password server» وأن يشير إلى المتحكم بالنطاق؛ لكن هذا ضروريٌ فقط إن لم يُضبَط DNS للعثور على المتحكم بالنطاق؛ حيث يَعرِض سامبا افتراضيًا تحذيرًا إن ضُبِطَ الخيار «password server» مع «security = ads». ضبط SSSDلا يوجد ملف ضبط افتراضي أو مثال عن ملف الضبط لملف ‎/etc/sssd/sssd.conf في حزمة sssd؛ فمن الضروري إنشاء واحد؛ ها هو ذا أصغر ملف ضبط يمكن أن يعمل: [sssd] services = nss, pam config_file_version = 2 domains = MYUBUNTU.EXAMPLE.COM [domain/MYUBUNTU.EXAMPLE.COM] id_provider = ad access_provider = ad # Use this if users are being logged in at /. # This example specifies /home/DOMAIN-FQDN/user as $HOME. # Use with pam_mkhomedir.so override_homedir = /home/%d/%u # Uncomment if the client machine hostname doesn't match # the computer object on the DC. # ad_hostname = mymachine.myubuntu.example.com # Uncomment if DNS SRV resolution is not working # ad_server = dc.mydomain.example.com # Uncomment if the AD domain is named differently than the Samba domain # ad_domain = MYUBUNTU.EXAMPLE.COM # Enumeration is discouraged for performance reasons. # enumerate = trueبعد حفظ الملف، فانقل الملكية إلى الجذر، وغيِّر أذونات الملف إلى 600: sudo chown root:root /etc/sssd/sssd.conf sudo chmod 600 /etc/sssd/sssd.confحيث سيرفض sssd أن يعمل إن لم تكن الملكية أو الأذونات صحيحةً. التأكد من ضبط nsswitch.confالسكربت الذي يعمل بعد تثبيت حزمة sssd يُجري بعض التعديلات على ملف ‎‎/etc/nsswitch.conf تلقائيًا؛ حيث يجب أن يكون كما يلي: passwd: compat sss group: compat sss ... netgroup: nis sss sudoers: files sss تعديل ملف ‎/etc/hostsأضف اسمًا بديلًا الذي يحدد اسم النطاق الكامل للحاسوب المحلي في ملف ‎/etc/hosts كما يلي: 192.168.1.10 myserver myserver.myubuntu.example.comهذا مفيد لاستخدامه مع تحديثات DNS الديناميكية. الانضمام إلى Active Directoryعليك الآن إعادة تشغيل ntp و samba، وتشغيل sssd: sudo service ntp restart sudo restart smbd sudo restart nmbd sudo start sssdثم اختبر الضبط بمحاولة الحصول على بطاقة Kerberos: sudo kinit Administratorتحقق من البطاقة باستخدام: sudo klistإذا كانت هنالك بطاقة مع تاريخ انتهاء الصلاحية، فقد حان الوقت للانضمام إلى النطاق: sudo net ads join -kالتحذير «No DNS domain configured. Unable to perform DNS Update‎.‎» يعني أنه ليس هنالك اسم بديل (أو اسم بديل صحيح) في ملف ‎/etc/hosts، ولا يمكن للنظام توفير الاسم الكامل له؛ فعليك التحقق من الاسم البديل في ‎/etc/hosts كما هو مشروح في قسم «تعديل ملف etc/hosts/» أعلاه. الرسالة «NT_STATUS_UNSUCCESSFUL» تشير إلى أن الانضمام إلى النطاق قد فشل وأن هنالك شيء ما خاطئ، عليك مراجعة الخطوات السابقة وإصلاح المشكلة قبل الإكمال. هنالك تحققان آخران اختياريان للتأكد من أن الانضمام إلى النطاق قد نجح؛ لاحظ أنه إذا نجح الانضمام إلى النطاق لكن إذا فشل أحد أو كلا التحققين، فربما عليك الانتظار لدقيقةٍ أو دقيقتين قبل المحاولة مرةً أخرى؛ حيث يبدو أن بعض التغيرات لا تحدث في الوقت الحقيقي. 1. التحقق الأول: تحقق من «وحدة التنظيم» (Organizational Unit) لحسابات الحواسيب في Active Directory للتأكد من أن حساب الحاسوب قد أُنشِئ (وحدات التنظيم هي موضوع خارج عن نطاق هذا الدرس). 2. التحقق الثاني: نفِّذ الأمر الآتي لمستخدم AD معيّن (المدير مثلًا): getent passwd usernameملاحظة: إذا ضبطت الخاصية «enumerate = ture» في ملف sssd.conf، فإن الأمر getnet passwd دون تمرير اسم مستخدم كوسيط سيَعرض جميع مستخدمي النطاق؛ ربما يكون هذا السلوك مفيدًا للاختبار، لكنه بطيء وغير مستحسن للخواديم الإنتاجية. اختبار الاستيثاقيجب أن يكون الآن من الممكن الاستيثاق عبر Active Directory: su - usernameإذا عَمِلَ الأمر السابق بنجاح، فيجب أن تعمل بقية طرق الاستيثاق (getty، و SSH). إذا أُنشِئ حساب الحاسوب، مما يشير إلى أن النظام قد انضم إلى النطاق، لكن فشل الاستيثاق؛ فربما من المفيد مراجعة الملف ‎/etc/pam.d و sssdwitch.conf وأيضًا تغيرات الملفات المشروحة آنفًا في هذا الدرس. مجلدات المنزل مع pam_mkhomedirعند تسجيل الدخول باستخدام حساب مستخدم Active Directory، فمن المحتمل ألّا يكون للمستخدم مجلد منزل، ويمكن حل هذه المشكلة باستخدام pam_mkhomedir.so، حيث سيُنشَأ مجلد المنزل للمستخدم عند تسجيل الدخول؛ عدِّل ملف ‎/etc/pam.d/common-session، وأضف هذا السطر مباشرةً بعد «session required pam_unix.so»: session required pam_mkhomedir.so skel=/etc/skel/ umask=0022ملاحظة: قد تحتاج إلى «override_homedir» في ملف sssd.conf للعمل عملًا صحيحًا، تأكد من ضبط تلك الخاصية هناك. الاستيثاق في سطح مكتب أوبنتومن الممكن أيضًا الاستيثاق من المستخدمين في سطح مكتب أوبنتو باستخدام حسابات Active Directory؛ لكن لن تظهر أسماء حسابات مستخدمي AD في قائمة الاختيار مع المستخدمين المحليين، لذلك يجب تعديل lightdm؛ وذلك بتحرير الملف ‎/etc/lightdm/lightdm.conf.d/50-unity-greeter.conf وإضافة السطرين الآتيين: greeter-show-manual-login=true greeter-hide-users=trueأعد الإقلاع لإعادة تشغيل lightdm، حيث يمكن الآن تسجيل الدخول باستخدام حساب تابع للنطاق إما بالشكل «username» أو «username/username@domain». المصادرصفحة مشروع SSSD.مقالة «DNS Server Configuration guidelines».صفحة «Active Directory DNS Zone Entries».صفحة «Kerberos config options».ترجمة -وبتصرف- للمقال Ubuntu Server Guide: SSSD and Active Directory.

لا يستعمل أغلب الناس Kerberos لوحده، فبعد أن يستوثق المستخدم (Kerberos)، فسنحتاج لمعرفة ماذا بإمكانه أن يفعل (تصريح [authorization])؛ وهنا تكون مهمة البرامج مثل LDAP. قد يكون استنساخ قاعدة مبادئ Kerberos بين خادومين أمرًا معقدًا، ويضيف قاعدة بيانات مستخدم أخرى إلى شبكتك؛ لحسن الحظ، MIT Kerberos مضبوطٌ ليستخدم دليل LDAP كقاعدة بيانات للمبادئ؛ يشرح هذا الدرس ضبط خادومَيّ Kerberos الرئيسي والثانوي لاستخدام OpenLDAP لقاعدة بيانات المبادئ. ملاحظة: الأمثلة هنا تستخدم MIT Kerberos و OpenLDAP. ضبط OpenLDAPأولًا، يجب تحميل المخطط الضروري على خادوم OpenLDAP الذي لديه اتصال شبكي مع مركز توزيع المفاتيح الرئيسي والثانوي؛ بقية هذا القسم تفترض أن لديك استنساخ LDAP مضبوط بين خادومين على الأقل؛ للمزيد من المعلومات حول ضبط OpenLDAP راجع درس «خادوم OpenLDAP». من المطلوب أيضًا ضبط OpenLDAP من أجل اتصالات TLS و SSL؛ لذلك ستكون جميع البيانات المارة بين خادومي LDAP و KDC مشفرةً. ملاحظة: cn=admin,cn=config هو المستخدم الذي أنشأناه مع امتياز الكتابة إلى قاعدة بيانات ldap؛ تكون القيمة في كثير من الأحيان هي RootDN، عدِّل قيمته وفقًا للضبط عندك. لتحميل المخطط على LDAP، فثبِّت الحزمة krb5-kdc-ldap في خادوم LDAP؛ أي أدخِل الأمر الآتي في الطرفية: sudo apt-get install krb5-kdc-ldapثم استخرج محتويات الملف kerberos.schema.gz: sudo gzip -d /usr/share/doc/krb5-kdc-ldap/kerberos.schema.gz sudo cp /usr/share/doc/krb5-kdc-ldap/kerberos.schema /etc/ldap/schema/يجب أن يضاف مخطط kerberos إلى شجرة cn=config؛ آلية إضافة مخطط جديد إلى slapd مفصلةٌ في قسم «تعديل قاعدة بيانات ضيط slapd» من درس «خادوم OpenLDAP». أولًا، أنشِئ ملف ضبط باسم schema_convert.conf، أو أي اسم آخر ذي معنى، يحتوي على الأسطر الآتية: include /etc/ldap/schema/core.schema include /etc/ldap/schema/collective.schema include /etc/ldap/schema/corba.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/duaconf.schema include /etc/ldap/schema/dyngroup.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/java.schema include /etc/ldap/schema/misc.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/openldap.schema include /etc/ldap/schema/ppolicy.schema include /etc/ldap/schema/kerberos.schemaأنشِئ مجلدًا مؤقتًا لاحتواء ملفات LDIF: mkdir /tmp/ldif_outputاستخدم الآن slapcat لتحويل ملفات المخطط: slapcat -f schema_convert.conf -F /tmp/ldif_output -n0 -s \ "cn={12}kerberos,cn=schema,cn=config" > /tmp/cn\=kerberos.ldifعدِّل اسم الملف والمسار السابق ليُطابِق ما عندك إن كان مختلفًا. عدِّل الخاصيات الآتية في الملف المولَّد ‎/tmp/cn=kerberos.ldif: dn: cn=kerberos,cn=schema,cn=config ... cn: kerberosواحذف الأسطر الآتية من نهاية الملف: structuralObjectClass: olcSchemaConfig entryUUID: 18ccd010-746b-102d-9fbe-3760cca765dc creatorsName: cn=config createTimestamp: 20090111203515Z entryCSN: 20090111203515.326445Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090111203515Zقد تختلف قيم تلك الخاصيات، لكن تأكد أنها قد حُِذِفَت. حمِّل المخطط الجديد بالأمر ldapadd: ldapadd -x -D cn=admin,cn=config -W -f /tmp/cn\=kerberos.ldifأضف فهرسًا لخاصية krb5principalname: ldapmodify -x -D cn=admin,cn=config -W Enter LDAP Password: dn: olcDatabase={1}hdb,cn=config add: olcDbIndex olcDbIndex: krbPrincipalName eq,pres,sub modifying entry "olcDatabase={1}hdb,cn=config"وفي النهاية، حدِّث قوائم التحكم في الوصول (ACL): ldapmodify -x -D cn=admin,cn=config -W Enter LDAP Password: dn: olcDatabase={1}hdb,cn=config replace: olcAccess olcAccess: to attrs=userPassword,shadowLastChange,krbPrincipalKey by dn="cn=admin,dc=example,dc=com" write by anonymous auth by self write by * none - add: olcAccess olcAccess: to dn.base="" by * read - add: olcAccess olcAccess: to * by dn="cn=admin,dc=example,dc=com" write by * read modifying entry "olcDatabase={1}hdb,cn=config"هذا كل ما في الأمر، أصبح دليل LDAP جاهزًا لكي يخدم كقاعدة بيانات مبادئ Kerberos. ضبط مركز توزيع المفاتيح الرئيسيبعد ضبط OpenLDAP، حان الوقت الآن لضبط مركز توزيع المفاتيح. أولًا، ثبِّت الحزم الضرورية الآتية، بتنفيذ الأمر: sudo apt-get install krb5-kdc krb5-admin-server krb5-kdc-ldapعدِّل الآن ملف ‎/etc/krb5.conf بإضافة الخيارات الآتية تحت الأقسام الملائمة لها: [libdefaults] default_realm = EXAMPLE.COM ... [realms] EXAMPLE.COM = { kdc = kdc01.example.com kdc = kdc02.example.com admin_server = kdc01.example.com admin_server = kdc02.example.com default_domain = example.com database_module = openldap_ldapconf } ... [domain_realm] .example.com = EXAMPLE.COM ... [dbdefaults] ldap_kerberos_container_dn = dc=example,dc=com [dbmodules] openldap_ldapconf = { db_library = kldap ldap_kdc_dn = "cn=admin,dc=example,dc=com" # this object needs to have read rights on # the realm container, principal container and realm sub-trees ldap_kadmind_dn = "cn=admin,dc=example,dc=com" # this object needs to have read and write rights on # the realm container, principal container and realm sub-trees ldap_service_password_file = /etc/krb5kdc/service.keyfile ldap_servers = ldaps://ldap01.example.com ldaps://ldap02.example.com ldap_conns_per_server = 5 }ملاحظة: عدِّل قيم example.com ،dc=example,dc=com ،cn=admin,dc=example,dc=com ،ldap01.example.com للقيم الملائمة للنطاق، وكائن LDAP، وخادوم LDAP لشبكتك. لاحقًا، استخدم الأداة kdb5_ldap_util لإنشاء الحقل: sudo kdb5_ldap_util -D cn=admin,dc=example,dc=com create -subtrees \ dc=example,dc=com -r EXAMPLE.COM -s -H ldap://ldap01.example.comأنشِئ «مخبأً» (stash) لكلمة المرور المستخدم في خادوم LDAP، تستخدم هذه الكلمة من ldap_kdc_dn و ldap_kadmind_dn في ملف ‎/etc/krb5.conf: sudo kdb5_ldap_util -D cn=admin,dc=example,dc=com stashsrvpw -f \ /etc/krb5kdc/service.keyfile cn=admin,dc=example,dc=comانسخ شهادة سلطة الشهادات من خادوم LDAP: scp ldap01:/etc/ssl/certs/cacert.pem . sudo cp cacert.pem /etc/ssl/certsالآن عدِّل ‎/etc/ldap/ldap.conf ليستخدم الشهادة: TLS_CACERT /etc/ssl/certs/cacert.pemملاحظة: يجب أن تُنسَخ الشهادة أيضًا إلى مركز توزيع المفاتيح الثانوي، للسماح بالاتصال إلى خواديم LDAP باستخدام LDAPS. تستطيع الآن إضافة مبادئ Kerberos إلى قاعدة بيانات LDAP، وستُنسَخ إلى بقية خواديم LDAP المضبوطة للاستنساخ. فأدخل ما يليل لإضافة مبدأ باستخدام الأداة kadmin.local: sudo kadmin.local Authenticating as principal root/admin@EXAMPLE.COM with password. kadmin.local: addprinc -x dn="uid=steve,ou=people,dc=example,dc=com" steve WARNING: no policy specified for steve@EXAMPLE.COM; defaulting to no policy Enter password for principal "steve@EXAMPLE.COM": Re-enter password for principal "steve@EXAMPLE.COM": Principal "steve@EXAMPLE.COM" created.يجب أن تكون خاصيات krbPrincipalName ،krbPrincipalKey ،krbLastPwdChange ،krbExtraData مضافةً إلى كائن المستخدم uid=steve,ou=people,dc=example,dc=com؛ استخدم أداتَيّ kinit و klist لاختبار إذا أصدر المستخدم المعين بطاقةً. ملاحظة: إذا كان كائن المستخدم مُنشأً مسبقًا، فإنه يجب إضافة الخيار ‎-x dn="..."‎ إلى خاصيات Kerberos؛ لأنه سيُنشَأ فيما عدا ذلك كائن مبدأي جديد في شجرة الحقل الفرعية. ضبط مركز توزيع المفاتيح الثانويضبط مركز توزيع المفاتيح الثانوي لاستخدم LDAP هو شبيه بضبطه لاستخدام قاعدة بيانات Kerberos العادية. أولًا، ثبت الحزم الضرورية، بتطبيق الأمر الآتي في الطرفية: sudo apt-get install krb5-kdc krb5-admin-server krb5-kdc-ldapعدِّل الآن ملف ‎/etc/krb5.conf ليستخدم LDAP: [libdefaults] default_realm = EXAMPLE.COM ... [realms] EXAMPLE.COM = { kdc = kdc01.example.com kdc = kdc02.example.com admin_server = kdc01.example.com admin_server = kdc02.example.com default_domain = example.com database_module = openldap_ldapconf } ... [domain_realm] .example.com = EXAMPLE.COM ... [dbdefaults] ldap_kerberos_container_dn = dc=example,dc=com [dbmodules] openldap_ldapconf = { db_library = kldap ldap_kdc_dn = "cn=admin,dc=example,dc=com" # this object needs to have read rights on # the realm container, principal container and realm sub-trees ldap_kadmind_dn = "cn=admin,dc=example,dc=com" # this object needs to have read and write rights on # the realm container, principal container and realm sub-trees ldap_service_password_file = /etc/krb5kdc/service.keyfile ldap_servers = ldaps://ldap01.example.com ldaps://ldap02.example.com ldap_conns_per_server = 5 }أنشِئ مخبأً لكلمة مرور LDAP: sudo kdb5_ldap_util -D cn=admin,dc=example,dc=com stashsrvpw -f \ /etc/krb5kdc/service.keyfile cn=admin,dc=example,dc=comالآن انسخ مخبأ ‎‏«Master Key‎»‏ على المركز الرئيسي ‎/etc/krb5kdc/.k5.EXAMPLE.COM إلى مركز توزيع المفاتيح الثانوي؛ تأكد من نسخ الملف عبر اتصال مشفر مثل scp، أو عبر وسيط تخزين فيزيائي. sudo scp /etc/krb5kdc/.k5.EXAMPLE.COM steve@kdc02.example.com:~ sudo mv .k5.EXAMPLE.COM /etc/krb5kdc/ملاحظة: مرةً أخرى، استبدل EXAMPLE.COM باسم الحقل الحقيقي. وبالعودة إلى المركز الثانوي، أعد تشغيل خادوم ldap فقط: sudo service slapd restartفي النهاية، ابدأ عفريت krb5-kdc: sudo service krb5-kdc startتأكد أن خادومَيّ ldap (وبالتالي kerberos) متزامنَين. تستطيع الآن إكمال استيثاق المستخدمين إن أصبح خادوم LDAP أو Kerberos، أو خادوم LDAP وخادوم Kerberos غير متوفرين. مصادرلدى دليل «Kerberos Admin Guide» بعض التفاصيل الإضافية.للمزيد من المعلومات حول kdb5_ldap_util راجع صفحة دليل man kdb5_ldap_util.مصدر آخر مفيد هو صفحة الدليل man krb5.conf.انظر أيضًا لصفحة ويكي أوبنتو: «Kerberos and LDAP».ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Kerberos and LDAP.

إن Kerberos هو نظام استيثاق شبكي مبني على مفهوم الجهة الثالثة الموثوقة؛ الجهتان الأخريتان هما المستخدم والخدمة التي يريد المستخدم أن يستوثق فيها؛ لا يمكن لجميع الخدمات والتطبيقات استخدام Kerberos؛ لكن الخدمات التي تستطيع ذلك تجعله يُقرِّب بيئة الشبكة لتصبح أقرب خطوةً إلى «تسجيل الدخول الموحد» (Single Sign On‏ [SSO]). يشرح هذا الدرس تثبيت وضبط خادوم Kerberos، وبعض الأمثلة عن ضبط العملاء. لمحة عامةإذا كنت جديدًا على Kerberos، فهذه بعض المصطلحات التي من الجيد معرفتها قبل إعداد خادوم Kerberos، أغلبها مرتبطةٌ بأشياء قد تعرفها من البيئات الأخرى: مبدأ (Principal): يجب أن تُعرَّف أيّة مستخدمين أو حواسيب أو خدمات موفرة من الخواديم كمبادئ Kerberos.النماذج (Instances): تستخدم لمبادئ الخدمة ومبادئ الإدارة الخاصة.الحقول (Realms): الحقل الفريد للتحكم الذي تم تزويده من عملية تثبيتKerberos؛ تخيل أن الحقول هي مجال أو مجموعة من المضيفين والمستخدمين الذين ينتمون إليها، ويُصطلَح أن الحقل يجب أن يكون بأحرف كبيرة؛ سيستخدم أوبنتو افتراضيًا عنوان DNS مُحوّلًا إلى أحرفٍ كبيرة (EXAMPLE.COM) اسمًا للحقل.مركز توزيع المفاتيح (Key Distribution Center‏ [KDC]): يتكون من ثلاثة أقسام: قاعدة بيانات لكل المبادئ، وخادوم استيثاق، وخادوم منح بطاقات (ticket granting server)؛ يحب أن يكون هنالك مركز توزيع للمفاتيح واحد على الأقل لكل حقل.بطاقة منح البطاقات (Ticket Granting Ticket): تُصدَر من خادوم الاستيثاق (Authentication Server‏ [AS])؛ بطاقة منح البطاقات (TGT) مشفرة بكلمة مرور المستخدم الذي يعلمها فقط المستخدم و مركز توزيع المفاتيح (KDC).خادوم منح البطاقات (Ticket Granting Server‏ [TGS]): يُصدِر خدمة البطاقات للعملاء عند الطلب.البطاقات: تأكيد هوية مبدأين، أحد تلك المبادئ هو المستخدم، والآخر هو الخدمة المطلوبة من المستخدم؛ تؤسس البطاقات مفتاح تشفير ليُستخدَم في الاتصالات الآمنة أثناء جلسة الاستيثاق.ملفات Keytab: الملفات المستخرجة من قاعدة بيانات مبادئ مركز توزيع المفاتيح وتحتوي على مفتاح التشفير للخدمة أو المضيف.ولجمع القطع مع بعضها بعضًا، لدى الحقل مركز توزيع مفاتيح واحد على الأقل -ويفضل أن يكون لديه أكثر من واحد لضمان توفر الخدمة- الذي يحتوي على قاعدة بيانات بالمبادئ، وعندما يُسجِّل مستخدمٌ دخوله إلى منصة العمل المضبوطة لاستخدام استيثاق Kerberos؛ فإن مركز توزيع المفاتيح يصدر بطاقة منح البطاقات (TGT)، وإذا كانت التصاريح التي أعطاها المستخدم مطابقة، فسيتم الاستيثاق من المستخدم وبإمكانه الآن طلب البطاقات لخدمات Kerberos من خادوم منح البطاقات (TGS)، ستسمح خدمة البطاقات للمستخدم أن يستوثق إلى خدمة دون أن يُدخِل اسم المستخدم أو كلمة المرور. خادوم Kerberos التثبيتلنقاشنا هذا، سننشِئ مجال MIT Kerberos مع الخاصيات الآتية (عدِّلها لتلائم حاجاتك): الحقل: EXAMPLE.COM.مركز توزيع المفاتيح الرئيسي: kdc01.example.com‏ (192.168.0.1).مركز توزيع المفاتيح الثانوي: kdc02.example.com‏ (192.168.0.2).مبدأ المستخدم: steve.مبدأ المدير: steve/admin.ملاحظة: من المستحسن -وبشدة- أن تكون معرفات مستخدمين الشبكة الموثوقين في مجال مختلف عن المستخدمين المحليين (لنقل أنه يبدأ من 5000). قبل تثبيت خادوم Kerberos، فمن الضروري وجود خادوم DNS مضبوط مسبقًا؛ ولما كان حقل Kerberos عرفيًا يستخدم اسم النطاق، فإن هذا القسم يستخدم النطاق EXAMPLE.COM التي ستُشرح طريقة ضبطه في قسم الرئيس الأولي في الدرس الخاص بخادوم DNS الذي سينشر لاحقًا في هذه السلسلة. Kerberos هو بروتوكول حساس بالنسبة للوقت؛ فلو كان وقت النظام المحلي يختلف بين جهاز العميل وجهاز الخادوم أكثر من خمس دقائق (افتراضيًا)، فلن تستطيع منصة العمل أن تستوثق من العميل. ولتصحيح المشكلة، يجب أن يزامن جميع المضيفين وقتهم بواسطة بروتوكول وقت الشبكة (NTP)؛ للمزيد من المعلومات حول ضبط NTP، راجع الدرس «مزامنة الوقت باستخدام بروتوكول NTP». أول خطوة في ضبط حقل Kerberos هي تثبيت حزمتَيّ krb5-kdc و krb5-admin-server؛ أدخل الأمر الآتي في الطرفية: sudo apt-get install krb5-kdc krb5-admin-serverستُسأل في نهاية التثبيت عن اسم مضيف Kerberos وخواديم Admin -اللذان يمكن أن يكونا نفس الخادوم أو غيره- للحقل (realm). ملاحظة: افتراضيًا، يُنشَأ الحقل من اسم نطاق مركز توزيع المفاتيح. ثم أنشِئ حقلًا جديدًا باستخدام الأداة kdb5_newrealm: sudo kdb5_newrealmالضبطتستخدم الأسئلة التي سألوك إياها أثناء التثبيت لضبط ملف ‎/etc/krb5.conf؛ إذا احتجت لتعديل إعدادات مركز توزيع المفتاح (KDC) فعدِّل ببساطة الملف وأعد تشغيل عفريت krb5-kdc. إذا احتجت لإعادة ضبط Kerberos من الصفر، ربما لتغير اسم الحقل، فيمكنك ذلك بالأمر: sudo dpkg-reconfigure krb5-kdcبعد أن يعمل KDC عملًا سليمًا، فإنه من الضروري وجود مستخدم مدير (مبدأ المدير). من المستحسن استخدام اسم مستخدم مختلف عن اسم المستخدم الذي تستعمله عادةً. يمكن فعل ذلك عبر الأداة kadmin.local، بإدخال الأمر الآتي في الطرفية: sudo kadmin.local Authenticating as principal root/admin@EXAMPLE.COM with password. kadmin.local: addprinc steve/admin WARNING: no policy specified for steve/admin@EXAMPLE.COM; defaulting to no policy Enter password for principal "steve/admin@EXAMPLE.COM": Re-enter password for principal "steve/admin@EXAMPLE.COM": Principal "steve/admin@EXAMPLE.COM" created. kadmin.local: quitفي المثال السابق، يكون steve هو مبدأ، و ‎/admin هو نموذج، و يشير ‎@EXAMPLE.COM إلى الحقل، ويكون مبدأ المستخدم هو steve@EXAMPLE.COM، ويجب أن يحمل امتيازات المستخدم العادي فقط. ملاحظة: استبدل EXAMPLE.COM و steve بالحقل واسم مستخدم المدير عندك على التوالي. ثم يحتاج مستخدم المدير الجديد إلى أن يحصل على أذونات قوائم التحكم بالوصول (ACL) الملائمة؛ تُضبَط هذه الأذونات في ملف ‎/etc/krb5kdc/kadm5.acl: steve/admin@EXAMPLE.COM *يعطي هذا القيد steve/admin القدرة على القيام بأي عملية في جميع المبادئ في الحقل؛ تستطيع ضبط المبادئ بامتيازات أقل؛ والذي يكون ملائمًا إذا احتجت مبدأ مدير يستطيع طاقم العمل المبتدئ استخدامه في عملاء Kerberos؛ راجع صفحة الدليل man kadm5.acl لمزيد من التفاصيل. أعد الآن تشغيل krb5-admin-server لكي تأخذ قوائم التحكم بالوصول الجديدة مفعولها: sudo service krb5-admin-server restartيمكن اختبار مبدأ المستخدم الجديد باستخدام الأداة kinit: kinit steve/admin steve/admin@EXAMPLE.COM's Password:بعد إدخال كلمة المرور، فاستخدم klist لعرض معلومات حول بطاقة منح البطاقات (TGT): klist Credentials cache: FILE:/tmp/krb5cc_1000 Principal: steve/admin@EXAMPLE.COM Issued Expires Principal Jul 13 17:53:34 Jul 14 03:53:34 krbtgt/EXAMPLE.COM@EXAMPLE.COMحيث اسم ملف التخزين المؤقت krb5cc_1000 مكون من السابقة krb5cc_‎ ومعرف المستخدم uid، الذي في هذه الحالة 1000؛ ربما تحتاج لإضافة قيد في ملف ‎/etc/hosts من أجل مركز توزيع المفاتيح لكي يستطيع العميل العثور عليه، على سبيل المثال: 192.168.0.1 kdc01.example.com kdc01استبدل 192.168.0.1 بعنوان مركز توزيع المفاتيح؛ هذا يحدث عادة عندما تملك حقل Kerberos يشمل عدّة شبكات مفصولة بموجهات (routers). أفضل طريقة للسماح للعملاء بتحديد مركز توزيع المفاتيح للحقل هو استخدم سجلات DNS SRV، أضف ما يلي إلى ‎/etc/named/db.example.com: _kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc01.example.com. _kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc01.example.com. _kerberos._udp.EXAMPLE.COM. IN SRV 10 0 88 kdc02.example.com. _kerberos._tcp.EXAMPLE.COM. IN SRV 10 0 88 kdc02.example.com. _kerberos-adm._tcp.EXAMPLE.COM. IN SRV 1 0 749 kdc01.example.com. _kpasswd._udp.EXAMPLE.COM. IN SRV 1 0 464 kdc01.example.com.ملاحظة: استبدل EXAMPLE.COM ،kdc01 و kdc02، باسم النطاق، ومركز توزيع المفاتيح الرئيسي، ومركز توزيع المفاتيح الثانوي على التوالي وبالترتيب. انظر إلى الدرس تنصيب وإعداد خدمة اسم النطاق DNS لتعليمات تفصيلية حول ضبط DNS. أصبح حقل Kerberos الجديد جاهزًا لاستيثاق العملاء. مركز توزيع المفاتيح الثانويبعد أن حصلت على مركز توزيع المفاتيح (KDC) في شبكتك، فمن المستحسن الحصول على مركز ثانوي في حال لم يكن المركز الرئيسي متوافرًا؛ وأيضًا لو كان عندك عملاء Kerberos في شبكات مختلفة (ربما مفصولة بموجهات تستخدم NAT)، فمن الحكمة وضع مركز توزيع ثانوي في كل شبكة من تلك الشبكات. أولًا، ثبت الحزم، عندما تسأل عن أسماء Kerberos و Admin server فادخل اسم مركز توزيع المفاتيح الرئيسي: sudo apt-get install krb5-kdc krb5-admin-serverبعد أن ثبتت الحزم، أنشِئ مبدأ مضيف KDC، بإدخال الأمر الآتي في الطرفية: kadmin -q "addprinc -randkey host/kdc02.example.com"ملاحظة: بعد تنفيذك لأوامر kadmin فستُسأل عن كلمة مرور username/admin@EXAMPLE.COM. استخرج ملف Keytab: kadmin -q "ktadd -norandkey -k keytab.kdc02 host/kdc02.example.com"يجب أن يكون هنالك ملف keytab.kdc02 في مجلدك الحالي، انقل الملف إلى ‎/etc/krb5.keytab: sudo mv keytab.kdc02 /etc/krb5.keytabملاحظة: المسار إلى keytab.kdc02 يختلف تبعًا لمجلد العمل الحالي. تستطيع أيضًا أن تُشكِّل قائمةً بالمبادئ في ملف Keytab؛ مما يفيد في استكشاف الأخطاء؛ استخدم الأداة klist: sudo klist -k /etc/krb5.keytabيشير الخيار ‎-k إلى أن الملف هو ملف keytab. هنالك حاجة لوجود ملف kpropd.acl في كل مركز لتوزيع المفاتيح الذي يعرض كل مراكز توزيع المفاتيح للحقل؛ على سبيل المثال، أَنشِئ في مركز توزيع المفاتيح الرئيسي والثانوي الملف ‎/etc/krb5kdc/kpropd.acl: host/kdc01.example.com@EXAMPLE.COM host/kdc02.example.com@EXAMPLE.COMأنشِئ قاعدة بيانات فارغة في المركز الثانوي: sudo kdb5_util -s createابدأ الآن عفريت kpropd، الذي يستمع إلى الاتصالات من أداة kprop؛ تستخدم أداة kprop لنقل ملفات التفريغ: sudo kpropd -Sمن الطرفية في مركز توزيع المفاتيح الرئيسي، أنشئ ملف تفريغ من قاعدة بيانات المبادئ: sudo kdb5_util dump /var/lib/krb5kdc/dumpاستخرج ملف keytab في مركز توزيع المفاتيح الرئيسي وانقله إلى ‎/etc/krb5.keytab: kadmin -q "ktadd -k keytab.kdc01 host/kdc01.example.com" sudo mv keytab.kdc01 /etc/krb5.keytabملاحظة: تأكد من وجود مضيف مرتبط مع kdc01.example.com قبل استخراج Keytab. استخدم الأداة kprop لدفع التغيرات إلى قاعدة البيانات في KDC الثانوي: sudo kprop -r EXAMPLE.COM -f /var/lib/krb5kdc/dump kdc02.example.comملاحظة: يجب أن تَظهر رسالة SUCCEEDED إذا تمت عملية «النسخ» بنجاح، إذا كانت هنالك رسالة خطأ، فتحقق من ‎/var/log/syslog في مركز توزيع المفاتيح الثانوي لمزيدٍ من المعلومات. ربما ترغب بإنشاء مهمة مجدولة لتحديث قاعدة البيانات في مركز توزيع المفاتيح الثانوي كل فترة زمنية؛ ما يلي سيدفع التغييرات إلى قاعدة البيانات كل ساعة (لاحظ أن السطر الطويل قد جُزِّء لجزأين لكي يتسع في عرض الصفحة): # m h dom mon dow command 0 * * * * /usr/sbin/kdb5_util dump /var/lib/krb5kdc/dump && /usr/sbin/kprop -r EXAMPLE.COM -f /var/lib/krb5kdc/dump kdc02.example.comأنشئ ملف stash في المركز الثانوي لكي يُحفَظ به مفتاح Kerberos الرئيسي (Master Key): sudo kdb5_util stashفي النهاية، شغل عفريت krb5-kdc في المركز الثانوي: sudo service krb5-kdc startيجب أن يكون المركز الثانوي قادرًا على إعطاء البطاقات للحقل؛ يمكنك اختبار ذلك بإيقاف عفريت krb5-kdc في المركز الرئيسي؛ ثم استخدام kinit لطلب بطاقة، وإذا جرى كل شيء على ما يرام، فيجب أن تحصل على بطاقة من مركز توزيع المفاتيح الثانوي؛ عدا ذلك، تحقق من ‎/var/log/syslog و ‎/var/log/auth.log في مركز توزيع المفاتيح الثانوي. عميل Kerberos للينكسيشرح هذا القسم ضبط نظام لينُكس كعميل Kerberos؛ هذا سيسمح بالوصول إلى أيّة خدمة تستخدم Kerberos بعد أن يستطيع المستخدم تسجيل دخوله إلى النظام. التثبيتلكي يتم الاستيثاق إلى حقل Kerberos؛ فإن حزمتَيّ krb5-user و libpam-krb5 مطلوبتان؛ بالإضافة إلى غيرها من الحزم غير المطلوبة لكنها تسهل عملك؛ أدخِل الأمر الآتي في مِحَث الطرفية لتثبيت هذه الحزم: sudo apt-get install krb5-user libpam-krb5 libpam-ccreds auth-client-configتسمح حزمة auth-client-config بضبط PAM ضبطًا بسيطًا للاستيثاق من مصادر عدّة، وستُخزِّن حزمة libpam-ccreds اعتماديات الاستيثاق مما يسمح لك بتسجيل الدخول في حال لم يكن مركز توزيع المفاتيح متاحًا؛ ستفيد هذه الحزمة الحواسيب المحمولة، التي يمكن أن تستوثق باستخدام Kerberos عندما تكون في شبكة الشركة، لكنها تحتاج إلى الوصول عندما تكون خارج الشبكة أيضًا. الضبطلضبط العميل، أدخل ما يلي في الطرفية: sudo dpkg-reconfigure krb5-configسيُطلَب منك إدخال اسم حقل Kerberos؛ أيضًا إن لم لديك DNS مضبوط مع سجلات Kerberos SRV؛ فستظهر قائمة تسألك عن اسم مضيف مركز توزيع المفاتيح وخادوم إدارة الحقل. يضيف dpkg-reconfigure قيودًا إلى ملف ‎/etc/krb5.conf للحقل الخاص بك، يجب أن تحصل على قيود شبيهة بالآتي: [libdefaults] default_realm = EXAMPLE.COM ... [realms] EXAMPLE.COM = { kdc = 192.168.0.1 admin_server = 192.168.0.1 }ملاحظة: إذا ضَبطت uid لكلٍ من مستخدمي شبكتك الموثوقين ليبدأ من 5000؛ كما هو منصوح به في قسم «التثبيت» من درس OpenLDAP، فتستطيع عندها أن تخبر pam بأن يستوثق باستخدام مستخدمي Kerberos عندما يكون uid أكبر من 5000: # Kerberos should only be applied to ldap/kerberos users, not local ones. for i in common-auth common-session common-account common-password; do sudo sed -i -r \ -e 's/pam_krb5.so minimum_uid=1000/pam_krb5.so minimum_uid=5000/' \ /etc/pam.d/$i doneهذا ما سيتجنب الطلب لكلمات مرور (غير موجودة) لمستخدم موثوق محليًا عند تغيير كلمة المرور باستخدام passwd. يمكنك اختبار الضبط بطلب بطاقة باستخدام الأداة kinit، على سبيل المثال: kinit steve@EXAMPLE.COM Password for steve@EXAMPLE.COM:يمكن عرض التفاصيل عند إعطاء بطاقة باستخدام klist: klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: steve@EXAMPLE.COM Valid starting Expires Service principal 07/24/08 05:18:56 07/24/08 15:18:56 krbtgt/EXAMPLE.COM@EXAMPLE.COM renew until 07/25/08 05:18:57 Kerberos 4 ticket cache: /tmp/tkt1000 klist: You have no tickets cachedثم استخدم auth-client-config لضبط وحدة libpam-krb5 لطلب بطاقة أثناء تسجيل الدخول: sudo auth-client-config -a -p kerberos_exampleيجب أن تحصل الآن على بطاقة بعد عملية استيثاق ناجحة. مصادرللمزيد من المعلومات حول نسخة MIT من Kerberos، راجع موقع «MIT Kerberos».توجد بعض التفاصيل في صفحة ويكي أوبنتو «Kerberos».الكتاب من O'Reilly المسمى «Kerberos: The Definitive Guide» هو مرجع ممتاز أثناء ضبط Kerberos.تستطيع أيضًا القدوم إلى قناتَيّ ‎#ubuntu-server و ‎#kerberos على خادوم IRC الشهير Freenode إذا كانت لديك أسئلة حول Kerberos.ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Kerberos.

يشرح هذا الدرس دمج سامبا مع LDAP. دور خادوم سامبا هو أن يكون خادومًا قائمًا بحد ذاته، ويوفر دليل LDAP بطاقة الاستيثاق بالإضافة إلى احتواء معلومات حساب المستخدم والمجموعة والجهاز التي يتطلبها سامبا لكي يعمل (في أيٍّ من أدواره الممكنة)؛ المتطلب المسبق هو خادوم OpenLDAP مضبوط مع دليل يمكن استخدامه لطلبيات الاستيثاق؛ راجع الدرس «الإدارة عن بعد – OpenSSH» لمزيدٍ من المعلومات حول تحقيق هذا المتطلب؛ وبعد إكمال هذا الدرس، عليك تحديد ماذا تريد من سامبا أن يفعل لك، وتضبطه وفقًا لذلك. تثبيت البرمجياتهنالك ثلاث حزم مطلوبة لدمج سامبا مع LDAP: حزمة samba ،samba-doc و smbldap-tools. وإذا أردنا الدقة، فإن حزمة smbldap-tools ليست مطلوبة، لكن ما لم يكن لديك طريقة أخرى لإدارة قيود سامبا المختلفة (المستخدمين والمجموعات والحواسيب) في LDAP، فعليك تثبيتها. ثبِّت هذه الحزم الآن: sudo apt-get install samba samba-doc smbldap-toolsضبط LDAPسنضبط الآن خادوم LDAP لكي يلائم بيانات سامبا، إذ أننا سنجري ثلاث مهمات في هذا القسم: استيراد مخطط (schema).فهرسة بعض القيود.إضافة كائنات (objects).مخطط سامبالكي يُستخدَم OpenLDAP كسند خلفي (backend) لسامبا؛ فمنطقيًا يجب أن تَستخدم شجرة معلومات الدليل خاصياتٍ تستطيع وصف بيانات سامبا وصفًا سليمًا؛ و يمكن الحصول على مثل هذه الخاصيات باستخدام مخطط سامبا في LDAP؛ لنفعل ذلك الآن. ملاحظة: لمزيد من المعلومات حول المخططات وتثبيتهم، راجع القسم «تعديل قاعدة بيانات ضبط slapd» في الدرس السابق. يمكن العثور على المخطط في حزمة samba-doc التي ثبتناها الآن، لكنها تحتاج إلى أن يُفَكَّ ضغطها وتُنسَخ إلى مجلد ‎/etc/ldap/schema: sudo cp /usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz /etc/ldap/schema sudo gzip -d /etc/ldap/schema/samba.schema.gzاحصل على ملف الضبط schema_convert.conf الذي يحتوي على الأسطر الآتية: include /etc/ldap/schema/core.schema include /etc/ldap/schema/collective.schema include /etc/ldap/schema/corba.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/duaconf.schema include /etc/ldap/schema/dyngroup.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/java.schema include /etc/ldap/schema/misc.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/openldap.schema include /etc/ldap/schema/ppolicy.schema include /etc/ldap/schema/ldapns.schema include /etc/ldap/schema/pmi.schema include /etc/ldap/schema/samba.schemaاحصل على مجلد ldif_output لكي يُبقي على المخرجات. حدد فهرس المخطط: slapcat -f schema_convert.conf -F ldif_output -n 0 | grep samba,cn=schema dn: cn={14}samba,cn=schema,cn=configحوِّل المخطط إلى صيغة LDIF: slapcat -f schema_convert.conf -F ldif_output -n0 -H \ ldap:///cn={14}samba,cn=schema,cn=config -l cn=samba.ldifعدِّل ملف cn=samba.ldif المولَّد بحذف معلومات الفهرس حتى تصل إلى: dn: cn=samba,cn=schema,cn=config ... cn: sambaاحذف الأسطر في الأسفل: structuralObjectClass: olcSchemaConfig entryUUID: b53b75ca-083f-102d-9fff-2f64fd123c95 creatorsName: cn=config createTimestamp: 20080827045234Z entryCSN: 20080827045234.341425Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20080827045234Zستختلف قيم خاصياتك. أضف المخطط الجديد: sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f cn\=samba.ldifولطلب وإظهار المخطط الجديد: sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=schema,cn=config \ 'cn=*samba*'فهارس سامبايعرف الآن slapd عن خاصيات سامبا، لنضبط الآن بعض الفهارس (indices) بناءً عليها؛ فهرسة المدخلات هي طريقة لزيادة الأداء عندما يُجرِي العميل بحثًا مُرشَّحًا على شجرة معلومات الدليل. أنشِئ الملف samba_indices.ldif بالمحتويات الآتية: dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbIndex: loginShell eq olcDbIndex: uid eq,pres,sub olcDbIndex: memberUid eq,pres,sub olcDbIndex: uniqueMember eq,pres olcDbIndex: sambaSID eq olcDbIndex: sambaPrimaryGroupSID eq olcDbIndex: sambaGroupType eq olcDbIndex: sambaSIDList eq olcDbIndex: sambaDomainName eq olcDbIndex: default subاستخدم الأداة ldapmodify لتحميل الفهارس الجديدة: sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f samba_indices.ldifإذا جرى كل شيء على ما يرام، فيجب أن تشاهد الفهارس الجديدة باستخدام ldapsearch: sudo ldapsearch -Q -LLL -Y EXTERNAL -H \ ldapi:/// -b cn=config olcDatabase={1}hdb olcDbIndexإضافة كائنات LDAP لسامباتاليًا، اضبط حزمة smbldap-tools لمطابقة بيئتك؛ تأتي هذه الحزمة مع ملف ضبط سيسأل بعض الأسئلة عن الخيارات الضرورية (اسمه smbldap-config.pl، وكان اسمه فيما مضى configure.pl)؛ لكن هنالك علِّة1 ليست مثبتة لكنه موجودة في الكود المصدري (apt-get source smbldap-tools). لضبط الحزمة يدويًا، عليك إنشاء وتعديل ملفَيّ ‎/etc/smbldap-tools/smbldap.conf و ‎/etc/smbldap-tools/smbldap_bind.conf. سيضيف سكربت smbldap-populate كائنات LDAP اللازمة لعمل سامبا؛ من الجيد عادةً أن تأخذ نسخةً احتياطيةً من كامل الدليل باستخدام slapcat: sudo slapcat -l backup.ldifأكمل بإملاء الدليل بعد أخذك لنسخةٍ احتياطيةٍ منه: sudo smbldap-populateتستطيع إنشاء ملف LDIF يحتوي كائنات سامبا الجديدة بتنفيذ الأمر: sudo smbldap-populate -e samba.ldifوهذا سيسمح لك بمعاينة التعديلات والتأكد من أن كل شيء صحيح؛ ثم نفِّذ السكربت لكن بدون الخيار ‎-e؛ أو تستطيع أخذ ملف LDIF واستيراد بياناته كالمعتاد. يجب أن يملك دليل LDAP الآن المعلومات الضرورية للاستيثاق من مستخدمي سامبا. ضبط سامباهنالك عدّة طرق لضبط سامبا، التي سنشرحها في هذه السلسلة لاحقًا؛ لتضبط سامبا ليستخدم LDAP، فعدِّل الملف ‎/etc/samba/smb.conf وأزل التعليق قبل معامل passdb backend وأضف بعض معاملات ldap: # passdb backend = tdbsam # LDAP Settings passdb backend = ldapsam:ldap://hostname ldap suffix = dc=example,dc=com ldap user suffix = ou=People ldap group suffix = ou=Groups ldap machine suffix = ou=Computers ldap idmap suffix = ou=Idmap ldap admin dn = cn=admin,dc=example,dc=com ldap ssl = start tls ldap passwd sync = yes ... add machine script = sudo /usr/sbin/smbldap-useradd -t 0 -w "%u"عدِّل القيم لتطابق بيئتك. أعد تشغيل خدمة samba لتفعيل الإعدادات الجديدة: sudo restart smbd sudo restart nmbdأخبر سامبا الآن عن كلمة مرور rootDN (تلك التي ضُبِطَت أثناء تثبيت حزمة slapd): sudo smbpasswd -w passwordإذا كان لديك مستخدم LDAP موجود مسبقًا، وأردت تضمينه في سامبا، فستحتاج لإضافة بعض الخاصيات؛ تَفعَل أداة smbpasswd هذا أيضًا (يجب أن يقدر المضيف على رؤية [أو سرد] هؤلاء المستخدمين عبر NSS؛ ثَبِّت واضبط إما libnss-ldapd أو libnss-ldap): sudo smbpasswd -a usernameسيُطلَب منك إدخال كلمة المرور، وستُعتبَر هي كلمة المرور الجديدة لهذا المستخدم. لإدارة حسابات المستخدم والمجموعة والجهاز، فاستخدم الأدوات الموفرة من حزمة smbldap-tools؛ هذه بعض الأمثلة: إضافة مستخدم جديد: sudo smbldap-useradd -a -P usernameيضيف الخيار ‎-a خاصيات سامبا، ويستدعي الخيار ‎-P الأداة smbldap-passwd بعد إنشاء المستخدم مما يسمح لك بإدخال كلمة مرور لذاك المستخدم. لإزالة مستخدم: sudo smbldap-userdel usernameاستُخدِم الخيار ‎-r في الأمر السابق لحذف مجلد المنزل للمستخدم المحدد. لإضافة مجموعة:sudo smbldap-groupadd -a groupnameوكما في الأمر smbldap-useradd، يضيف الخيار ‎-a خاصيات سامبا. لإنشاء مستخدم جديد ويكون عضوًا في مجموعة:sudo smbldap-groupmod -m username groupnameيمكن أن يضيف الخيار ‎-m أكثر من مستخدم في نفس الوقت بسردهم مفصولًا بينهم بفاصلة. لحذف مستخدم من مجموعة:sudo smbldap-groupmod -x username groupnameلإضافة حساب جهاز في سامبا:sudo smbldap-useradd -t 0 -w usernameاستبدل username باسم محطة العمل (workstation)، يُنشِئ الخيار ‎-t 0 حساب جهاز بدون تأخير، بينما يحدد الخيار ‎-w الحساب كحساب جهاز؛ لاحظ أيضًا أن معامل add machine script في ‎/etc/samba/smb.conf قد غُيِّر لكي يستخدم smbldap-useradd. هذه هي الأدوات في حزمة smbldap-tools التي لم نشرحها هنا: smbldap-groupaddsmbldap-groupdelsmbldap-groupmodsmbldap-groupshowsmbldap-passwdsmbldap-populatesmbldap-useraddsmbldap-userdelsmbldap-userinfosmbldap-userlistsmbldap-usermodsmbldap-usershowمصادرهنالك عدّة أماكن وثِّق فيها LDAP مع سامبا في «Samba HOWTO Collection».على الرغم من أن هذه الصفحة قديمة (2007) لكن صفحة «Linux Samba-OpenLDAP HOWTO» تحتوي ملاحظات مهمة.الصفحة الرئيسية «Samba Ubuntu community documentation» فيها مجموعة من الوصلات للمقالات المفيدة.ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Samba and LDAP.

تعرفنا في المقالين السابقين على كيفية تثبيت وضبط خادوم OpenLDAP على أوبنتو و كيفية القيام بعملية التناسخ لتفادي توقف الخادوم. استيثاق LDAPبعد أن أصبح عندك خادوم LDAP يعمل جيدًا، فستحتاج إلى تثبيت مكتبات على جهاز العميل التي تعلم كيف ومتى عليها أن تتصل إلى الخادوم؛ يتم ذلك في أوبنتو تقليديًا بتثبيت حزمة libnss-ldap؛ ستجلب هذه الحزمة أدواتٍ أخرى، وستساعدك في خطوة الضبط؛ ثبت الآن الحزمة: sudo apt-get install libnss-ldapستُسأل عن معلوماتٍ حول خادوم LDAP؛ إذا ارتكبت خطأً هنا، فتستطيع المحاولة مرة أخرى بالأمر: sudo dpkg-reconfigure ldap-auth-configستظهر نتائج مربع الحوار السابق في ملف ‎/etc/ldap.conf، إذا تطلَّب الخادوم خياراتٍ غير موجودة في القائمة، فعليك تعديل هذا الملف وفقًا لها. اضبط LDAP لاستخدامه مع NSS: sudo auth-client-config -t nss -p lac_ldapاضبط النظام لاستخدام LDAP للاستيثاق: sudo pam-auth-updateاختر LDAP وأيّة آليات استيثاق أخرى قد تحتاج لها من القائمة. تستطيع الآن تسجيل الدخول بتصاريح مبنية على LDAP. سيحتاج عملاء LDAP إلى الإشارة إلى عدّة خواديم إذا اُستخدِم الاستنساخ؛ يجب أن تضع شيئًا شبيهًا بالسطر الآتي في ملف ‎/‎etc/ldap.conf: uri ldap://ldap01.example.com ldap://ldap02.example.comإذا نَفِذَت مهلة (timeout) الطلب، فسيحاول العميل الوصول إلى المستهلك (ldap02) إذا لم يستجيب المزود (ldap01). إذا كنت تريد استخدام LDAP لتخزين مستخدمي سامبا، فإن عليك ضبط سامبا ليستوثق عبر LDAP، وسنشرح ذلك في الدرس القادم. ملاحظة: بديل عن حزمة libnss-ldap هي حزمة libnss-ldapd؛ التي ستجلب معها حزمة nscd الذي قد لا نرغب فيها؛ احذفها ببساطة بعد التثبيت. إدارة المستخدمين والمجموعاتتأتي حزمة ldap-utils مع أدوات كافية لإدارة الدليل، لكن السلسلة الكبيرة من الإعدادات المطلوبة قد تصعِّب استخدامها؛ تحتوي حزمة ldapscripts على سكربتات متعلقة بهذه الأدوات التي يجدها بعض الأشخاص أسهل في الاستخدام. ثبِّت الحزمة: sudo apt-get install ldapscriptsثم عدِّل الملف ‎/etc/ldapscripts/ldapscripts.conf حتى يصبح شبيهًا بالآتي: SERVER=localhost BINDDN='cn=admin,dc=example,dc=com' BINDPWDFILE="/etc/ldapscripts/ldapscripts.passwd" SUFFIX='dc=example,dc=com' GSUFFIX='ou=Groups' USUFFIX='ou=People' MSUFFIX='ou=Computers' GIDSTART=10000 UIDSTART=10000 MIDSTART=10000أنشِئ الآن الملف ldapscripts.passwd لكي يستطيع rootDN الوصول إلى الدليل: sudo sh -c "echo -n 'secret' > /etc/ldapscripts/ldapscripts.passwd" sudo chmod 400 /etc/ldapscripts/ldapscripts.passwdملاحظة: ضع كلمة المرور الخاصة بمستخدم rootDN بدلًا من «secret». أصبحت السكربتات جاهزةً لإدارة دليلك؛ هذه بضعة أمثلة حول طريقة استخدامها: إنشاء مستخدم جديد: sudo ldapadduser george exampleهذا ما سيُنشِئ مستخدمًا بمعرِّف george ويضبط مجموعة المستخدم الرئيسية إلى example. تغيير كلمة مرور المستخدم: sudo ldapsetpasswd george Changing password for user uid=george,ou=People,dc=example,dc=com New Password: New Password (verify):حذف مستخدم: sudo ldapdeleteuser georgeإضافة مجموعة: sudo ldapaddgroup qaحذف مجموعة: sudo ldapdeletegroup qaإضافة مستخدم إلى مجموعة: sudo ldapaddusertogroup george qaعليك أن ترى الآن خاصية memberUid لمجموعة qa ذات القيمة george. إزالة مستخدم من مجموعة: sudo ldapdeleteuserfromgroup george qaيجب أن تزال الآن الخاصية memberUid من المجموعة qa. يسمح لك سكربت ldapmodifyuser بإضافة أو حذف أو استبدل خاصيات المستخدم؛ يستخدم هذا السكربت البنية العامة لأداة ldapmodify، على سبيل المثال: sudo ldapmodifyuser george # About to modify the following entry : dn: uid=george,ou=People,dc=example,dc=com objectClass: account objectClass: posixAccount cn: george uid: george uidNumber: 1001 gidNumber: 1001 homeDirectory: /home/george loginShell: /bin/bash gecos: george description: User account userPassword:: e1NTSEF9eXFsTFcyWlhwWkF1eGUybVdFWHZKRzJVMjFTSG9vcHk= # Enter your modifications here, end with CTRL-D. dn: uid=george,ou=People,dc=example,dc=com replace: gecos gecos: George Carlinيجب أن يصبح الآن المستخدم gecos باسم «George Carlin». ميزة جميلة من ميزات ldapscripts هو نظام القوالب؛ تسمح لك القوالب بتخصيص خاصيات المستخدم، والمجموعة، وكائنات الجهاز؛ فعلى سبيل المثال، لتفعيل قالب user، عدِّل الملف ‎/etc/ldapscripts/ldapscripts.conf مغيّرًا: UTEMPLATE="/etc/ldapscripts/ldapadduser.template"هنالك عينات عن القوالب في مجلد ‎/etc/ldapscripts، انسخ أو أعد تسمية ملف ldapadduser.template.sample إلى ‎/etc/ldapscripts/ldapadduser.template: sudo cp /usr/share/doc/ldapscripts/examples/ldapadduser.template.sample \ /etc/ldapscripts/ldapadduser.templateعدِّل القالب الجديد ليضيف الخاصيات التي تريدها؛ سيُنشِئ ما يلي مستخدمين جدد بقيمة inetOrgPerson للخاصية objectClass: dn: uid=<user>,<usuffix>,<suffix> objectClass: inetOrgPerson objectClass: posixAccount cn: <user> sn: <ask> uid: <user> uidNumber: <uid> gidNumber: <gid> homeDirectory: <home> loginShell: <shell> gecos: <user> description: User account title: Employeeلاحظ القيمة <ask> المُستخدَمة للخاصية sn؛ وهي ما سيجعل ldapadduser يسألك عن قيمتها. هنالك أدوات في هذه الحزمة لم نشرحها هنا، هذه هي قائمةٌ كاملةٌ بها: ldaprenamemachine ldapadduser ldapdeleteuserfromgroup ldapfinger ldapid ldapgid ldapmodifyuser ldaprenameuser lsldap ldapaddusertogroup ldapsetpasswd ldapinit ldapaddgroup ldapdeletegroup ldapmodifygroup ldapdeletemachine ldaprenamegroup ldapaddmachine ldapmodifymachine ldapsetprimarygroup ldapdeleteuserالنسخ الاحتياطي والاسترجاعالآن يجب أن يعمل LDAP كما نريده تمامًا، فحان الآن الوقت للتحقق من أن عملنا يمكن أن يُستَرجَع وقت الحاجة. كل ما نحتاج هو طريقة لنسخ قاعدة بيانات ldap احتياطيًا، وخصوصًا السند الخلفي (backend التي هي cn=config) والواجهة الأمامية (frontend التي هي dc=example,dc=com)؛ إذا كنت ستنسخ هذه القواعد نسخًا احتياطيًا إلى- ولِنَقُل- ‎/export/backup، فإننا سنستخدم slapcat كما هو موضَّح في السكربت الآتي المدعو ‎/usr/local/bin/ldapbackup: #!/bin/bash BACKUP_PATH=/export/backup SLAPCAT=/usr/sbin/slapcat nice ${SLAPCAT} -n 0 > ${BACKUP_PATH}/config.ldif nice ${SLAPCAT} -n 1 > ${BACKUP_PATH}/example.com.ldif nice ${SLAPCAT} -n 2 > ${BACKUP_PATH}/access.ldif chmod 640 ${BACKUP_PATH}/*.ldifملاحظة: هذه الملفات هي ملفات نصية غير مضغوطة تحتوي كل شيء في قواعد بيانات LDAP بما فيها مخطط الشجرة، وأسماء المستخدمين، وكل كلمات المرور؛ لذلك ربما تفكر في جعل ‎/export/backup قسمًا مشفرًا؛ وحتى كتابة سكربت يشفر هذه الملفات عند إنشائها، وربما تفعل كلا الأمرين، ولكن ذلك متعلقٌ بمتطلبات الأمن في نظامك. كل ما يلزم الآن هو الحصول على سكربت مهام مجدولة (cron) لتشغيل هذا البرنامج كل فترة زمنية (ترى أنها مناسبة)؛ سيكون ملائمًا للكثيرين جدولة تنفيذ البرنامج مرة واحدة كل يوم؛ لكن قد يحتاج الآخرون إلى مراتٍ أكثر في اليوم؛ هذا مثال عن سكربت cron مدعو ‎/etc/cron.d/ldapbackup، والذي سيعمل كل ليلة في تمام الساعة 22:45: MAILTO=backup-emails@domain.com 45 22 * * * root /usr/local/bin/ldapbackupوبعد إنشاء الملفات، يجب نقلها لخادوم النسخ الاحتياطي. وعلى فرض أنك أعدت تثبيت ldap، فإن عملية الاسترجاع ستكون شبيهةً بما يلي: sudo service slapd stop sudo mkdir /var/lib/ldap/accesslog sudo slapadd -F /etc/ldap/slapd.d -n 0 -l /export/backup/config.ldif sudo slapadd -F /etc/ldap/slapd.d -n 1 -l /export/backup/domain.com.ldif sudo slapadd -F /etc/ldap/slapd.d -n 2 -l /export/backup/access.ldif sudo chown -R openldap:openldap /etc/ldap/slapd.d/ sudo chown -R openldap:openldap /var/lib/ldap/ sudo service slapd startمصادرالمصدر الأساسي هو توثيق www.openldap.org.هنالك الكثير من صفحات الدليل للحزمة slapd؛ هذه أهمها آخذين بعين الاعتبار المعلومات المقدمة في هذا الفصل:man slapd man slapd-config man slapd.access man slapo-syncprovصفحات الدليل الأخرى: man auth-client-config man pam-auth-updateصفحة ويكي مجتمع أوبنتو «OpenLDAP» تحتوي مجموعةً من الملاحظات.كتاب O'Reilly المدعو «LDAP System Administration».كتاب Packt المدعو «Mastering OpenLDAP».ترجمة -وبتصرف- للمقال Ubuntu Server Guide: OpenLDAP Server.

إنّ عامل الاستيثاق authentication factor هو جزء من المعلومات يُستخدَم لإثبات أنّه لدينا الحق لتنفيذ إجراء ما، مثل تسجيل الدخول إلى النّظام، وقناة الاستيثاق authentication channel هي الطّريقة التي يُوصِل بها نظام الاستيثاق عاملًا factor للمستخدم أو الطّريقة التي يطلب بها من المستخدم الرّد، من الأمثلة على عوامل الاستيثاق نجد كلمات السّر ورموز الأمان security tokens، ومن الأمثلة على قنوات الاستيثاق نجد الحواسيب والهواتف المحمولة. تستخدم SSH افتراضيًّا كلمات السّر من أجل الاستيثاق، وتُوصي تعليمات SSH باستخدام مفتاح SSH key بدلًا من ذلك، على أيّة حال يبقى هذا عاملًا واحدًا فقط، فإن تمّ تهديد الحاسوب لدينا من قبل شخص ما، فبإمكانه استخدام مفتاحنا لتهديد خواديمنا أيضًا. لمكافحة هذا سنقوم في هذا الدّرس بإعداد استيثاق مُتعدِّد العوامل (Multi-factor authentication (MFA، والذي يتطلّب أكثر من عامل من أجل الاستيثاق أو تسجيل الدّخول، وهذا يعني أنّه يجب على المُخترِق أن يُهدِّد عدّة أشياء، مثل حاسوبنا وهاتفنا المحمول معًا لكي يستطيع الدخول، يتم عادةً تلخيص أنواع العوامل المختلفة كما يلي: شيء نعرفه، مثل كلمة سر أو سؤال أمانشيء نملكه، مثل تطبيق استيثاق أو رمز أمان security tokenشيء نكون نحن عليه، مثل بصمة الأصابع أو الصوتمن العوامل الشائعة تطبيق OATH-TOTP مثل Google Authenticator، إنّ (OATH-TOTP (Open Authentication Time-Based One-Time Password الاستيثاق المفتوح لكلمة سر لمرّة واحد مُعتمِدة على الزمن هو عبارة عن ميثاق protocol مفتوح يقوم بتوليد كلمة سر صالحة للاستخدام لمرّة واحدة تكون عادةً عددًا من 6 أرقام يتم تجديده كل 30 ثانية. سيشرح هذا الدّرس كيفيّة تمكين استيثاق SSH باستخدام تطبيق OATH-TOTP بالإضافة لمفتاح SSH ، حيث سيتطلّب تسجيل الدخول إلى خادومنا عبر SSH عاملين اثنين عبر قناتين ممّا يجعله أكثر أمانًا من كلمة السّر أو مفتاح SSH لوحدهما. المتطلبات الأساسيةسنحتاج لمتابعة هذا الدّرس إلى: خادوم Ubuntu 14.04.مستخدم sudo غير جذري non-root مع إضافة مفتاح SSH، والذي نستطيع إعداده باتّباع درس الإعداد الابتدائي لخادوم أوبنتو 14.04.هاتف ذكي أو لوحي tablet مُثبَّت عليه تطبيق OATH-TOTP مثل Google Authenticator (روابط تنزيله من أجل Android و iOS).الخطوة الأولى – تثبيت libpam-google-authenticatorسنقوم في هذه الخطوة بتثبيت وإعداد PAM الخاصّة بـ Google. إنّ PAM، والتي ترمز إلى وحدة الاستيثاق القابلة للإضافة Pluggable Authentication Module، هي عبارة عن بنية تحتيّة للاستيثاق تُستَخدم على أنظمة لينِكس من أجل استيثاق المستخدمين، ولأنّ Google صنعت تطبيق OATH-TOTP فقد قامت أيضًا بإنشاء PAM تقوم بتوليد TOTPs ومتوافقة بشكل كامل مع أي تطبيق OATH-TOTP. نقوم في البداية بتحديث الذاكرة المؤقتة cache لمستودع Ubuntu: sudo apt-get updateنُثبِّت بعدها PAM: sudo apt-get install libpam-google-authenticatorوبعد تثبيت PAM سنستخدم تطبيق مُساعِد يتم تثبيته مع PAM لتوليد مفتاح TOTP للمستخدم الذي نرغب بإضافة عامل ثانٍ له، يتم توليد هذا المفتاح للمستخدم على أساس المستخدم وليس على أساس النّظام، ويعني هذا أنّ كل مستخدم يريد استعمال تطبيق استيثاق TOTP سيحتاج لتسجيل الدخول وتشغيل التطبيق المُساعِد للحصول على المفتاح الخاص به: google-authenticatorبعد تنفيذ الأمر سيتم سؤالنا عدّة أسئلة، يطلب السؤال الأول معرفة إذا ما كان يجب أن تكون رموز الاستيثاق authentication tokens على أساس زمني. يسمح PAM هذا برموز على أساس زمني time-based أو على أساس تتابعي sequential-based، يعني استخدام رموز على أساس تتابعي أنّ الشيفرة code تبدأ في نقطة مُعيّنة وبعدها تقوم بزيادة الشيفرة بعد كل استخدام، ويعني استخدام رموز على أساس زمني أنّ الشيفرة تتغير بشكل عشوائي بعد انقضاء وقت مُحدّد، سنختار الرموز على أساس زمني لأنّ هذا ما تتوقعه تطبيقات مثل Google Authenticator، لذا نجيبه بنعم: Do you want authentication tokens to be time-based (y/n) yبعد الإجابة على هذا السؤال سيتم تمرير الكثير من الخَرْج output، ومن ضمنه شيفرة QR كبيرة، تأكّد من تسجيلك للمفتاح السّري secret key، شيفرة التحقيق verification code، وشيفرات البداية في حالات الطوارئ emergency scratch codes في مكان آمن مثل مُدير كلمات السّر. عند هذه النقطة نستخدم تطبيق الاستيثاق authenticator الموجود على هاتفنا لمسح scan شيفرة QR أو نكتب يدويًّا المفتاح السّري، إن كانت شيفرة QR كبيرة جدًّا لمسحها نستطيع استخدام الرابط الموجود أعلاها للحصول على نسخة أصغر منها، حالما تتم إضافتها سنرى رمزًا مُكوَّنًا من 6 أرقام يتغيّر كل 30 ثانية في تطبيقنا. تقوم بقيّة الأسئلة بإعلام PAM كيف يعمل، سنمر عليها واحدًا تلو الآخر: Do you want me to update your "~/.google_authenticator" file (y/n) yيقوم هذا بشكل أساسي بكتابة المفتاح والخيارات إلى الملف google_authenticator.، إن قلنا "لا" سيخرج البرنامج ولن تتم كتابة أي شيء، والذي يعني أنّ تطبيق الاستيثاق authenticator لن يعمل. Do you want to disallow multiple uses of the same authentication token? This restricts you to one login about every 30s, but it increases your chances to notice or even prevent man-in-the-middle attacks (y/n) yنمنع عندما نجيب على هذا السؤال بنعم هجمات الإعادة replay attack بأن نجعل كل رمز تنتهي صلاحيّته مباشرة بعد استخدامه، وهذا يمنع المُهاجِم من التقاط الرّمز الذي استخدمناه للتو وتسجيل الدخول به. By default, tokens are good for 30 seconds and in order to compensate for possible time-skew between the client and the server, we allow an extra token before and after the current time. If you experience problems with poor time synchronization, you can increase the window from its default size of 1:30min to about 4min. Do you want to do so (y/n) nتسمح إجابة نعم هنا بثمانية رموز صالحة خلال فترة 4 دقائق، وبإجابتنا "لا" نقوم بتحديدها إلى 3 رموز صالحة خلال فترة 1:30 دقيقة، إن لم تكن لديك مشكلة مع هذه الفترة فالإجابة "لا" هنا هي الخيارة الأكثر أمانًا. If the computer that you are logging into isn't hardened against brute-force login attempts, you can enable rate-limiting for the authentication module. By default, this limits attackers to no more than 3 login attempts every 30s. Do you want to enable rate-limiting (y/n) yيعني تحديد المُعدَّل Rate limiting أنّ المُهاجِم البعيد يستطيع فقط أن يحاول عدد مُحدَّد من التخمينات قبل أن يتم حظره، إن لم نقم مُسبقًا بإعداد تحديد المُعدَّل بشكل مباشر داخل SSH فإنّ فعل هذا هنا هو تقنية رائعة. الخطوة الثانية – إعداد OpenSSHإنّ الخطوة التالية الآن هي إعداد SSH لاستخدام مفتاح TOTP لدينا، سنحتاج أن نخبر SSH عن PAM ومن ثم نقوم بإعداد SSH لاستخدامه. نفتح أولًا ملف الإعدادات sshd لتحرير باستخدام nano أو مُحرِّر النصوص المُفضَّل لدينا: sudo nano /etc/pam.d/sshdنضيف السطر التالي إلى نهاية الملف: . . \# Standard Un*x password updating. @include common-password auth required pam_google_authenticator.so nullokتُخبِر الكلمة "nullok" الموجودة في النهاية PAM أنّ طريقة الاستيثاق هذه اختياريّة، فيسمح هذا للمستخدمين الذين لا يملكون مفتاح OATH-TOTP أن يظلّوا قادرين على تسجيل الدخول باستخدام مفتاح SSH الخاص بهم، أمّا إن كان جميع المستخدمين يملكون مفتاح OATH-TOTP فنستطيع حذف "nullok" من هذا السّطر لجعل الاستيثاق مُتعدِّد العوامل MFA إجباريًّا. نحفظ ونغلق الملف. نقوم بعدها بإعداد SSH ليدعم هذا النوع من الاستيثاق، نفتح ملف إعدادات SSH لتحريره: sudo nano /etc/ssh/sshd_configنبحث عن ChallengeResponseAuthentication ونعيّن قيمتها إلى yes: . . . \# Change to yes to enable challenge-response passwords (beware issues with \# some PAM modules and threads) ChallengeResponseAuthentication yes . . .نحفظ ونغلق الملف، ونعيد تشغيل SSH لإعادة تحميل ملفّات الإعدادات: sudo service ssh restartالخطوة الثالثة – جعل SSH على علم بالاستيثاق مُتعدد العوامل MFAسنختبر في هذه الخطوة إذا ما كان مفتاح SSH يعمل. نفتح أولًا طرفيّة terminal أخرى ونحاول الدخول عبر SSH إلى الخادوم، سنلاحظ أنّنا سجلّنا الدخول إلى هذه الجلسة الثانية باستخدام مفتاح SSH الخاص بنا بدون إدخال شيفرة التحقيق أو كلمة السّر، حدث هذا لأنّ مفتاح SSH يقوم بشكل افتراضي بتجاوز جميع خيارات الاستيثاق الأخرى، نحتاج أن نُخبِر SSH أن يستخدم شيفرة TOTP ومفتاح SSH بدلًا من كلمة السر. نفتح الآن ملف الإعدادات sshd مرّة أخرى: sudo nano /etc/ssh/sshd_configنبحث عن السطر PasswordAuthentication ونزيل التعليق عنه بحذف الحرف # في بداية السّطر ونقوم بتحديث قيمته إلى no، يُخبِر هذا SSH ألّا يقوم بالسؤال عن كلمة السّر. . . . \# Change to no to disable tunnelled clear text passwords PasswordAuthentication no . . .نضيف بعد ذلك السطر التالي إلى أسفل الملف، والذي يُخبِر SSH ما هي طرق الاستيثاق المطلوبة: . . . UsePAM yes AuthenticationMethods publickey,keyboard-interactiveنحفظ ونغلق الملف. نفتح بعدها ملف إعدادات PAM sshd: sudo nano /etc/pam.d/sshdنقوم بإيجاد السطر include common-auth@ وجعله كتعليق بإضافة الحرف # كالحرف الأول في هذا السطر، يُخبِر هذا PAM ألّا تسأل عن كلمة السر، وقد قمنا سابقًا بإخبار SSH ألّا تفعل هذا في sshd_config: . . . # Standard Un*x authentication. #@include common-auth . . .نحفظ ونغلق الملف ومن ثم نعيد تشغيل SSH: sudo service ssh restartنحاول الآن تسجيل الدخول إلى الخادوم مرّة أخرى، ينبغي أن نرى أنّنا قمنا بالاستيثاق بشكل جزئي باستخدام مفتاح SSH الخاص بنا ومن ثمّ حصلنا على مُحِث prompt من أجل شيفرة التحقيق verification code، والذي سيبدو مشابهًا لما يلي: ssh sammy@your_server_ip Authenticated with partial success. Verification code:نُدخِل شيفرة التحقيق من تطبيق OAUTH-TOTP لدينا، وسيتم تسجيل دخولنا إلى الخادوم، نمتلك الآن الاستيثاق مُتعدِّد العوامل MFA مُمكَّنًا من أجل SSH. الخاتمةوكما يحدث مع أي نظام نقوم بتمنيعه وتأمينه سنصبح مسؤولين عن إدارة هذا الأمان، ويعني هذا في هذه الحالة عدم فقدان مفتاح SSH الخاص بنا أو مفتاح أمان TOTP، ومع ذلك قد يحدث هذا في بعض الأحيان ونفقد التحكّم بالمفاتيح التي تجعلنا نُسجِّل الدخول. نجد هنا بعض الاقتراحات لاستعادة النفاذ إلى خادومنا: إن فقدنا تطبيق TOTP أو لم نعد نملك نفاذًا إليه، نستخدم شيفرات الاستعادة recovery codes كشيفرة للتحقيق، قد يحدث هذا إن اشترينا هاتفًا جديدًا ونسينا تصدير مفاتيحنا من الهاتف القديم، أو نفذت بطارية هاتفنا.إن فقدنا مفتاح الأمان secret key والنسخة الاحتياطية، نقوم بإعادة تسمية أو حذف الملف google_authenticator./~، حيث يحرص هذا ألّا تعود PAM على معرفة بإعداداتنا وألّا تطلب منّا الرمز، تأكّد من أنّ الملف etc/pam.d/sshd/ لا زال يملك "nullok" في آخره، مثل الخطوة الثانية، وإن غيّرنا هذا نقوم بإعادة تشغيل SSH.إن فقدنا مفتاح SSH الخاص بنا، نقوم بإزالة المفتاح العام القديم من ssh/authorized_hosts./~، ونستبدله بمفتاح جديد.بامتلاك عاملين (مفتاح SSH+رمز MFA token) عبر قناتين اثنتين (حاسوبنا+هاتفنا المحمول) جعلنا من المستحيل تقريبًا لأي عميل خارجي أن يشقّ طريقه بالقوة القاسية brute force إلى داخل جهازنا عبر SSH وقمنا بزيادة أمان جهازنا بشكل رائع. ترجمة -وبتصرّف- لـ How To Set Up Multi-Factor Authentication for SSH on Ubuntu 14.04 لصاحبه Michael Holley.

عند إعداد خادوم ويب توجد غالبًا أقسام من الموقع نرغب بتقييد الوصول إليها، تُوفِّر تطبيقات الويب عادةً طرق التصريح authorization والاستيثاق authentication الخاصّة بها، ولكن يُمكِن استخدام خادوم الويب بذاته لتقييد الوصول إن كانت هذه الطّرق غير كافية أو غير متوفّرة. سنشرح في هذا الدّرس كيف نحمي الممتلكات assets باستخدام كلمة سر على خادوم ويب Apache يعمل على Ubuntu. المتطلبات الأساسيةنحتاج للوصول إلى بيئة خادوم Ubuntu لكي نبدأ، نحتاج أيضًا لمستخدم غير جذري non-root مع صلاحيّات sudo من أجل تنفيذ مهام إداريّة administrative، لكي تتعلّم كيفيّة إعداد مستخدم بامتيازات sudo اتبع دليلنا للإعداد الأولي لخادوم Ubuntu 14.04. تثبيت حزمة أدوات Apache المساعدةسنستخدم أداة مُساعِدة utility تُدعى htpasswd من أجل إنشاء الملف الذي يقوم بتخزين كلمات السّر التي نحتاجها للوصول إلى المحتوى المُقيَّد لدينا، تُوجَد هذه الأداة في الحِزمة apache2-utils داخل المستودعات repositories في Ubuntu. نُحدِّث الذاكرة المؤقتة cache للحِزَم المحليّة ونُثبِّت الحِزمَة بكتابة هذا الأمر، سننتهز الفرصة أيضًا لتثبيت خادوم Apache2 في حال لم يكن مُثبّتًا لديك: sudo apt-get update sudo apt-get install apache2 apache2-utilsإنشاء ملف كلمات السرنستطيع الآن الوصول للأمر htpasswd واستخدامه لإنشاء ملف كلمات السّر والذي يستعمله خادوم Apache لاستيثاق authenticate المستخدمين، سنقوم بإنشاء ملف مخفي لهذا الغرض يُدعى htpasswd. بداخل دليل الإعدادات etc/apache2/. عند استخدام هذه الأداة لأوّل مرّة نحتاج لإضافة الخيار c- لإنشاء الملف المُحدَّد، نقوم بتحديد اسم مستخدم (في هذا المثال sammy) في نهاية الأمر لإنشاء مُدخَل جديد بداخل الملف: sudo htpasswd -c /etc/apache2/.htpasswd sammyسيتم سؤالنا عن تزويد كلمة سر وتأكيدها للمستخدم. نترك الوسيط c- لأي مستخدمين آخرين نرغب في إضافتهم: sudo htpasswd /etc/apache2/.htpasswd another_userإن قمنا بمشاهدة محتويات الملف نستطيع رؤية اسم المستخدم وكلمة السّر المُشفّرة لكل تسجيل record: cat /etc/apache2/.htpasswdsammy:$apr1$lzxsIfXG$tmCvCfb49vpPFwKGVsuYz. another_user:$apr1$p1E9MeAf$kiAhneUwr.MhAE2kKGYHK.إعداد استيثاق كلمة السر لخادوم Apacheالآن وبعد أن أصبحنا نمتلك ملف لأسماء المستخدمين وكلمات السّر في صيغة يستطيع خادوم Apache قراءتها، نحتاج لإعداد Apache لكي يتفحّص هذا الملف قبل تخديم محتوانا المحمي، بإمكاننا فعل هذا بطريقتين مختلفتين. الخيار الأول هو تحرير edit إعدادات Apache وإضافة حماية كلمة السّر إلى ملف المضيف الافتراضي virtual host file. يُعطينا هذا الخيار أداء أفضل بشكل عام لأنّه يتجنّب تكلفة قراءة ملفات إعدادات مُوزَّعة، إن كنت تملك هذا الخيار فإنّنا ننصح بهذا الأسلوب. إن لم تكن لدينا القدرة على تعديل ملف المضيف الافتراضي (أو كنّنا نستخدم مُسبقًا ملفات htaccess. لأغراض أخرى) نستطيع تقييد النفاذ باستخدام ملف htaccess.، يستخدم Apache ملفّات htaccess. من أجل السّماح لتعيين بعض عناصر الإعدادات داخل ملف في دليل المحتوى. العيب في هذا هو أنّه يجب على Apache إعادة قراءة هذه الملفّات عند كل طلب يتضمّن هذا الدّليل ممّا قد يؤثر على الأداء. اختر الخيار الذي يُناسِب احتياجاتك أدناه. إعداد التحكم بالنفاذ Access Control داخل تعريف المضيف الافتراضينبدأ بفتح ملف المضيف الافتراضي الذي نرغب بإضافة تقييد له، سنستخدم في مثالنا الملف 000-default.conf الذي يحمل المضيف الظاهري الافتراضي والمُثبَّت عبر حزمة apache في Ubuntu: sudo nano /etc/apache2/sites-enabled/000-default.confينبغي أن يبدو المحتوى داخل الملف مُشابِهًا لما يلي بعد إزالة التّعليقات: etc/apache2/sites-enabled/000-default.conf/ <VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost>يتم الاستيثاق على أساس كل دليل، سنحتاج لإعداد الاستيثاق إلى استهداف الدّليل الذي نرغب بتقييد الوصول إليه بواسطة كتلة <Directory ___>، في مثالنا سنقيّد الوصول إلى كامل جذر المستند document root ولكن نستطيع تعديل القائمة لاستهداف دليل مُحدَّد داخل مساحة الويب: etc/apache2/sites-enabled/000-default.conf/ <VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined <Directory "/var/www/html"> </Directory> </VirtualHost>نُحدِّد داخل كتلة الدّليل أنّنا نرغب بإعداد استيثاق أساسي Basic، نختار من أجل AuthName اسم حقل يتم عرضه عند السؤال عن الاعتمادات credentials، نستخدم الأمر التوجيهي AuthUserFile ليشير إلى Apache عن ملف كلمات السّر الذي أنشأناه، سنحتاج أخيرًا إلى valid-user للوصول إلى هذا المورد، وهذا يعني أنّه سيتم السماح بالدخول لكل من يثبت صحّة هويته بكلمة سر: etc/apache2/sites-enabled/000-default.conf/ <VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined <Directory "/var/www/html"> AuthType Basic AuthName "Restricted Content" AuthUserFile /etc/apache2/.htpasswd Require valid-user </Directory> </VirtualHost>عند الانتهاء نحفظ ونغلق الملف، نعيد تشغيل Apache لتنفيذ سياسة policy كلمات السّر: sudo service apache2 restartيجب الآن أن يكون الملف الذي حدّدناه محميًّا بكلمة سر. إعداد التحكم بالنفاذ Access Control باستخدام ملفات htaccess.إن كُنّا نرغب بإعداد حماية كلمة السّر باستخدام ملفّات htaccess. بدلًا من الطريقة السّابقة فينبغي أن نبدأ بتحرير ملف إعدادات Apache الرئيسي للسماح بملفّات htaccess.: sudo nano /etc/apache2/apache2.confنبحث عن الكتلة <Directory> من أجل الدّليل var/www/ الذي يحتوي جذر المستند، نقوم بتشغيل معالجة htaccess. بتغيير الأمر التّوجيهي AllowOverride داخل تلك الكتلة من “None” إلى “All”: etc/apache2/apache2.conf/ . . . <Directory /var/www/> Options Indexes FollowSymLinks AllowOverride All Require all granted </Directory> . . .عند الانتهاء نحفظ ونغلق الملف. نحتاج بعد ذلك لإضافة ملف htaccess. إلى الدّليل الذي نرغب بتقييد الوصول إليه، في هذا المثال سنقيّد الوصول إلى كامل جذر المستند (كامل الموقع) والذي يتواجد في المسار var/www/html/، ولكن يُمكننا وضع هذا الملف في أي دليل نرغب بتقييد الوصول إليه: sudo nano /var/www/html/.htaccessنُحدِّد بداخل هذا الملف أنّنا نرغب بإعداد استيثاق أساسي Basic، نختار من أجل AuthName اسم حقل يتم عرضه عند السؤال عن الاعتمادات credentials، نستخدم الأمر التوجيهي AuthUserFile ليشير إلى Apache عن ملف كلمات السّر الذي أنشأناه، سنحتاج أخيرًا إلى valid-user للوصول إلى هذا المورد، وهذا يعني أنّه سيتم السماح بالدخول لكل من يثبت صحّة هويته بكلمة سر: var/www/html/.htaccess/ AuthType Basic AuthName "Restricted Content" AuthUserFile /etc/apache2/.htpasswd Require valid-userنحفظ ونغلق الملف، نعيد تشغيل خادوم الويب لنحمي بكلمة سر كل المحتوى الموجود في الدّليل بواسطة الملف htaccess.: sudo service apache2 restartتأكيد استيثاق كلمة السرللتأكّد من أنّ المحتوى محمي لدينا نُجرِّب النفاذ إلى المحتوى المُقيَّد من متصفّح إنترنت، يجب أن يتم عرض مُحث prompt لاسم المستخدم وكلمة السّر يُشبه ما يلي: إن أدخلنا الاعتمادات الصحيحة سيتم السماح لنا بالنفاذ إلى المحتوى، وإن أدخلنا الاعتمادات الخاطئة أو ضغطنا على إلغاء Cancel سنشاهد صفحة الخطأ "Authorization Required": الخاتمة يجب أن يكون لدينا الآن كل ما نحتاجه لإعداد استيثاق أساسي لموقعنا، فلنضع في اعتبارنا أنّ حماية كلمة السّر يجب أن تكون جنبًا إلى جنب مع تشفير SSL كي لا يتم إرسال اعتماداتنا إلى الخادوم في شكل نص مُجرَّد plain text، يمكنك الإطلاع أيضا على كيفيّة إنشاء شهادة SSL موقّعة ذاتيًّا لاستخدامها مع Apache. ترجمة -وبتصرّف- لـ How To Set Up Password Authentication with Apache on Ubuntu 14.04 لصاحبه Justin Ellingwood. حقوق الصورة البارزة: Designed by Freepik.

عند إعداد خادوم ويب توجد غالبًا أقسام من الموقع نرغب بتقييد الوصول إليها، تُوفِّر تطبيقات الويب عادةً طرق التصريح 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.

Nginx (وتلفظ "engine x") هو خادوم ويب حرّ ومفتوح المصدر، يعمل كخادوم بروكسي معكوس reverse proxy للبروتوكولات HTTP ،POP3 ،SMPT ،IMAP، كتبه Igor Sysoe بهدف التركيز على المرونة، الخفة، وقلّة استهلاك الموارد وذلك بالمقارنة مع أباتشي Apache. المتطلبات كشرط مسبق لهذا الدرس سأفترض أنك انتهيت من الإعدادات الأولية على الخادوم الافتراضي الخاص بك VPS إضافةً إلى تثبيت Nginx بنجاح. الخطوة الأولى: تثبيت Apache Utilsنحتاج أولًا إلى الأداة htpasswd بهدف إنشاء وتحديث ملف لتخزين معلومات التوثيق الأساسية للمستخدم (الاسم وكلمة المرور)، htpasswd هي جزء من حزمة apache2-utils والتي يمكنك تركيبها بالأمر التالي: sudo apt-get install apache2-utils الخطوة الثانية: إنشاء مستخدمإنشاء ملف htpasswd. داخل دليل موقع الويب الخاص بك يؤمن بواسطة Nginx. يُنشئ الأمر التالي الملف اللازم ويضيف اسم مُستخدم مع كلمة مرور مُشفّرة له: sudo htpasswd -c /etc/nginx/.htpasswd exampleuser هنا ستطلب منك الأداة اختيار كلمة المرور: New password: Re-type new password: Adding password for user exampleuser وهكذا تكون صيغة ملف htpasswd. مشابهة لهذا: login:password خُذ بعين الاعتبار أن htpasswd يجب أن يكون قابلًا للوصول بواسطة حساب المستخدم الذي يُشغّل Nginx. الخطوة الثالثة: تحديث إعدادات Nginxيقع ملف ضبط Nginx ضمن الدليل /etc/nginx/sites-available/. أضف السطرين التاليين إلى آخره لحماية مسار النطاق الذي ترغب به: auth_basic "Restricted"; auth_basic_user_file /etc/nginx/.htpasswd; يحمل السطر الثاني مكان ملف htpasswd. الخاص بموقعك. على سبيل المثال لنقل بأنّ ملف ضبط nginx لموقعنا هو /etc/nginx/sites-available/website_nginx.conf/؛ افتح الملف بواسطة المحرّر النصيّ الذي تفضّله: sudo vi /etc/nginx/sites-available/website_nginx.conf ثم أضف هذين السطرين إلى المسار التالي: server { listen portnumber; server_name ip_address; location / { root /var/www/mywebsite.com; index index.html index.htm; auth_basic "Restricted"; #For Basic Auth auth_basic_user_file /etc/nginx/.htpasswd; #For Basic Auth } } الخطوة الرابعة: أعد تحميل Nginxيتوجب علينا أخيرًا إعادة تحميل إعدادات Nginx لتأخذ التغييرات الجديدة موضع التنفيذ على موقع الوِب الخاص بنا. بعد ذلك جرّب الدخول إلى النطاق الذي تمّت حمايته بواسطة معلومات التوثيق السابقة: $ sudo /etc/init.d/nginx reload * Reloading nginx configuration... حاول الآن الدخول إلى موقعك أو إلى مسار النطاق المحمي وسيطلب منك المتصفح إدخال اسم المستخدم وكلمة المرور للمتابعة، ولن يكون بإمكانك استعراض المحتوى دون معلومات الولوج الصحيحة. رائع! أصبح لديك الآن نطاق ويب محمي باستخدام توثيق Nginx الأساسي. ترجمة -وبتصرف- للمقال How To Set Up HTTP Authentication With Nginx On Ubuntu 12.10. حقوق الصورة البارزة: Designed by Freepik.

يتضمن توفير الخدمات للعموم عبر شبكة الإنترنت خطر التعرض لهجمات، إلا أن عرض الخدمات هو الغرض الأساسي - غالبا - لتجهيز خادوم. يمكن لأي منفَذ Port أو خدمة أن تكون عُرضة لأنواع كثيرة من التجسس ومحاولات الوصول من طرف مستخدمين سيئي النوايا أو سكربتات تعمل تلقائيا. في حين أن بعض الخدمات يجب أن تبقى متاحة نظرا لأنها موجهة للاستخدام من الجميع (خادوم ويب يستضيف موقعا على سبيل المثال)، إلا أن أخرى لا ينبغي لها ذلك، إذ يجب الاستيثاق من مستخدميها ومنع من لايُرخص له الدخول من الولوج إلى الخدمة (خدمة SSH على سبيل المثال). الوضعية المُثلى هي أن تكون هذه الخدمات مؤمنة جدا ولا يتاح الوصول إليها إلا لمن نرغب في منحه هذه الصلاحية. يتيح الاستيثاق فريد الحزمة Single Packet Authentication وسيلة تسمح للجدار الناري Firewall الإبقاء على حظر خدمة إلى حين إرسال حزمة خاصة مُعمَّاة Encrypted إلى خدمة في الاستماع. إذا صادقت خدمة الاستماع على الحزمة فإنها تغير فورا قواعد الجدار الناري من أجل عرض المنفذ المطلوب. توجد أداة اسمها fwknop (اختصار ل Firewall Knock Operator وتعني عامل الطرق على الجدار الناري) تستخدم لاعتراض الحزم المخصصة ثم تغيير قواعد الجدار الناري حسب المطلوب. سنعد في هذا الدليل خادوما لأداة fwknop وعميلا لها على جهازين يعملان بتوزيعة أوبنتو 14.04. يمكّننا هذا الإعداد من حماية خادوم SSH وحظر الدخول إليه ما لم تطلب إتاحته. تثبيت fwknop على خادوم أوبنتو الأولسنفترض في إعداداتنا وجود خادوميْ أوبنتو 14.04 وتوفر اسم نطاق لكل واحد من الخادومين؛ مع أن استخدام عناوين IP لن يمثل عائقا. نفترض أيضا تثبيت خدمة SSH. تثبت الأوامر التالية خادوم fwknop على الجهاز الأول والذي سيكون بمثابة خادوم للثاني: sudo apt-get update sudo apt-get install fwknop-serverتثبيت عميل fwknop على خادوم أوبنتو الثانيسنجعل من الخادوم الثاني عميلا؛ لذا سنحتاج لتثبيت عميل fwknop عليه. يتكفل هذا العنصر بإنشاء الحزمة المعماة لإرسالها إلى الخادوم الآخر. sudo apt-get update sudo apt-get install fwknop-clientإعداد مفاتيح GPGسنستخدم مفاتيح GPG لتوفير الاستيثاق أثناء نقل الحزم. نحتاج لتنفيذ الإجراءات التالية على كل من الجهاز الخادوم والجهاز العميل. تأتي أداة GPG مثبتة افتراضيا. ولِّد مفاتيح على كل من الجهازيْن: gpg --gen-keyستسأل بضعة أسئلة يكفي - في الغالب - اختيار الإجابات الافتراضية بالضغط على زر Enter. سيطلب منك أيضا إدخال ثم تأكيد عبارة سر Passphrase. سيأخذ إنشاء مفتاح عشوائي بعض الوقت؛ من الأفضل تنفيذ بعض الإجراءات على الخادوم للتسريع من العملية (مثلا افتح نافذة Shell جديدة ونفذ فيها الأمر التالي find / > /dev/null إضافة إلى أوامر أخرى). نحتاج بعد انتهاء توليد مفاتيح GPG إلى كتابة أو نسخ معرفات المفاتيح العمومية. لذا ننفذ الأمر التالي على كل من الجهازين (الخادوم والعميل) gpg --list-keys /home/zeine77/.gnupg/pubring.gpg ------------------------------- pub 1024D/FFEDEE15 2015-07-21 uid Mohamed Ahmed Eyil (Comment) <Email> sub 1024g/95B798A4 2015-07-21الجزء المعلَّم هو الذي نحتاجه هنا (مفتاح عمومي). انسخ المفتاح العمومي لكل من الجهازين واحتفظ به مع تعليمِه (خادوم SERVER أو عميل CLIENT للتفريق بينهما) على النحو التالي: SERVER: FFEDEE15 CLIENT: 1E6E6DC4نفذ الأمر التالي على الجهاز العميل لإنشاء نسخة client.asc من المفتاح عبر تصديرها إلى ملف. ستحتاج لكتابة معرف مفتاح العميل الذي نسخته للتو: gpg -a --export 1E6E6DC4 > client.ascنفس الشيء على الجهاز الخادوم مع استخدام المفتاح العمومي للخادوم وتسمية المف بserver.asc: gpg -a --export FFEDEE15 > server.asc1- نقل المفاتيح بين الأجهزةنحتاج الآن لنقل المفاتيح بين الجهازين بحيث يكون لدى كل منهما نسخة من الاثنين. نستخدم أداة scp لنسخ ملف client.asc من العميل إلى الخادوم. نفذ الأمر التالي على العميل scp client.asc server_domain_or_ip:/path/to/user/home/directoryحيث server_domain_or_ip اسم نطاق أو عنوان IP الخادوم و/path/to/user/home/directory المسار الذي سيُنقل إليه الملف (المجلد الشخصي للمستخدم). سيطلب منك بعد تنفيذ الأمر معلومات الدخول إلى الخادوم. ثم نكرر نفس الشيء مع ملف server.asc لنقله من الخادوم إلى العميل (تنفيذ الأمر يكون على العميل): scp server_domain_or_ip:/path/to/user/home/directory/server.asc .توجد الآن نسخة من كل ملف على الخادوم وعلى العميل. 2- استيراد وتوثيق المفاتيحيوجد الآن المفتاح العمومي لكل واحد من الجهازين على الآخر (المفتاح العمومي للخادوم على العميل، والمفتاح العمومي للعميل على الخادوم) مما يعني أنه يمكننا استيراد المفتاح العمومي إلى قاعدة بيانات GPG المحلية. نفذ الأمر التالي على الخادوم: gpg --import client.ascثم نفذ التالي على العميل: gpg --import server.ascيوجد لدى كل من الجهازين الآن مفتاح الآخر في قاعدة بياناته؛ ننتقل إلى توثيق المفاتيح. نفذ الأمر التالي عل كل من الجهازين، مع استخدام معرفات المفاتيح المناسبة. في المثال لدينا سننفذ ما يلي على العميل (نوثق المفتاح العمومي للخادوم): gpg --edit-key FFEDEE15وعلى الخادوم (نوثق المفتاح العمومي للعميل) gpg --edit-key 1E6E6DC4سيظهر سطر أوامر gpg؛ نطلب توثيق المفتاح عبر الأمر: signسيطلب منك التأكيد على اختيارك، اضغط زر y ثم Enter. ثم الخطوة قبل الأخيرة وهي كتابة عبارة السر (نفس عبارة السر التي أدخلتها عند توليد المفتاح). وأخيرا أمر save لحفظ الإعدادات والخروج من سطر أوامر gpg. نحصل باكتمال هذه الخطوات على نسخة موثَّقة لمفتاح gpg الخاص بكل جهاز على الآخر، مما يعني أننا نثق من صحة المفاتيح. إعداد الوصول في خادوم fwknopيجب علينا إعداد خدمة fwknop لاستخدام مفاتيح GPG والسماح للعميل بالاتصال بالخادوم والاستيثاق لديه. افتح ملف إعداد الأداة على الخادوم بصلاحيات إدارية: sudo nano /etc/fwknop/access.confتوجد افتراضيا بضعة أسطر نشطة، البقية تعليقات وشروح. SOURCE: ANY; KEY_BASE64 __CHANGEME__ HMAC_KEY_BASE64 __CHANGEME__سنضبط ملف الإعداد لاستخدام الاستيثاق عبر مفاتيح GPG التي أعددناها سابقا. لذا سنضيف تعليمات لإعطاء معلومات لخدمة fwknop عن المفاتيح التي نستخدمها. توجد هذه التعليمات ضمن ملف الإعداد، احذف علامة التعليق (#) ثم أعط القيم المناسبة للتعليمات. عدل الملف لتصبح الأسطر النشطة على النحو التالي: SOURCE: ANY; OPEN_PORTS: tcp/22; ## SSH لتمكين الاتصال عن طريق FW_ACCESS_TIMEOUT: 30; ## مدة بقاء الاتصال مفتوحا REQUIRE_SOURCE_ADDRESS: Y; ## طلب عنوان المصدَر GPG_REMOTE_ID: FFEDEE15; ## المفتاح العمومي للعميل GPG_DECRYPT_ID: 1E6E6DC4; ## المفتاح العمومي للخادوم GPG_DECRYPT_PW: your_GPG_passphrase_here; ## عبارة سر الخاصة بالخادوم GPG_HOME_DIR: /home/test/.gnupg; ## gunpg مسار مجلد ## يوجد عادة في المجلد الشخصي للمستخدِم تأكد من إعطاء معرف مفتاح العميل ضمن تعليمة GPG_REMOTE_ID ومعرف مفتاح الخادوم ضمن تعليمة GPG_DECRYPT_ID. يجب كذلك إدخال عبارة السر لمفتاح الخادوم ضمن التعليمة GPG_DECRYPT_PW ومسار مجلد gnupg. ضمن تعليمة GPG_HOME_DIR. احفظ (CTRL+O) الملف ثم أغلقه (CTRL+X). اضبط قواعد IPTablesننتقل الآن، بعد أن أنهينا إعداد خادوم fwknop، إلى ضبط قواعد IPTables. ستعدل خدمة fwknop هذه القواعد حسب الحاجة؛ ولكن قبل ذلك نحتاج إلى إغلاق المنفذ. نحتاج أولا إلى السماح للاتصال الجاري بالمتابعة قبل غلق المنفذ. تسمح القاعدة التالية للاتصال الموجودة بالمواصلة: sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTملحوظة: هذا الإجراء مهم جدا في حال كنت تعد خادوما بعيد تتصل به عن طريق SSH. ثم نقيّد مباشرة بعد تنفيذ الأمر أعلاه الولوجَ عبر منفذ SSH بمنع بقية الاتصالات كلها: sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -j DROPيوجد لدينا الآن جدار ناري مبدئي لمنع الاتصال عبر المنفذ 22 ويمكن بالتالي تنفيذ إعدادات fwknop؛ لذا نعيد تشغيل خادوم fwknop: sudo service fwknop-server restartستبدأ خدمة fwknop بمراقبة الخادوم بحثا عن حزم بيانات توافق القواعد التي أعددناها. الاتصال بالخادوم من العميلسنجرب الآن الاتصال بالخادوم من العميل. إن جرى كل شيء على ما يرام فلن يمكننا الاتصال بسبب انتهاء مهلة الاتصال (Time out). ssh root@server_domain_or_ipسيحاول العميل الاتصال بالخادوم وبعد انتهاء مهلة الاتصال تظهر الرسالة التالية: ssh: connect to host server_domain_or_ip port 22: Connection timed outإن لم ترغب في انتظار اكتمال المهلة - التي قد تطول - يمكنك الضغط على مفتاحي CTRL وC معا. يمكننا الآن إرسال حزمة معماة للاستيثاق لدى الخادوم. نستخدم عميل fwknop لهذا الغرض؛ ونمرر له المعطيات التالية: A tcp/22-: يحدد هذا الخيار البروتوكول والمنفذ الذي نطلب فتحه. gpg-recip--: معرف مفتاح GPG الخاص بالخادوم. gpg-sign--: معرف مفتاح GPG الخاص بالعميل. a-: يخبر fwknop بعنوان IP الذي يسمح بالوصول منه؛ أي عنوان الجهاز العميل. D-: يخبر الأمر بوجهة الطلب. نحدد هنا عنوان IP الخاص بالخادوم أو نطاقه. ننشئ ثم نرسل الأمر انطلاقا من هذه المعطيات والمعطيات السابقة (مفاتيح GPG): fwknop -A tcp/22 --gpg-recip FFEDEE15 --gpg-sign 1E6E6DC4 -a client_ip_address -D server_domain_or_ipسيطالب منك إدخال عبارة سر العميل لفك تعمية المفاتيح ثم ترسل الحزمة المعماة إلى الخادوم. لديك الآن ثلاثون ثانية لمحاولة الاتصال عبر SSH. ملحوظة: لتغيير هذه المدة فعّل تعليمة FW_ACCESS_TIMEOUT في ملف إعداد خادوم fwknop ثم أعطها القيمة المرادة. ssh root@server_domain_or_ipإن جرت الأمور على النحو المخطط لها فسيمكنك الاتصال بنجاح. سيُغلق المنفذ المفتوح بعد ثلاثين ثانية غير أن الاتصال سيبقى نشطا. تستطيع رؤية قواعد IPTables المضافة على الجهاز الخادوم بعد تنفيذ أمر إنشاء الحزمة المعماة وإرسالها على العميل (وقبل انقضاء مهلة الثلاثين ثانية). استخدم الأمر التالي لهذا الغرض: sudo iptables -Sالنتيجة -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N FWKNOP_INPUT -A INPUT -j FWKNOP_INPUT -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 22 -j DROP -A FWKNOP_INPUT -s client_ip_address/32 -p tcp -m tcp --dport 22 -j ACCEPT لاحظ إضافة سطر جديد إلى IPTables. يطبق القاعدة المضافة على جميع طلبات الاتصال، إن وافق عنوان مصدر الطلب الجهاز الذي أرسل الحزمة المعماة فإنه يسمح له بالوصول عبر المنفذ 22 وإلا يرفض الطلب. خاتمةيمكّن إعداد آلية للاستيثاق فريد الحزمة من إضافة طبقة أمان عند الاتصال بين الأجهزة. يوفر هذا الإجراء علاوة على حماية الخواديم من هجمات القوة القاسية Brute force والهجمات العشوائية، المساعدة في حال اكتشاف ثغرات أمنية ضمن الخدمات المحمية مما يتيح لك في وضعية آمنة إلى أن ترقع الثغرة. قد تمثل آلية الاستيثاق فريد الحزمة إزعاجا للمستخدمين؛ إلا أنها مفيدة أمنيا ويمكن استخدامها مع إجراءات أمنية أخرى للمزيد من الأمان. ترجمة -بتصرف- لمقال How To Use fwknop to Enable Single Packet Authentication on Ubuntu 12.04.