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

SSH عبارة عن بروتوكول آمن يُستخدم كوسيلة أساسيّة للاتصال بخوادم لينكس عن بُعد. SSH تُقدّمُ واجهة نصّية بحيثُ تعطيك الصّلاحيّة لكتابة أي أوامر وتنفيذها مباشرة على الخادوم. بعد الاتصال، جميع الأوامر التي تكتبها على الطرفيّة محليّاً تُرسل إلى الخادوم عن بعد وتُنفّذ هناك. في هذا الدّليل السّريع، سنُغطّي بعضاً من أكثر وسائل الاتّصال بSSH شيوعاً لتحقيق أهدافك. هذا المقال يُمكن أن يُستعمل كمرجع سريعٍ كلّما احتجت إلى معرفة كيفية الاتصال بخادومك أوضبطه بطرق مختلفة. نظرة عامة على SSH أشهر وسيلة للاتّصال بخادوم لينكس عن بعد هي استعمال SSH .SSH اختصار ل Secure Shell أو شل آمن، حيث تُوفّر وسيلة آمنة لتنفيذ الأوامر، إضافة تعديلات وضبط الخدمات عن بُعد. عندما تتّصل عبر SSH، تقوم بتسجيل الدّخول باستخدام حساب موجود على الخادوم. كيف يعمل SSH عندما تتّصل عبر SSH، ستدخلُ إلى جلسة شل (shell session)، وهي واجهة نصّيّة تُمكّنك من التّفاعل مع خادومك. أثناء الجلسة جميع الأوامر التي تُنفّذها في الطرفيّة محليّاً تُرسل عبر نفق SSH أو SSH tunnel مُشفّر وتُنفّذ على الخادوم. اتصال SSH يُنفّذ باستخدام نموذج خادوم خاص بالعميل. هذا يعني أن إنشاء اتصال SSH يتطلّب تشغيل برمجيّة تسمى عفريت SSH على الخادوم. تستمع هذه البرمجيّة للاتصالات على منفذ شبكة معيّن، طلبات تسجيل الدّخول والاستيثاق authentication من هوية صاحب الاتصال وتقوم بتقديم البيئة المناسبة إذا قام المستخدم بتوفير المعلومات الصّحيحة. يجب على المُستخدم أن يمتلك على جهازه برمجية تسمى عميل SSH أو SSH client، البرمجية تعرف كيف تتواصل باستخدام بروتوكول SSH ويُمكن أن تُمنَح معلومات عن المُضيف البعيد (الخادوم) للاتّصال به،عن طريق اسم المستخدم ومعلومات يجب تمريرها للاتّصال بنجاح. يمكن للعميل أيضاً أن يحدّد تفاصيل معيّنة عن نوع الاتّصال المرغوب فيه. كيف يقوم SSH بتسجيل دخول المستخدمين العميل يصادق إمّا باستخدام كلمات المُرور ( أقلّ أماناً وغير منصوح بها) أو عن طريق مفاتيح SSH، التي تعتبر آمنة جدّاً. كلمات المرور تُشفَّرُ وتعتبر سهلة الفهم بالنّسبة للمُستخدمين الجُدد. لكنّ المُخترقين يستعملون برمجيّات خبيثة يُمكن لها أن تُكرّر محاولات الدّخول إلى حواسيب من يستخدمون كلمات المرور، ما قد يُؤدي إلى اختلال أمني. لهذا السّبب ننصح دائما بالاعتماد على استيثاق SSH المبدئي لمُعظم الإجراءات. مفاتيح SSH هي مجموعة من المفاتيح المُشفّرة يُمكن استعمالها للاستيثاق. كلّ مجموعة تحتوي على مفتاح عام وخاص. يُمكن نشر المفتاح العام بشكل حرّ، أما المفتاح الخاص فيجب الاحتفاظ به ولا يجب أن يُكشف لأحد. للاستيثاق باستخدام مفاتيح SSH، يجب على المستخدم أن يمتلك زوج مفتاح SSH على جهازه المحلي. وعلى الخادم البعيد المفتاح العام يجب أن ينسخ إلى ملفّ بداخل مجلّد منزل المُستخدم على ssh/authorized_keys./~ . هذا الملفّ يحتوي على قائمة من المفاتيح العامّة - واحد في كلّ سطر- مُخوّلٌ لها بالدّخول إلى الحساب. عندما يتّصل عميل بالمُضيف Host راغباً باستخدام استيثاق مفتاح SSH، سيُعلم الخادومَ عن أي مفتاح عام يستخدم. يتحقّق الخادوم بعد ذلك من ملفّ المفاتيح المُخوّل لها authorized_keys باحثاً عن المفتاح العام المُستخدم. ثم يولّد سلسلة نصّية عشوائيا ويُشفّر باستخدام المفتاح العام، هذا النّص المُشفّر يُمكن فك تشفيره فقط باستعمال المفتاح الخاصّ المُقترن. سيُرسل الخادوم هذه الرّسالة المُشفرة إلى العميل لاختبار إذا ما كان فعلا يمتلك المفتاح الخاصّ المُرتبط. عند استلام الرّسالة، سيقوم العميل بفك التّشفير باستخدام المفتاح الخاص ويجمع السّلسلة نصّية العشوائية مع هوية جلسة سابقة (session ID) . ويولّد بعد ذلك مزيج MD5 الخاص بالقيمة وينقلها مجدّدا إلى الخادوم. الخادوم يمتلك سابقا الرّسالة الأصليّة وهوية الجلسة، لذلك يُمكنه أن يُقارن مزيج MD5 المولّد من القيّم ويُحدّد بأن العميل يجب أن يمتلك المفتاح الخاص. الآن بما أنّك تعلم كيف يعمل SSH، يُمكننا البدء في الحديث عن بعض الأمثلة للتعرّف على الطّرق المُختلفة للعمل مع SSH. توليد مفاتيح SSH والعمل معها هذا القسم سيغطي كيف تولّد مفاتيح SSH على جهاز عميل ونشر المفتاح العام إلى الخوادم حيث يجب أن تُستخدم. هذا قسم جيّد للبدء به إذا لم يسبق لك أن ولّدت مفاتيح، ويجب عليك البدء به إذا أردت تأمين خادومك نظراً لزيادة الأمان التي تتيحه لنا في الاتصّالات المُستقبليّة. توليد زوج مفاتيح SSH توليد زوج مفاتيح SSH عام وخاص على جهازك المحلي هو أول خطوة نحو استيثاق مع خادوم عن بعد بدون كلمة مرور. إلا إذا كنت تملك سببا جيدا لعدم فعل ذلك، يجب عليك دائما الاتصال باستخدام مفاتيح SSH. يمكن استخدام مجموعة من خوارزميّات التشفير لتوليد مفاتيح SSH، مثل RSA، DSA، ECDSA. مفاتيح RSA مُفضلة بشكل عام وهي نوعية المفاتيح الافتراضية. لتوليد زوج مفاتيح RSA على جهازك المحلي، أكتب: $ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/demo/.ssh/id_rsa): هذا المحث (prompt) يتيح لك اختيار مكان لتخزين مفتاح RSA الخاص. اضغط Enter للخيار الافتراضي، الذي سيُخزنها في مجلّد .ssh المخفي قي مجلد المنزل. ترك المسار الافتراضي سيتيح لعميل SSH إيجاد المفاتيح آلياً. Enter passphrase (empty for no passphrase): Enter same passphrase again: المحث التالي يتيح لك إدخال جملة مرور بطول اعتباطي لتأمين مفتاحك الخاص. افتراضياً يجب عليك إدخال جملة المرور هذه في كل مرّة تستعمل المفتاح الخاص، كإجراء أمني إضافي. يُمكنك أن تضغط Enter لترك الحقل فارغا إذا لم ترغب في إنشاء كلمة مرور. تذكّر فقط أن هذا سيخوّل أي شخص يملك قابلية التحكم بمفتاح SSH الخاص للدخول إلى الخادوم الخاص بك. إذا اخترت وضع كلمة مرور لن يظهر شيء على الشاشة أثناء الكتابة، وهذا من أجل الاحتياط الأمني. Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: 8c:e9:7c:fa:bf:c4:e5:9c:c9:b8:60:1f:fe:1c:d3:8a root@here The key's randomart image is: +--[ RSA 2048]----+ | | | | | | | + | | o S . | | o . * + | | o + = O . | | + = = + | | ....Eo+ | +-----------------+ هذه العملية ولّدت زوج مفاتيح SSH من نوع RSA، وملفّات تحت المجلد المخفي .ssh في مجلد المنزل وهذه الملفّات هي: ssh/id_rsa./~: المفتاح الخاص. لا تنشر هذا الملفّ! ssh/id_rsa.pub./~: المفتاح العام المُرتبط. هذا الملفّ يمكن مشاركته بحرية. توليد زوج مفاتيح مع رقم أكبر من البتات Bits مفاتيح SSH تكون افتراضياً 2048 بت. هذا يعتبر جيّداً بشكل عام أمنياً، لكنّك تستطيع تحديد عدد أكبر لمزيد من الأمان. لفعل ذلك ضَمِّن معامل -b مع عدد البتات الذي تريد. معظم الخوادم تدعم 4096 بت على الأقل. المفاتيح الأطول يُمكن ألّا تُقبل لأغراض الحماية من DDOS: ssh-keygen -b 4096 إذا سبق لك أن أنشئت مفتاحاً، سيُطلب منك إذا ما كنت ترغب في الكتابة فوق المفتاح السّابق: Overwrite (y/n)? إذا اخترت نعم (y)، فإن المفتاح الجديد سيكتب فوق المفتاح السّابق ولن تستطيع استعمال المفتاح القديم بعدها للدّخول إلى الخادوم، لذلك كن حذرا أثناء تغيير المفتاح. حذف وتغيير جملة المرور على المفتاح الخاص إذا سبق لك وأن عيّنت جملة مرور للمفتاح الخاص ورغبت في تغييرها فالأمر بسيط، ويمكنك أن تقوم به بسهولة. ملاحظة: لتغيير أو حذف جملة المُرور، يجب عليك معرفة جملة المرور الأصليّة. إذا فقدت جملة المرور إلى المفتاح،فللأسف لا يوجد طريقة لإرجاعها وسيتوجّب عليك توليد زوج مفاتيح جديد. لتغيير أو حذف جملة المرور، فقط أكتب: ssh-keygen -p Enter file in which the key is (/root/.ssh/id_rsa): يُمكنك أن تُحدد مسار المفتاح الذي تحاول تعديله أو اضغط Enter لقبول القيمة الافتراضيّة: Enter old passphrase: أكتب جملة المرور القديمة المراد تغييرها. بعد ذلك ستُسأل لإدخال جملة مرور جديدة: Enter new passphrase (empty for no passphrase): Enter same passphrase again: هنا أكتب جملة المرور الجديدة أو اضغط Enter لحذفها. عرض بصمة مفتاح SSH ينشر كل زوج مفاتيح بصمة مُشفّرة يُمكن استعمالها لتعريف المفاتيح بشكل فريد. يُمكن أن يكون هذا جيّدا في كثير من الحالات. لإيجاد بصمة مفتاح SSH، اكتب: ssh-keygen -l Enter file in which the key is (/root/.ssh/id_rsa): إذا كان هذا هو مسار المفتاح الصحيح اضغط ENTER ، أو اكتب المسار الخاص إذا كان المسار مختلفاً، ستُرجع سلسلة نصيّة تحتوي على سعة المفتاح من البتات، البصمة، والحساب والمُضيف الذي أنشئت له، والخوارزمية المُستخدمة: 4096 8e:c4:82:47:87:c2:26:4b:68:ff:96:1a:39:62:9e:4e demo@test (RSA) نسخ مفتاح SSH العام إلى الخادوم مع SSH-Copy-ID لنسخ مفتاحك العام إلى الخادوم، بغرض الاستيثاق بدون كلمة مرور، سنتخذ بعض الإجراءات. إذا كنت حالياً تمتلك وصولا إلىSSH عن طريق كلمة مرور مضبوطاً على الخادوم، وتمتلك أداة ssh-copy-id مثبّتة، فهذه العمليّة بسيطة. أداة ssh-copy-id تأتي مضمّنة على حزم OpenSSH في كثير من توزيعات لينكس، لذلك فمن المُحتمل أن تكون لديك افتراضيا. إذا كنت تملك هذا الخيّار، يُمكنك بسهولة نقل مفتاحك العام باستعمال: ssh-copy-id username@remote_host سيُطلب منك إدخال كلمة مرور المُستخدم على الجهاز البعيد: The authenticity of host ‘111.111.11.111 (111.111.11.111)’ can’t be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed – if you are prompted now it is to install the new keys demo@111.111.11.111’s password: بعد كتابة كلمة المرور، مُحتوى مفتاح ssh/id_rsa.pub./~ سوف يُلحق إلى آخر ملف ssh/authorized_keys./~ الخاصّ بحساب المُستخدم: Number of key(s) added: 1 Now try logging into the machine, with: "ssh ‘demo@111.111.11.111’" and check to make sure that only the key(s) you wanted were added. يُمكنك الآن الدّخول إلى الحساب بدون كلمة مرور: ssh username@remote_host نسخ مفتاح SSH العام إلى خادوم بدون SSH-Copy-ID إذا لم تكن تملك أداة ssh-copy-id، لكنك لا زلت تملك وصولا إلى الخادوم البعيد بكلمة مرور، يُمكنك نسخ محتويات المفتاح العام بطريقة مختلفة. يُمكنك إرجاع مُحتويات المفتاح وتمريرها إلى أمر SSH، في الجهة البعيدة يُمكنك التأكد إذا ما كان مجلّد ssh./~ موجوداً، وبعد ذلك ألحق المحتوى المُمَرّر إلى ملفّ ssh/authorized_keys./~: cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys" سيُطلب منك كتابة كلمة المرور للحساب البعيد: The authenticity of host ‘111.111.11.111 (111.111.11.111)’ can’t be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes demo@111.111.11.111’s password: بعد إدخال كلمة المرور، سيُنسخ مفتاحك، متيحاً لك الاتصال بدون كلمة مرور: ssh username@remote_IP_host نسخ مفتاح SSH العام إلى خادوم يدويا إذا لم تكن تملك وصولا عن طريق كلمة مرور، ستحتاج لإضافة مفتاحك العام إلى الخادوم البعيد يدويّاً. على جهازك المحليّ، يُمكنك إيجاد محتويات ملفّ مفتاحك العام بكتابة: cat ~/.ssh/id_rsa.pub ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test يُمكنك نسخ هذه القيمة، ولصقها يدويّاً في المكان المناسب على الخادوم البعيد. يجب عليك أن تتّصل بالخادوم بوسيلة مختلفة. على الخادوم البعيد، أنشئ مجلّد ssh./~ إذا لم يكن موجوداً من قبل: mkdir -p ~/.ssh بعد ذلك، يُمكنك إنشاء أو إلحاق ملفّ ssh/authorized_keys./~ بكتابة: echo سلسلة_المفتاح_العام >> ~/.ssh/authorized_keys يجب عليك الآن أن تتمكّن من الدّخول إلى الخادوم بدون كلمة مرور عبر أمر ssh: ssh username@remote_IP_host ترجمة -مع شيءٍ من التصرّف- للقسم الأول من مقال: SSH Essentials: Working with SSH Servers, Clients, and Keys.

كتبت مؤخّرا برنامج Bash قصير لنسخ ملفّات MP3 من مفتاح USB من مُضيف شبكة (network host) إلى مُضيف شبكة آخر. تُنسَخ الملفّات إلى مجلّد خاصّ على خادوم أقوم بتشغيله لمؤسّسة تطوعيّة، ما يسمح بتشغيل وتنزيل الملفّات. يقوم برنامجي ببضعة أمور أخرى، مثل تعديل أسماء الملفّات قبل نسخها لتكون مرتّبة تلقائيّا حسب التّاريخ على صفحة الويب. كما تحذف جميع الملفّات على مفتاح USB بعد التّأكد من اكتمال النّقل بنجاح. يأتي هذا البُريْمِج ببضعة خيارات، مثل -h لعرض المُساعدة، و -t لنمط الاختبار (test mode) وبضعة خيارات أخرى. رغم أنّ برنامجي الصغير هذا جميل، إلّا أنّه يحتاج إلى تشغيله بالمُستخدم الجذر (root) للقيام بالعمليّات الأساسيّة. للأسف، لا تمتلك هذه المؤسّسة أشخاصا مهتمين بإدارة أنظمة الحواسيب، ما يدفعني للبحث عن أشخاص بقدرات تقنيّة متواضعة لتدريبهم على كيفيّة تسجيل الدّخول إلى الحاسوب الذي يعمل على نقل الملفّات وتشغيل هذا البرنامج. صحيح بأنّني أستطيع تشغيل البرنامج بنفسي، إلّا أنّ بضعة أسباب (كالمرض والسّفر) قد تحول دون ذلك. وحتى لو كنتُ متاحا، فبصفتي مدير نُظم كسول، أحب أن يقوم الآخرون بعملي من أجلي. لذا أكتب برامج لأتمتة (automate) هذه المهام وأستعمل Sudo لتمكين بضعة مُستخدمين من تشغيل البرامج.يتطلّب تنفيذ العديد من أوامر Linux صلاحيّات المُستخدم الجذر. هذا يحمي النظام من التخريب الخبيث أو غير المقصود. استعمال أداة Sudo يُمكنّ برنامج sudo مدراء النّظم ذوي صلاحيّات الجذر من تفويض المسؤوليّة لبضعة مهام أو جميعها لمستخدمين آخرين لنفس الحاسوب. كما يسمح لي بتنفيذ هذا التفويض دون توفير كلمة مرور المُستخدم الجذر، ما يوفّر مستوى عاليّا من الحماية على المُضيف. لنفترض على سبيل المثال بأنّني أعطيت للمُستخدم ruser أحقيّة الوصول إلى برنامج Bash خاص بي باسم myprog، والذي يحتاج إلى صلاحيّات المستخدم الجذر لتنفيذ بعض من وظائفه. يقوم المستخدم ruser بتسجيل الدّخول أولا باستعمال كلمة المرور الخاصّة به، وبعدها ينفّذ الأمر التّالي لتشغيل myprog. sudo myprog يقوم برنامج sudo بالاطّلاع على الملفّ /etc/sudoers ويتحقّق من أنّ لـruser إذنا يُمكّنه من تشغيل myprog. إن كان الأمر كذلك، يطلب sudo من المُستخدم كلمة مروره -وليس كلمة مرور المُستخدم الجذر-، بعد إدخال كلمة المرور، يتمّ تنفيذ البرنامج. يقوم sudo كذلك بتسجيل معلومات الوصول إلى myprog مع التاريخ والوقت الذي تمّ فيه تشغيل البرنامج إضافة إلى سطر الأمر والمُستخدم الذي قام بتنفيذه. تُسجّل هذه البيانات في ملفّ /var/log/security. أجد بأنّ سجلّ الأوامر التي تم تنفيذها مفيد عند التّدريب. إذ يسمح لي هذا بالتعرّف على من قام بماذا وما إن أدخل الأمر بشكل صحيح. قمت باستخدام هذه الميّزة لتفويض الصلاحيّات لي ولمُستخدم آخر للتمكّن من تشغيل برنامج واحد؛ لكن لـsudo إمكانيّات أكبر من ذلك. إذ يسمح لمدير النظام بتفويض السُّلطَة لإدارة وظائف الشّبكة أو خدمات مُعيّنة لشخص واحد أو مجموعة من المُستخدمين الموثوقين. يُمكّن هذا من تفويض أحقيّة تشغيل هذه الوظائف ويحمي كلمة مرور المُستخدم الجذر في نفس الوقت. ضبط ملفّ sudoers بصفتي مدير نُظم، يُمكنني استعمال ملفّ /etc/sudoers للسماح للمستخدمين أو مجموعات من المُستخدمين بالوصول إلى أمر مُعيّن، مجموعة محدّدة من الأوامر أو جميع الأوامر. هذه المرونة هي سرّ كل من قوّة وبساطة استعمال sudo للتفويض. بدا لي ملفّ sudoers معقّدا في البداية، لذا نسختُ وحلّلت ملفّ sudoers بالكامل من المُضيف الذي أستخدمه. على أمل أن تفهم الأساسيّات بعد قراءة هذا التّحليل. وجدت كذلك بأنّ ملفّات الإعدادات الافتراضيّة في التوزيعات المبنيّة على Red Hat تحتوي على الكثير من التّعليقات والأمثلة التي تُسهّل المأموريّة. لا تستعمِل محرّر النصوص الاعتياديّ عند تعديل ملفّ sudoers. استعمل الأمر visudo لتطبيق التّغييرات حالما تحفظ الملفّ وتخرجُ من المُحرّر. يُمكن استعمال محرّرات أخرى عوضا عن Vi بنفس الشكل الذي نستعمل فيه visudo. لنبدأ بتحليل هذا الملفّ من البداية مع بضعة أنواع من الأسماء المُستعارة (aliases). الأسماء المُستعارة الخاصّة بالمُضيفات Host aliases يُستعمل جزء الأسماء المُستعارة الخاصّة بالمُضيفات لإنشاء مجموعات من المُضيفات التي يُمكن عليها استعمال الأوامر أو الأسماء المستعارة للأوامر لمنح أحقيّة الوصول. الفكرة أن يُصان (maintain) هذا الملفّ الوحيد من أجل جميع المُضيفات في المؤسّسة ويُنسخ إلى مُجلّد /etc الخاص بكل مُضيف. وبالتالي يُمكن ضبط بعض المُضيفات (مثل الخوادم) لتُشكّل مجموعة لمنح بعض المُستخدمين أحقيّة الوصول إلى أوامر مُخصّصة، مثل إمكانيّة تشغيل أو إيقاف خدمات مثل HTTPD، DNS والتشبيك (networking) أو وصل (mount) أنظمة الملفّات وما إلى ذلك. يُمكن استعمال عناوين IP عوضا عن أسماء المُضيفات في الأسماء المُستعارة الخاصّة بالمُضيفات. ## Sudoers allows particular users to run various commands as ## the root user, without needing the root password. ## ## Examples are provided at the bottom of the file for collections ## of related commands, which can then be delegated out to particular ## users or groups. ## ## This file must be edited with the 'visudo' command. ## Host Aliases ## Groups of machines. You may prefer to use hostnames (perhaps using ## wildcards for entire domains) or IP addresses instead. # Host_Alias FILESERVERS = fs1, fs2 # Host_Alias MAILSERVERS = smtp, smtp2 ## User Aliases ## These aren't often necessary, as you can use regular groups ## (ie, from files, LDAP, NIS, etc) in this file - just use %groupname ## rather than USERALIAS # User_Alias ADMINS = jsmith, mikem User_Alias AUDIO = dboth, ruser ## Command Aliases ## These are groups of related commands... ## Networking # Cmnd_Alias NETWORKING = /sbin/route, /sbin/ifconfig, /bin/ping, /sbin/dhclient, /usr/bin/net, /sbin/iptables, /usr/bin/rfcomm, /usr/bin/wvdial, /sbin/iwconfig, /sbin/mii-tool ## Installation and management of software # Cmnd_Alias SOFTWARE = /bin/rpm, /usr/bin/up2date, /usr/bin/yum ## Services # Cmnd_Alias SERVICES = /sbin/service, /sbin/chkconfig ## Updating the locate database # Cmnd_Alias LOCATE = /usr/bin/updatedb ## Storage # Cmnd_Alias STORAGE = /sbin/fdisk, /sbin/sfdisk, /sbin/parted, /sbin/partprobe, /bin/mount, /bin/umount ## Delegating permissions # Cmnd_Alias DELEGATING = /usr/sbin/visudo, /bin/chown, /bin/chmod, /bin/chgrp ## Processes # Cmnd_Alias PROCESSES = /bin/nice, /bin/kill, /usr/bin/kill, /usr/bin/killall ## Drivers # Cmnd_Alias DRIVERS = /sbin/modprobe # Defaults specification # # Refuse to run if unable to disable echo on the tty. # Defaults !visiblepw Defaults env_reset Defaults env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS" Defaults env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE" Defaults env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES" Defaults env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE" Defaults env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY" Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin ## Next comes the main part: which users can run what software on ## which machines (the sudoers file can be shared between multiple ## systems). ## Syntax: ## ## user MACHINE=COMMANDS ## ## The COMMANDS section may have other options added to it. ## ## Allow root to run any commands anywhere root ALL=(ALL) ALL ## Allows members of the 'sys' group to run networking, software, ## service management apps and more. # %sys ALL = NETWORKING, SOFTWARE, SERVICES, STORAGE, DELEGATING, PROCESSES, LOCATE, DRIVERS ## Allows people in group wheel to run all commands %wheel ALL=(ALL) ALL ## Same thing without a password # %wheel ALL=(ALL) NOPASSWD: ALL ## Allows members of the users group to mount and unmount the ## cdrom as root # %users ALL=/sbin/mount /mnt/cdrom, /sbin/umount /mnt/cdrom ## Allows members of the users group to shutdown this system # %users localhost=/sbin/shutdown -h now ## Read drop-in files from /etc/sudoers.d (the # here does not mean a comment) #includedir /etc/sudoers.d ################################################################################ # Added by David Both, 11/04/2017 to provide limited access to myprog # ################################################################################ # AUDIO guest1=/usr/local/bin/myprog الأسماء المستعارة الخاصّة بالمُستخدمين User aliases تُعطي الأسماء المستعارة الخاصّة بالمُستخدمين إمكانيّة ترتيب المُستخدمين إلى مجموعات ذات أسماء مُستعارة للمُستخدم الجذر، بهذه الطّريقة ستتمكّن مجموعة كاملة من المستخدمين من الوصول إلى صلاحيات مدير محدّدة. هذا هو الجزء الذي أضَفْتُ فيه السّطر User_Alias AUDIO = dboth, ruser، والذي يقوم بتعيين مُستخدمَيْنِ للاسم المُستعار AUDIO. يُمكن الاعتماد على المجموعات المنشأة مُسبقا في ملفّ /etc/groups عوضا عن الأسماء المستعارة. إن كانت أحد المجموعات في هذا الملفّ تفي بالغرض، مثل مجموعة audio فيُمكنك استخدام اسم المجموعة مسبوقا بعلامة % كما يلي: %audio عند تعيين الأوامر التي ستُوفَّرُ للمجموعات في ملفّ sudoers. الأسماء المستعارة للأوامر Command aliases في جزء الأسماء المستعارة للأوامر، نقوم بتوفير قائمة للأوامر ذات الصّلة، مثل أوامر التّشبيك أو الأوامر التي تقوم بتنصيب التّحديثات أو حزم RPM جديدة. تُمكّن هذه الأسماء المستعارة مدير النّظام من منح تصريح للوصول إلى مجموعة من الأوامر. تم مُسبقا إعداد عدد من هذه الأسماء المستعارة في هذا الجزء، ما يجعل تفويض أحقية الوصول لنوع محدد من الأوامر أمرا سهلا. القيم الافتراضيّة للبيئة Environment defaults يقوم الجزء التّالي بتعيين عدد من متغيّرات البيئة (environment variables). أكثر سطر مثير للاهتمام في هذا الجزء هو السّطر !visiblepw، والذي يمنع تشغيل sudo إن كانت بيئة المُستخدم تسمح بعرض كلمة المرور. هذا إجراء وقائي لا يجب تعديله. قسم الأوامر Command section قسم الأوامر هو الجزء الرّئيسي في ملفّ sudoers. يمكن القيام بأي شيء ترغب به دون الحاجة إلى الأسماء المستعارة عبر إضافة خانات هنا. لكنّ الأسماء المستعارة تجعل الأمر في غاية السّهولة. يقوم هذا القسم باستخدام الأسماء المُستعارة التي تم تعريفها أعلاه لإخبار sudo من لديه الحقّ للقيام بماذا وعلى أي مُضيف. الأمثلة تشرح نفسها ما دمت تفهم القواعد (Syntax) في هذا القسم. لننظر إلى القواعد في قسم الأوامر: ruser ALL=(ALL) ALL المثال أعلاه يقول بأنّ للمُستخدم ruser صلاحيات تُمكّنه من تنفيذ أي برنامج على أي مُضيف بصفة أي مُستخدم. هذه خانة عامّة للمُستخدم ruser. المقطع ALL الأول يدلّ على أنّ هذه القاعدة تُطبَّق على جميع المُضيفات. ALL الثّانيّة تسمح لـruser بتنفيذ الأوامر بصفة أي مُستخدم آخر. افتراضيّا، تُنفَّذُ الأوامر بصفة المُستخدم الجذر، لكنّ لـruser القدرة على انتحال صفة أي مُستخدم آخر عند استعمال الأمر sudo. المقطع ALL الأخير يعني بأنّ ruser يستطيع تنفيذ جميع الأوامر دون أية قيود. ما يمنح لـruser جميع صلاحيّات المُدير. لاحظ الخانة التي تمنح للمُستخدم root جميع صلاحيات الوصول لجميع الأوامر على جميع المُضيفات: root ALL=(ALL) ALL لتجربة هذا، قمت بتعليق (comment) السّطر أعلاه وحاولتُ تنفيذ الأمر chown بصفة المُستخدم الجذر دون sudo. تمّ تنفيذ الأمر. بعدها حاولت استخدام الأمر sudo chown، والذي فشل مع الرّسالة root غير موجود على ملفّ sudoers. سيتم الإبلاغ عن هذه الحادثة. ما يعني بأنّ المُستخدم الجذر قادر على تنفيذ أي أمر بصفته المُستخدم الجذر، لكن أي أمر سيفشل عند استعمال الأمر sudo. سيمنع هذا المُستخدمَ الجذر من تنفيذ أية أوامر بصفته مُستخدما آخر عبر الأمر sudo. لكنّ root يستطيع التحايل على هذا القيد بالعديد من الطّرق. الشّيفرة أسفله هي ما أضفته للتحكم بأحقية الوصول إلى برنامج myprog. يقول السّطر بأنّ المستخدمين الذين ينتمون إلى المجموعة AUDIO التي تم تعريفها أعلى الملفّ لديهم أحقيّة الوصول إلى برنامج واحد فقط (myprog) على مُضيف واحد (guest1). AUDIO guest1=/usr/local/bin/myprog سيُمكّن السّطر أعلاه المستخدمين المنتمين إلى مجموعة AUDIO من الوصول إلى البرنامج myprog على المُضيف guest1. لاحظ بأنّ السّطر أعلاه لا يُحدّد سوى المُضيف الذي يُمكن عليه تنفيذ البرنامج. ولا يُحدّد بأنّ للمُستخدم حريّة تنفيذ الأمر بصفة أي مُستخدم آخر. تجاوز كلمات المرور يُمكنك استخدام الكلمة المفتاحيّة NOPASSWORD لتمكين المُستخدمين المنتمين إلى المجموعة AUDIO من تشغيل برنامج myprog دون الحاجة إلى إدخال كلمة المرور الخاصّة بهم كما يلي: AUDIO guest1=NOPASSWORD : /usr/local/bin/myprog لم أُفعِّل هذا الخيار لبرنامجي، إذ يجب على مُستخدمي sudo التوقف والتفكير في ما يقومون به، وهذا يُساعد قليلا على ذلك. والسّطر أعلاه مُجرّد مثال توضيحيّ. المجموعة wheel معيار wheel المُحدّد في جزء الأوامر داخل ملفّ sudoers (كما هو موضّح أسفله) يقوم بالسماح لجميع المُستخدمين المُنتمين إلى المجموعة wheel بتنفيذ جميع الأوامر على أي مُضيف. تُعرَّف مجموعة wheel على الملفّ /etc/group، ومن الواجب إضافة المُستخدمين هناك. علامة % التي تسبق اسم المجموعة تعني بأنّ على sudo البحث عن هذه المجموعة في ملفّ /etc/group. %wheel ALL = (ALL) ALL يسمح السّطر أعلاه لجميع المُستخدمين الذين ينتمون إلى المجموعة wheel المعرّفة في ملفّ /etc/group بتشغيل جميع الأوامر على أي مُضيف. هذه طريقة جيّدة لتفويض كامل صلاحيّات المُستخدم الجذر لعدّة مُستخدمين دون توفير كلمة المرور الخاصّة بالمُستخدم الجذر. مجرّد إضافة مُستخدم إلى مجموعة wheel يُعطيهم كامل إمكانيّات المُستخدم الجذر. يسمح هذا كذلك بمُراقبة نشاطات المُستخدمين عبر مُدخلات التّسجيلات التي يقوم sudo بإنشائها. تُضيف بعض التوزيعات (مثل توزيعة Ubuntu) مُعرّفات المُستخدمين (user ID) إلى المجموعة wheel في ملفّ /etc/group، ما يسمح لهم باستخدام sudo لتنفيذ جميع الأوامر التي تتطلّب صلاحيّات المُستخدم الجذر. ختاما استعملت sudo هنا لغرض محدود (تمكين مستخدم أو مُستخدمَيْن من الوصول إلى أمر واحد). تمكّنت من تحقيق هذا الغرض عبر كتابة سطرَيْن فقط (دون احتساب التّعليقات). تفويض صلاحيات تنفيذ مهام مُحدّدة لمُستخدمين لا يمتلكون إمكانيّة الوصول إلى المستخدم الجذر عمليّة بسيطة يُمكن لها اقتصاد كم جيّد من الوقت لمُدير النظم. بالإضافة إلى ميّزة تسجيل نشاطات المُستخدمين التي تُساعد على إيجاد المشاكل. يُوفّر ملفّ sudoers كمًّا هائلًا من الإمكانيّات والخيارات. ألقِ نظرة على ملفّات man الخاصّة بـsudo وsudoers لمزيد من التّفاصيل. ترجمة -بتصرّف- للمقال Using sudo to delegate permissions in Linux لصاحبه David Both.

في الدرس السابق تحدثنا عن طرق تثبيت ووردبريس لأول مرة بأمان. في هذا الدرس، سنتحدّث عن كيفية تأمين موقع ووردبريس بعد تثبيته، سنتحدّث عن أساليب أفضل للحماية فوق مستوى نصائح "اختر كلمة مرور أكثر تعقيدًا" وسنحاول الغوص قليلًا في موضوع أمان ووردبريس. تقييد عمليات تسجيل الدخول واحدٌ من أول الأشياء التي يجب عليك فعلها لتأمين موقع ووردبريس الخاصّ بك هو تقييد عدد المرّات التي يمكن لشخصٍ ما أن يحاول تسجيل الدخول بها إلى الموقع. يحاول العديد من المخترقين القيام بهجمات التخمين أو ما يعرف بـ Bruteforce لمحاولة كسر اسم المستخدم / كلمة المرور الخاصّيَن بك، وحتّى لو لم تنجح هذه الهجمات في اختراق موقعك، فإنّه ستقوم باستهلاك جزء كبير من موارد خادومك وستقوم بوضع حملٍ عليه. عبر تقييد عمليات تسجيل الدخول، يمكنك منع المخترقين من محاولة القيام بهجمات Bruteforce. بمجرّد أن يقوم بمحاولة تخمين كلمة المرور مرتين أو ثلاث، فسيتم حظر عنوان الـIP الخاصّ به. يمكنك القيام بهذا الأمر بسهولة عبر تثبيت إصافة Limit Login Attempts، صحيحٌ أنّه لم يتم تحديثها منذ سنتين ولكنّها تمتلك مميزاتٍ رائعة، ولكن ربّما تودّ تجاهلها حاليًا بسبب انقطاع دعمها عن التحديثات الأمنية. عوضًا عن هذا، فإننا ننصح بإضافة Login Lockdown، تسمح لك هذه الإضافة أيضًا بتقييد عدد مرّات تسجيل الدخول الفاشلة قبل أن يتم حظر عنوان الـIP الخاصّ بالمستخدم الذي يحاول الدخول، كما يمكنك اختيار المدّة التي تريد حظر عنوان الـIP خلالها، ستصبح هجمات Bruteforce أصعب بكثير بعد تثبيت هذه الإضافة وضبطها، لأنّه سيجب على المخترقين استخدام وسيط (Proxy) بعد كلّ 3 محاولات فاشلة لتسجيل الدخول، وسيجب عليهم تغيير ذلك الوسيط آلاف المرّات ليتمكّنوا من تحقيق الهجوم، وهو الأمر الذي لا يتوفّر لديهم غالبًا. حظر المستخدمين الذين يحاولون تسجيل الدخول باسم Admin من المهم ألّا تستخدم اسم "admin" كاسم مدير الموقع على موقعك، ومن المهم أيضًا أن تقوم بحظر كلّ من يحاول الدخول إلى ذلك المستخدم (طالما أنتَ لستَ المدير، والحساب غير موجود، فلماذا تحاول الدخول؟ إذن فأنتَ مُخترِق)، يمكنك القيام بهذا عن طريق إضافة Wordfence. تسمح لك هذه الإضافة بإعداد ميزة الحظر التلقائي هذه، بالطبع، هناك العديد من المميزات الأخرى في هذه الإضافة التي يمكنك استخدامها من أجل الحماية، مثل الاستيثاق الثنائي (two-factor authentication)، حظر الهجمات الشائعة والمزيد. ضبط صلاحيات الملفّات الصحيحة شيءٌ آخر يمكنك فعله هو ضبط صلاحياتٍ مناسبة للملفّات على موقعك. وفقًا لـ WordPress.org، فإنّ استخدام صلاحيات 777 للملفّات / المجلّدات هو أمرٌ خطير للغاية ويسمح للجميع أن يقوموا بتعديل ملفّات موقعك وإضافة أكواد خبيثة أو حتّى حذف الموقع بالكامل. يجب عليك أن تقوم بوضع صلاحيات 600 لملفّ wp-config.php، بينما يجب عليك أن تقوم بتعيين ملفّاتك الأخرى إلى وضع صلاحيات 640 أو 644، كما يجب أن تكون المجلّدات الموجودة على موقعك بالصلاحيات 750 أو 755. يمكنك تعلّم المزيد عن الصلاحيات عبر دليل ووردبريس الرسمي لتغيير الصلاحيات. إنشاء ملف htaccess. إذا كنتَ تريد تركيبة روابط دائمة (permalinks) جميلة لموقعك فإنّك ستحتاج ملفّ htaccess. عبر إضافة واحدٍ إلى موقعك فإنّك ستقوم بتحسين مستوى الحماية قليلًا، صحيحٌ أنّه ليس حلًا كاملًا ولا يمكنه فعل شيء جوهري لوحده ولكنّه إضافة جيّدة. هناك شرح شامل منشور على الويب حول إنشاء ملفّ htaccess. ، لن نقوم بشرح تلك العملية بالكامل هنا لأنّ العملية مشروحة بذاك الدليل بشكلٍ شامل. بمجرّد أن تقوم باتّباع ذاك الشرح فإنّه سيصبح بإمكانك منع الوصول إلى ملفّات معيّنة على موقع ووردبريس الخاصّ بك. إذا لم يكن الناس قادرين على الوصول إلى تلك الملفّات التي تريدها فلن يكونوا قادرين على العبث بها. لزيادة صعوبة اختراق موقع ووردبريس الخاصّ بك ستحتاج إلى إضافة بضع سطور من الأكواد لحظر الوصول إلى ملفّات معينة مثل: wp-config.php readme.html license.txt wp-includes directory يمكنك أيضًا منع الوصول إلى امتدادات معيّنة للملفّات، مثل ملفّات النسخ الاحتياطي، الإعدادات، السجلات المحفوظة على الخادوم.. إلخ. بشكلٍ عام، يجب حظر الوصول إلى أيّ شيء يتعلّق بالتصميم والتطوير والتوثيق الخاصّ بخلفيّة الموقع (back-end). إذا كنتَ تريد حظر الوصول إلى مجلّد إضافة أو قالب معيّن أو مسارٍ آخر على موقعك، فيمكنك حظر المجلّد بأكمله إن أردت. هذه حركة جيّدة للقيام بها في كلّ مجلّد لا يمتلك بداخله ملفّ index. حيث أنّ المجلّدات التي لا تحتوي على ملفّات index ستقوم بعرض كلّ الملفّات الموجودة بداخل ذاك المجلّد، مما يعطي معلوماتٍ هامّة يمكن استغلالها من طرف المخترقين، لذا يجب عليك إخفاؤها. إخفاء صفحة تسجيل الدخول هذا تعديلٌ آخر يمكن القيام به عن طريق htaccess. ولكن مختلف قليلًا عن التعديلات الأخرى ولذلك سنذكره هنا. يمكنك حظر وصول أيّ شخص إلى صفحة تسجيل الدخول الخاصّة بموقعك ومنح حقّ الوصول فقط إلى عنوان الـIP الخاصّ بك، وطبعًا، يجب أن يكون هناك مستخدمٌ واحد فقط للموقع بأكمله، وبالتالي فتلك ليست طريقة عملية حقًا لاستخدامها. إذا كنتَ تريد إبقاء خيارٍ مفتوح لإضافة كتّابٍ ومستخدمين آخرين إلى موقعك لاحقًا، فيمكنك استخدام إضافة Secure Hidden Login. تسمح لك هذه الإضافة بإخفاء حقول الإدخال من صفحة تسجيل الدخول الخاصّة بموقعك، ويتم إظهار حقول الإدخال لاسم المستخدم وكلمة المرور فقط عند الضغط على اختصاراتٍ معيّنة على لوحة المفاتيح، فإن حاول أحدهم فتح صفحة تسجيل الدخول، فلن يتمكّن من ذلك دون أن يعرف ما هي اختصارات لوحة المفاتيح التي تقوم بعرض صفحة تسجيل الدخول. إزالة وسم Generator يقوم المخترقون بكلّ شيءٍ قد يمكّنهم من اختراق موقعك، واحدٌ من هذه الأشياء هو سكربتٌ شهير يستخدمه المخترقون لالتقاط المواقع التي تعمل بإصدارات معيّنة من ووردبريس عبر بصمات الأقدام (Footprints)، بصمات الأقدام هي عبارة عن سطور متعددة من الأكواد يمكن استخدامها للتعرّف على هوية موقع ويب ما، لسوء الحظّ فإن ووردبريس يستخدم هذه البصمات مما يجعل مواقع ووردبريس الموجودة على الشبكة قابلة للاكتشاف بسهولة. قد تبدو بصمة القدم الخاصّة بموقع ووردبريس كشيءٍ مثل: <meta name="generator" content="WordPress 3.8.4" /> يمكنك إزالة هذا الوسم إن أردت من الشفرة المصدرية الخاصّة بموقعك، ولكن ما يزال عليك إضافة الشفرة التالية إلى ملفّ functions.php الخاصّ بقالبك: remove_action('wp_head', 'wp_generator'); بعد هذا، لن يقوم موقع ووردبريس الخاصّ بك بتعريف نفسه على أنّه موقعٌ يعمل بسكربت ووردبريس، مما يصعّب المهمّة على المُخترقِين. تفعيل الاستيثاق الثنائي Two-Step Authentication شيءٌ آخر يمكنك فعله لتأمين موقعك هو تفعيل الاستيثاق الثنائي أو ما يدعى بـ Two-Step Authentication. عندما تقوم بطلب خطوتين للاستيثاق من مستخدمي موقعك عوضًا عن خطوة واحدة فإنّك تصعّب الأمر جدًا على المُخترقِين. هناك عدّة إضافات موجودة لتفعيل الاستيثاق الثنائي على ووردبريس ومن بينها: Clef: بمجرّد تثبيت هذه الإضافة، فإنّ كل ما سيجب عليك فعله هو فتح تطبيق Clef على هاتفك المحمول وتركيز كاميرا الهاتف على شاشة الحاسوب الخاصّة بك، بعدها سيتم فتح القفل الموجود على موقعك وتتمكن من الدخول. Duo Two-Factor Authentication: بعد أن تقوم بإدخال كلمة المرور الخاصّة بك في مربّع الإدخال التقليدي، سيجب عليك إكمال خطوةٍ أخرى لإتمام عملية تسجيل الدخول، مثل تأكيد تسجيل الدخول من على هاتفك الذكي عبر رسالة SMS وغيرها من الطرق. الخاتمة إدارة الحماية على موقع ووردبريس الخاصّ وإعداد عمليات تسجيل الدخول ليتم تقييدها قدر المستطاع هو أمرٌ قد يستغرق منك بعض الوقت، ولكن بمجرّد أن تكتمل هذه الأمور، فإنّ موقعك سيكون أكثر أمانًا لمستخدميه. ترجمة -وبتصرف- للمقال The WordPress Developer’s Guide to Security: Management & Logins لصاحبته Brenda Barron.

تحدد صلاحيّات الملفّات من يستطيع قراءة، إنشاء، تحرير ملف و/أو فتحه، وهذه العملية مهمّة في ووردبريس، لأنها قد تحتاج إلى إمكانية إنشاء ملفات جديدة في مجلد wp-content الّلازمة لعمل بعض الوظائف. إن عدم امتلاك ملفات الموقع للصلاحيات الضرورية والكافية يفتح المجال للآخرين للتطفّل على ملفّات موقعك، وقد لا يحميك تعيين الصلاحيات بشكل صحيح من جميع الهجمات الإلكترونية، لكنه سيساعدك في جعل موقعك أكثر أمانًا، حيث سيكون إجراءً أمنيًّا آخر يضاف إلى إجراءاتك الأمنية الحالية. يحتوي توثيق ووردبريس على بعض المعلومات حول صلاحيات الملفات الضرورية لـ ووردبريس، لكن قد يكون من الصعب متابعته لأنّه لا يشرح التفاصيل، لذا يهدف المقال إلى شرح تفاصيل صلاحيات الملفات والمجلّدات وكيفية تغييرها بغرض رفع أمان الموقع. كيف تبدو صلاحيات الملفات؟ توجد فئتان يجب أخذهما بعين الاعتبار عند التحدّث عن صلاحيات الملفّات: العمليّات ومستخدمو العمليّات. العمليّات وهي العمليات التي من الممكن تنفيذها على الملفّات: القراءة Read: تسمح بقراءة محتوى ملف فقط، ويتم تمثيلها بالحرف r كما سنرى لاحقًا. الكتابة Write: تسمح بإنشاء ملف جديد و/أو تعديل محتوى ملف موجود مسبقًا، ويتم تمثيلها بالحرف w. التنفيذ Execute: تعطي إمكانية تنفيذ الملف بغرض تشغيله كبرنامج أو سكربت، ويتم تمثيلها بالحرف x. ملاحظة: يجب الانتباه إلى عدم الخلط ما بين عمليّتي القراءة والتنفيذ، فالأولى تسمح بقراءة محتوى ملف (سواء كان ملف نصّي، أو صورة، أو برنامج حتّى) ولكنّها لازمة وغير كافية لتنفيذ محتوى الملف إن كان برنامجًا، فحينها يجب أن يمتلك ملف البرنامج إمكانيّتي القراءة والتنفيذ كي يكون بالإمكان تشغيله كبرنامج. أما مستخدمو العمليات فهم: المستخدم User: وهو مالك الملف owner، المجموعة Group: ويمكن أن تضم مستخدمين آخرين لهم صلاحية الوصول إلى الملفات التي تختارها والتي لهذه المجموعة صلاحية الوصول إليها; الطرف الثالث World: أي مستخدم آخر عدا ما ذُكر. ويمكن تمثيل صلاحيات الملفّات كمجموعات متتالية من الأرقام على الشكل rwxrwxrwx-: الرقم الأول rwx: صلاحيات الوصول الخاصة بمالك الملف user (أو owner). الرقم الثاني rwx: صلاحيات الوصول الخاصة بالمجموعة group. الرقم الثالث rwx: صلاحيات الوصول الخاصة بالطرف الثالث world. وللحصول على قيمة الرقم الخاص بِكلّ مجموعة سنقوم اعتمادًا على النظام الثنائيّ binary باستنباط الجدول التالي: نظام rwx الثُنائي binary القيمة بالنظام العُشري decimal إمكانيّة Read/Write/Execute 000 0 001 1 تنفيذ فقط 010 2 كتابة فقط 011 3 كتابة + تنفيذ 100 4 قراءة فقط 101 5 قراءة + تنفيذ 110 6 قراءة + كتابة 111 7 قراءة + كتابة + تنفيذ فاستنادًا للجدول السابق فإن أعلى صلاحية rwxrwxrwx- يمكن منحها بالنظام العُشريّ هي 777 حيث يكون لكلٍّ من المالك، المجموعة والطرف الثالث جميعهم، إمكانية القراءة والكتابة والتنفيذ، وبنفس الشكل يمكن القول بأنّ أقلّ صلاحية rwxrwxrwx- يمكن منحها (إلى جانب عدم وجود أيّ صلاحية على الإطلاق) هي 444، حيث يملك الجميع إمكانية القراءة فقط. لا تخف فهناك طريقة سهلة لتذكر الصلاحيات، فعلى سبيل المثال لو أردنا إعطاء مالك الملف كامل الصلاحيات والحدّ من صلاحيات باقي المستخدمين، فنقوم بما يلي: المستخدم User – سيملك إمكانية القراءة (4)، الكتابة (2) والتنفيذ (1)، فتكون قيمة الصلاحية النهائية (1+2+4=7) المجموعة Group – ستملك إمكانية القراءة (4) والكتابة (2)، فتكون قيمة الصلاحية النهائية (4+2=6) الطرف الثالث World – سيملك إمكانية القراءة فقط (4). إذًا، تصبح صلاحية الملف النهائيّة 764 أو rwxrw-r-- في هذا المثال، ولكنّ هذه الصلاحية غير مثاليّة لملفات مدوّنات ووردبريس، فقد تلاحظ بأن صلاحيات الملفّات تبدو مختلفة قليلًا عند التحقق منها عبر SSH أو FTP، كما في الصورة: تذكّر بأن الـ - (hyphen) في صيغة صلاحيّات الملفّات تمثّل غياب إمكانية ما، عدا أوّل - إلى أقصى اليسار والتي تبيّن فيما إذا كانت الصلاحية لملف أو مجلّد، فإن كانت لمجلّد حلّ محلّها الحرف d، الحرف الأول من كلمة directory. تجدر الإشارة إلى أنّ المحرف الأول إلى اليسار قد يملك قيمًا مختلفة عن الحرف d ولكن يندر أن تصادف هذا في ووردبريس. وكما ذكرنا سابقًا فإنّ كلّ مجموعة تمثّل الإمكانيات المسموحة لكل مجموعة مستخدمين، فإن أخذنا الصلاحية التالية rwxr-xr-x- فإنّ الـ - في أقصى اليسار تخبرنا بأنّ هذه صلاحية ملف، أما الـ rwx التي تليها فتخبرنا بأنّ المستخدم مالك الملف يملك إمكانية القراءة والكتابة والتنفيذ، بينما تملك مجموعة المستخدمين المالكة للملف إمكانية القراءة والتنفيذ، وأخيرًا يكون لباقي المستخدمين إمكانية القراءة والتنفيذ أيضًا، فإن قُمنا بتحويل نمط الصلاحية هذا إلى الشكل الرقمي لحصلنا على القيمة 755. من الجدير بالذكر بعد هذا الشرح المطوّل بأنّ الصلاحية 777 تعطي جميع المستخدمين كامل الصلاحيات وهذا غير مناسب أمنيًّا ويجب عدم استخدامه لمواقع ووردبريس على الأقل، وفي الوقت ذاته فإنّ الصلاحية 444 لن تكفي ليعمل موقع يستخدم ووردبريس. ما الصلاحيات اللازمة لمواقع ووردبريس؟ إن قمت بتنصيب ووردبريس بنفسك فإنّ الصلاحيات ستكون معدّة بشكل صحيح غالبًا، ولكن إن كنت تحصل على رسائل خطأ بصلاحيات الوصول أو كان موقعك معدًّا من قبل شخص آخر، فإنّ الوقت مناسب لمراجعة صلاحيات الملفّات. تختلف الصلاحيات المطلوبة باختلاف الإضافات plugins التي قد تستخدمها في موقعك والتي تتبع لطبيعة عمل الـ plugin، وستعتمد صلاحية الملفات والمجلّدات على إعدادات استضافتك، فإن كنت تستخدم خادومًا خاصًا بك بالكامل (dedicated server) فإنّ بالإمكان استخدام الصلاحيات التالية بشكل آمن تبعًا لما يذكره توثيق ووردبريس: للمجلّدات – 755 للملفّات – 644 أمّا الملفّات الأكثر خصوصية كملف الإعدادات الخاصة بـ ووردبريس والذي يتضمن معلومات حسّاسة wp-config.php، فيمكن استخدام الصلاحية 600 معه، ويستثنى من ذلك ملف htaccess. والذي يحتاج موقع ووردبريس للوصول إليه ليتم تحديث محتواه بشكل اوتوماتيكي، فينصح باستخدام الصلاحية 644 معه أو الصلاحية الأكثر أمنًا 604 في معظم الحالات. كيف يمكن التحكم بصلاحيات الملفات؟ يمكن إيجاد صلاحيات الملفات المذكورة على أنظمة لينكس/يونكس فقط، فإن فرضنا أنّ الاستضافة مزوّدة بلوحة تحكّم cPanel فعندها للوصول إلى صلاحيات الملفات نتوجّه بعد تسجيل الدخول إلى: Files > File Manager وعند ظهور نافذة اختيار المجلّد الرئيسي، نضغط زر Go أسفل النافذة. بعد ظهور صفحة إدارة الملفات، نختار أيّ ملف ثم نضغط على أيقونة Change Permissions في أعلى الصفحة. ستظهر الآن نافذة منبثقة تحوي على صلاحيات الملف أو المجلّد الذي قمنا باختياره، والتي يمكن من خلالها التعديل عليها: إضافة لما سبق فإنّ بالإمكان التعديل على الصلاحيات عبر برنامج إدارة الملفّات باستخدام FTP، فمثلًا باستخدام FileZilla بعد إتمام الاتصال، يمكن الوصول إلى صلاحيات الملف بالضغط بالزر الأيمن على الملف أو المجلّد المطلوب واختيار File permissions: حيث ستظهر نافذة يمكن خلالها التعديل على الصلاحيات كالمعتاد أيضًا: وأخيرًا يمكن التعديل أيضًا على الصلاحيات عبر سطر الأوامر من خلال SSH بعد تسجيل الدخول، باستخدام الأمر التالي: للمجلّدات find /path/to/your/wordpress/install/ -type d -exec chmod 755 {} \; للملفّات find /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \; سيقوم الأمر السابق بإعادة ضبط صلاحيات جميع المجلّدات في المسار المحدّد لتأخذ الصلاحية 755 وجميع الملفّات لتأخذ الصلاحية 644، وبالطبع لا تنس التأكّد من إدخال مسار تثبيت ووردبريس بشكل صحيح قبل التنفيذ. الخلاصة قمنا بتغطية الأساسيات الخاصّة بصلاحيات الملفات الّلازمة لعمل ووردبريس وكيفية تغييرها من خلال لوحة تحكم cPanel أو من خلال بروتوكوليّ FTP و SSH، لكن يبقى تحديث إصدار ووردبريس أمرًا ضروريًّا من الناحية الأمنيّة، فإنّ هذا يضمن بأنّ صلاحيات الملفات سيتم ضبطها بشكل تلقائيّ إلى الوضع الأمثل. إن كنت تفضّل استخدام الإضافات، فهناك 3 منها يمكنك تجربتها: Triagis® WordPress Security Evaluation SECURE BulletProof Security حيث تقوم هذه الإضافات بالتحقّق من صلاحيات الملفات وتخبرك إن كان هناك إعدادات غير مقبولة. هل احتجت من قبل لإصلاح صلاحيات الملفات لديك؟ شاركنا تجربتك عبر التعليقات في الأسفل. ترجمة -وبتصرّف- للمقال Understanding File Permissions and Using Them to Secure Your Site لصاحبته Jenni McKinnon.

يشكّل ضبط إعدادات المستخدمين والمجموعات في لينكس واحدًا من المهارات الأساسية لإدارة نظام التشغيل، ويتضمن ذلك مراقبة تسجيلات الدخول الممكنة لكافة مكونات النظام. نستعرض في هذا الدرس المعلومات الأساسية عن إدارة المستخدمين وتسجيلات الدخول، سنطبق أمثلتنا على توزيعة Ubuntu 14.04 إلا أنه يمكنك بالتأكيد المتابعة مهما كانت التوزيعة التي تستخدمها. استعراض المستخدمين الحاليينتخزّن أسماء ومعلومات جميع مستخدمي نظام لينكس ضمن ملف etc/passwd/ سواءً أكانت تشير إلى مستخدمين حقيقيين (مثلي ومثلك) أو مرتبطة بتشغيل إحدى الخدمات أو وظائف النظام. يتضمن الملف etc/passwd/ معلومات حول المستخدمين المنشأين على نظام التشغيل موزعة على عدّة أسطر، بحيث يُخصّص سطر لكل مستخدم، لنلقِ الآن نظرة على محتويات الملف: less /etc/passwdroot:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/bin/sh … ينقسم كل سطر من الأسطر السابقة إلى عدّة خانات يفصل بينها علامة النقطتين (:)، وما يهمنا من هذه الخانات حاليًا هي الخانة الأولى والتي تعبّر عن الاسم الفريد لكل مستخدم، كما يمكن من خلال الأمر التالي الحصول على القائمة السابقة مُضمّنة بأسماء المستخدمين فحسب: cut -d : -f 1 /etc/passwdroot daemon bin sys sync games … وكما ترى حصلنا في هذه المرة على أسماء المستخدمين فقط، السطر الأول مثلًا يحوي اسم المستخدم الإداري ذي الصلاحيات المطلقة root، كما ستجد في القائمة اسم المستخدم الخاص بك، وبين هذا وذاك هناك عددٌ آخر من المستخدمين قد لا تكون مُلِمًا بوظائفهم، مثل المستخدم dbus والذي يُشغّل بواسطة خدمة dbus، أو polkitd المسؤول عن خدمة polkit، وهكذا.. ففي لينكس يتم فصل صلاحيات المهام كلًّا على حدى، وبهذه الطريقة نضمن ألّا تنتقل أيّة مشاكل محتملة في خدمة ما إلى سائر مكونات النظام. استعراض المجموعات الحاليةتخزّن أسماء المجموعات وبعض المعلومات عنها في ملف etc/group/، والذي يمكننا استعراض محتوياته بالأمر التالي: less /etc/grouproot:x:0: daemon:x:1: bin:x:2: sys:x:3: adm:x:4: tty:x:5: disk:x:6: … وكما ترى فإن معظم الأسماء هنا ورد ذكرها في قائمة "المستخدمين الحاليين" منذ قليل، وهذا يدفعنا للتساؤل؛ لمَ؟ يعود السبب في ذلك إلى ما يسمى بـ"مجموعات المستخدم الخاصة" user private group أو UPG، وهو أسلوب في الإدارة والإعداد يسهّل إدارة المجموعات في لينكس، بحيث تنشئ مجموعة خاصة بكل مستخدم تتم إضافته، وتحمل هذه المجموعة ذات اسم المستخدم، وتُعيّن لتكون مجموعته الرئيسيّة، ويكون هو عضوها الوحيد، وحينها يغيّر قناع الطرح لـ umask من 022 إلى 002. ماذا يعني ذلك؟ تسمح هذه العملية بمزيد من المرونة في حالة عمل فريق ما ضمن مشروع، فبدلًا من أن تعود ملكية كل ملف يتم إنشاؤه في المشروع إلى الشخص المُنشئ، تنسد ملكية الملفات في هذه الحالة إلى ذات المجموعة المالكة للمجلد الأب، مما يسهل عملية التشارك. يتم ذلك عبر صلاحية تسمى setgid، إلا أنّ ذلك كلّه خارج نطاق موضوعنا اليوم. هنا أيضًا يمكن عرض أسماء المجموعات فقط من مجمل محتويات الملف etc/group/ عبر الأمر: cut -d : -f 1 /etc/grouproot daemon bin sys adm tty disk … معرفة المستخدم المُسجّل حاليًايتيح الأمر w في لينكس معرفة المستخدم النشط حاليًا على نظام التشغيل بالإضافة إلى مجموعة من المعلومات المهمة عنه، مثل توقيت تسجيل الدخول والأمر المستخدم حاليًا: w19:37:15 up 5:48, 2 users, load average: 0.33, 0.10, 0.07 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root pts/0 rrcs-72-43-115-1 19:15 38.00s 0.33s 0.33s -bash demoer pts/1 rrcs-72-43-115-1 19:37 0.00s 0.47s 0.00s w إضافة للأمر w تعرض التعليمة who معلومات أكثر اختصارًا، تتضمن اسم المستخدم النشط وتوقيت دخوله فقط: root pts/0 2013-09-05 19:15 (rrcs-72-43-115-186.nyc.biz.rr.com) demoer pts/1 2013-09-05 19:37 (rrcs-72-43-115-186.nyc.biz.rr.com) تقييد تسجيلات دخول المستخدمينتقييد تسجيلات الدخول باستخدام etc/passwd/يمكن من خلال التعديل على ملف etc/passwd/ تقييد تسجيل دخول أحد المستخدمين عن طريق إسناد قيمة معينة للصدفة shell المحدّدة له، لنفترض أنه لدينا مستخدم مسجّل بالاسم "messagebus" ضمن ملف etc/passwd/: less /etc/passwd | grep messagebus messagebus:x:102:104::/var/run/dbus:/bin/false قيمة الحقل الأخير في الخرج السابق تعبّر عن الأمر الذي يتم تنفيذه عقب تسجيل الدخول بنجاح، وهي في مثالنا هنا bin/false/. فإذا حاولت تسجيل دخول المستخدم messagebus كمستخدم جذر root فستلاحظ عدم نجاح المحاولة، وفشل التحويل إلى المستخدم الجديد: sudo su messagebus لنحاول الآن تسجيل الدخول بواسطة المستخدم sshd: sudo su sshd This account is currently not available.حصلنا على الرسالة السابقة بسبب قيمة الصدفة shell المستخدمة لـ ssh وهي usr/sbin/nologin/. less /etc/passwd | grep sshd sshd:x:103:65534::/var/run/sshd:/usr/sbin/nologin أظن أنك قد عرفت الآن كيف نمنع دخول أحد المستخدمين بواسطة هذه الطريقة؟ ببساطة سنستخدم الأداة usermod لتغيير قيمة الصدفة shell من إحدى قيمها المسموحة إلى أخرى وهمية: sudo usermod -s /usr/sbin/nologin usernameتقييد تسجيلات الدخول باستخدام etc/shadow/يتيح التعديل على ملف etc/shadow/ طريقة أخرى مشابهة لتقييد تسجيلات الدخول، وهو ملف يضم كلمات سر مستخدمي النظام بشكل مشفّر، ولاستعراض محتوياته يمكننا كتابة الأمر التالي في الطرفية: sudo less /etc/shadowroot:6r79Dod3Y$3hi3QklpGEQMxwQGEss4ueNNPkoUrqUe3SwyAacaxl.Lmgq1r9i4mTblV1z6NfKMNXH1Cpnq.4iKhOiQd7Riy1:15953:0:99999:7::: daemon:*:15455:0:99999:7::: bin:*:15455:0:99999:7::: sys:*:15455:0:99999:7::: sync:*:15455:0:99999:7::: games:*:15455:0:99999:7::: man:*:15455:0:99999:7::: …يُعرَض الخرج السابق على عدّة أسطر، بحيث يُخصّص سطر لكل مستخدم، ويضم كل سطر اسم المستخدم في الخانة الأولى، وكلمة السر بشكل مشفّر في الخانة الثانية "6r79Dod3Y#3…" مسبوقة بإشارة ($)، أما الخانات التي تبدأ بعلامة النجمة (*) ولا تتلوها قيمة مشفرة من المحارف فهي تخصّ المستخدمين المتعلقين بإدارة خدمات النظام، والتي لا تملك كلمات مرور، ولا يمكنها تسجيل الدخول كمستخدم عادي. يمكننا تعطيل خانة كلمة المرور لأحد الحسابات بوضع إشارة التعجب(!) أمام قيمتها المشفّرة (تسمى هذه العملية بقفل الحساب)، ولإجراء ذلك يمكننا الاستعانة بواحدة من الأداتين التاليتين: أولًا الأمر passwd والذي يتيح قفل حساب مستخدم ما بواسطة الخيار "l-" أو إلغاء قفله مع الخيار"u-": sudo passwd -l username sudo less /etc/shadow | grep username username:!$6$vpNJ3oFe$5GSh2aU2BDcpdjvQeNFzh0zTgyRUl26x4dn77mFE/vaoXwd19m7okX44jO8TWaVqNRL8vUVTAcZVmgUT8dR.4.:15953:0:99999:7:::وكما ترى فإن كلمة المرور تبقى موجودة ضمن الملف بقيمتها المشفرة إلا أنها غير فعّالة بسبب وجود إشارة التعجب (!) أمامها. ولإلغاء قفل الحساب مجددًا يمكننا كتابة: sudo passwd -u username بِذَات الطريقة يمكن استخدام الأمر usermod لقفل أو إلغاء قفل حسابات المستخدمين وفق الخيارات "L-" و "U-" على الترتيب: sudo usermod -L username sudo usermod -U username يجب الانتباه هنا إلى أن هذه الطريقة في القفل تعمل مع حسابات المستخدمين العاديين أي تلك التي تستخدم كلمة مرور لتوثيق دخولها، بينما لا تعمل مع حسابات المستخدمين الخاصة بخدمات النظام (ممن لا تملك كلمة مرور). تقييد تسجيلات الدخول باستخدام etc/nologin/في بعض الحالات الحرجة قد تحتاج لتعطيل تسجيلات دخول كافة المستخدمين باستثناء المستخدم الجذر root، مثل حالات الصيانة الشاملة، أو فيما لو تعرض أحد تلك الحسابات لاختراق أمني. عمومًا، يمكن إنجاز ذلك ببساطة، عن طريق إنشاء ملف فارغ باسم etc/nologin/: sudo touch /etc/nologin بهذه الطريقة تمنع كافة تسجيلات الدخول للنظام باستثناء من يملك امتيازات المستخدم الجذر، حيث تتم إعادة المستخدمين إلى الصدفة المحليّة local shell أو إخبارهم بأن التوثيق خاطئ! ولإضافة بعض التوضيح يجب ألا يترك الملف السابق فارغًا، بحيث تطبع عبارة على الشاشة تقدّم بعض الشرح: sudo sh -c 'echo "Planned maintenance. Log in capabilities will be restored at 1545 UTC" > /etc/nologin' لنقوم بتجربة جديدة الآن لاختبار ما سبق: ssh user@host user@host's password: Planned maintenance. Log in capabilities will be restored at 1545 UTC Connection closed by host عند الانتهاء من التعامل مع الوضع الحرج يمكن إعادة كل شيء على حاله بحذف الملف السابق etc/nologin/: sudo rm /etc/nologinمراقبة تسجيلات الدخولبعد ضبط مختلف الإعدادات المتعلقة بالمستخدمين والمجموعات لديك، نأتي الآن إلى مهارة أخرى أساسية تتعلق بمراقبة النظام، إذ تحتفظ أنظمة لينكس الحديثة بسجلات لكافة محاولات تسجيل الدخول في ملف مستقل يخزّن على المسار var/log/auth.log/: sudo less /var/log/auth.logMay 3 18:20:45 localhost sshd[585]: Server listening on 0.0.0.0 port 22. May 3 18:20:45 localhost sshd[585]: Server listening on :: port 22. May 3 18:23:56 localhost login[673]: pam_unix(login:session): session opened fo r user root by LOGIN(uid=0) May 3 18:23:56 localhost login[714]: ROOT LOGIN on ‘/dev/tty1’ Sep 5 13:49:07 localhost sshd[358]: Received signal 15; terminating. Sep 5 13:49:07 localhost sshd[565]: Server listening on 0.0.0.0 port 22. Sep 5 13:49:07 localhost sshd[565]: Server listening on :: port 22 … باستخدام الأمر lastيتيح لنا الأمر last استعراض تسجيلات الدخول الأخيرة لنظام التشغيل موزعة على جدول: lastdemoer pts/1 rrcs-72-43-115-1 Thu Sep 5 19:37 still logged in root pts/1 rrcs-72-43-115-1 Thu Sep 5 19:37 - 19:37 (00:00) root pts/0 rrcs-72-43-115-1 Thu Sep 5 19:15 still logged in root pts/0 rrcs-72-43-115-1 Thu Sep 5 18:35 - 18:44 (00:08) root pts/0 rrcs-72-43-115-1 Thu Sep 5 18:20 - 18:20 (00:00) demoer pts/0 rrcs-72-43-115-1 Thu Sep 5 18:19 - 18:19 (00:00)يُستمد الخرج السابق من الملف etc/log/wtmp/. وكما نرى فإن السطرين الأول والثالث يوضحان لنا بأن المستخدم لا يزال قيد الدخول logged in، أما في باقي الأسطر فيعرض توقيت كل جلسة والزمن المستغرق فيها. باستخدام الأمر lastlogإذا رغبت باستعراض السجّل السابق من زاوية أخرى، فيمكنك مشاهدة توقيت آخر مرة سجّل بها مستخدمو النظام دخولهم وذلك عبر الأمر lastlog والذي يعرض لنا محتويات الملف etc/log/lastlog/ مرتبة وفقًا لمدخلات الملف etc/passwd/: lastlogUsername Port From Latest root pts/1 rrcs-72-43-115-1 Thu Sep 5 19:37:02 +0000 2013 daemon **Never logged in** bin **Never logged in** sys **Never logged in** sync **Never logged in** games **Never logged in** …كما ترى يعرض الخرج السابق تاريخ آخر تسجيل دخول لكل مستخدم، بينما تُعرض العبارة "Never logged in" أمام المستخدمين الذين يتم إنشاؤهم لإدارة خدمات النظام، والذين لا يملكون كلمات مرور كما مرّ معنا. خاتمةإنه لمن المهم أن نعلم أين يحتفظ النظام بالمعلومات المتعلقة بتسجيلات الدخول، وذلك بهدف مراقبة التغييرات التي قد تشك بأمرها، لتعطيل تسجيل الدخول عن بعض أو كل المستخدمين. ترجمة -وبتصرف- للمقال Configuring and Managing Users and Groups لصاحبه Justin Ellingwood.

إحدى المميزات الرئيسية لووردبريس والتي عادة لا يعرف عنها الكثيرون هي أن هناك رتبًا للأعضاء مختلفة الصلاحيات والمستويات. وهي تساعد على التأكد من وصول المستخدمين للأماكن التي يحتاجونها فقط دون العبث بأدوات قد تتسبب بتوقّف الموقع. سنتحدث عنها باختصار في هذا المقال بالإضافة إلى كيفية إنشاء رتب أعضاء مُخصَّصة بنفسك. لقد كانت رتب الأعضاء جزءًا لا يتجزأ من تجربة ووردبريس منذ الإصدارة رقم 2.0. ومع ذلك لا يدرك معظم الناس وجودها، فيمنحون حقوق الإدارة الكاملة لكل شخص يملك وصولًا إلى لوحة التحكم الخاصة بهم (وهذا بالطبع غير مستحب لأسباب عديدة). يأتي ووردبريس مجهزًا بستّ رتب افتراضية: مدير: يملك جميع الخصائص والوظائف الإدارية في الموقع.محرر: يمكنه نشر وإدارة مقالات جميع المستخدمين، بما في ذلك مقالاتهم الخاصة.مؤلف: يمكنه نشر وإدارة مقالاته الخاصة.مساهم: يمكنه كتابة وإدارة مقالاته الخاصة ولكن لا يمكنه نشرها.مشترك: يمكنه فقط إدارة نبذته الخاصة.لِم نستخدم رتب الأعضاء المُخصَّصة؟بالنسبة لمعظم الناس تفي رتب الأعضاء الافتراضية بالمطلوب. ولكن هناك حالات تحتاج فيها لرتبة ذات صلاحيات مختلفة عن الصلاحيات المتاحة في الرتب الافتراضية. وفي هذا المقال سنعرف كيف تنشئ رتب أعضاء مُخصَّصة بنفسك دون الاستعانة بالإضافات. دعنا نلقِ مثالًا من العالم الواقعي. إذ عادة ما أستخدم رتب الأعضاء المُخصَّصة للتأكد من أن عملائي يملكون نفاذًا فقط للأشياء التي يحتاجونها. قد يختلف البعض مع هذا بحجة أنه موقع العميل ويجب أن يملك صلاحيات المدير بصفته المالك. وهذا صحيح إذا كنت ستسلم الموقع إلى العميل ولن تكون مسئولًا عن صيانة الموقع. لكن إذا كنت مسئولًا عن الحفاظ على الموقع قائمًا وفعّالًا طوال اليوم، فهنا أقترح عليك تحديد صلاحيات العميل عن طريق رتبة مُخصَّصة. هكذا أستطيع منح العميل كل شيء يحتاجه للإبقاء على موقعه نشطًا، مثل إضافة المحتوى، وربما إضافة فعاليات أو أي شيء يريدون فعله. ولكن ما لا يستطيعون فعله هي الأشياء التي قد تتسبب بسقوط الموقع أو تعطيل وظيفته. إذ أحظر صلاحيات إضافة أو حذف الإضافات والقوالب، وتحديث البنية الأساسية، وكل الوظائف التي تقع ضمن مجالي في صيانة الموقع. وظائف ووردبريس الأساسيةلإدارة الرتب والصلاحية بكفاءة، هناك خمس وظائف بسيطة: ()add_role: تتيح لك إضافة رتبة مُخصَّصة.()remove_role: تتيح لك حذف رتبة مُخصَّصة.()add_cap: تتيح لك إضافة صلاحيات جديدة إلى الرتبة.()remove_cap: تتيح لك حذف صلاحيات من الرتبة.()get_role: تعرض لك معلومات عن رتبة ما بالإضافة إلى الصلاحيات المُلحقة بها.سنستخدم فقط وظيفة ()add_role في هذا المقال عند إنشاء رتبة مُخصَّصة لعميلنا الخيالي. تحديد صلاحيات رتبة العضوقبل أن نبدأ في كتابة النص البرمجي علينا أن نجهز خطة، لأنه ليس من المستحب البداية في البرمجة دون خطط. أولًا، نحتاج لتسمية رتبة العضو خاصتنا. ويمكننا تسميتها ببساطة "عميل Client”. ثانيًا، نحتاج لتحديد صلاحيات رتبة "عميل". هناك حوالي 50 صلاحية مختلفة للاختيار منها في النسخة الافتراضية من ووردبريس (ويزداد العدد عند إنشاء الإضافات). هدفنا هو أن يستطيع العميل فعل الآتي: إنشاء المقالات.تعديل المقالات.تعديل مقالات الآخرين.إدارة التصنيفات.تعديل الصفحات.وفي الوقت ذاته لا نريده أن يستطيع فعل الآتي: تعديل القوالب.إضافة أو حذف الإضافات.تحديث البنية الأساسية.كتابة النص البرمجيسنضيف هذا النص البرمجي إلى ملف functions.php التابع لقالبنا الفعّال. لذا دعنا نبدأ بإضافة الآتي: // إضافة رتبة عضو مُخصَّصة $result = add_role( 'client', __('عميل' ), array( ) );هكذا أنشأت بإضافة ذلك النص البرمجي رتبة عضو جديدة (يمكنك العثور عليها في القائمة المنسدلة في صفحة أضف عضو جديد). لكن هذه الرتبة لا تمتلك صلاحيات بعد. لذا فالخطوة التالية بالطبع ستكون إضافة صلاحيات تفي بالمتطلبات التي ذكرناها سابقًا. فقط أضف نص المتتالية array إلى النص السابق الذي قمت بإدخاله في ملف functions.php. // إضافة رتبة عضو مُخصَّصة $result = add_role( 'client', __('عميل' ), array( 'read' => true, // تسمح بصلاحية القراءة 'edit_posts' => true, // تسمح للمستخدم بتعديل مقالاته الخاصة 'edit_pages' => true, // تسمح للمستخدم بتعديل الصفحات 'edit_others_posts' => true, // تسمح للمستخدم بتعديل مقالات الآخرين 'create_posts' => true, // تسمح للمستخدم بإنشاء مقالات جديدة 'manage_categories' => true, // تسمح للمستخدم بإدارة التصنيفات 'publish_posts' => true, // تسمح للمستخدم بنشر المقالات، أو ستُحفظ كمسودّات ) ); هذا سيعطينا الصلاحيات التي تمَكّن المستخدم من فعل ما يحتاجه، ولكننا ما زلنا بحاجة لحظر الصلاحيات التي قد تؤدي إلى سقوط الموقع. لذا سنضيف النص التالي: // إضافة رتبة عضو مُخصَّصة $result = add_role( 'client', __('عميل' ), array( 'read' => true, // تسمح بصلاحية القراءة 'edit_posts' => true, // تسمح للمستخدم بتعديل مقالاته الخاصة 'edit_pages' => true, // تسمح للمستخدم بتعديل الصفحات 'edit_others_posts' => true, // تسمح للمستخدم بتعديل مقالات الآخرين 'create_posts' => true, // تسمح للمستخدم بإنشاء مقالات جديدة 'manage_categories' => true, // تسمح للمستخدم بإدارة التصنيفات 'publish_posts' => true, // تسمح للمستخدم بنشر المقالات، أو ستبقى كمسودّات 'edit_themes' => false, // تمنع المستخدم من تعديل القوالب 'install_plugins' => false, // لا يستطيع المستخدم تنصيب إضافات جديدة 'update_plugin' => false, // لا يستطيع المستخدم تحديث الإضافات 'update_core' => false // لا يستطيع المستخدم تحديث البنية الأساسية ) );كيف تتأكد أن رتبة العضو قد أضيفت بشكل صحيحللتأكد من أن رتبة العضو تعمل جيدًا، سننشئ عضوًا جديدًا بالرتبة المذكورة، ثم نسجل الدخول إلى العضوية الجديدة ونلاحظ التغير الحاصل في الأدوات المتاحة في لوحة التحكم، وهذا بناءً على أيّ الصلاحيات منحتها وأيّهم منعتها. وتظهر الصورة بالأسفل ما يجب أن تراه إذا أضفت رتبة العضو كما فعلنا سابقًا. كما ترى، الأدوات المتاحة لهذا العضو قد قلت كثيرًا نتيجة للصلاحيات التي تم منحها ومنعها. يمكنك أن ترتاح الآن كمطور/مدير للموقع أنك لن تستقبل رسالة من العميل يقول فيها "لا أعرف ماذا حدث، ولكن فجأة لم يعد موقعي موجوداً". مترجم بتصرف من مقال How to Create Custom User Roles in WordPress لكاتبه Al Davis.

تتيح الأذونات في لينكس لمالك ملف أو مجلد ما من حصر الوصول لهذا الملف أو المجلّد بناءً على الصلاحيات المرتبطة به، وهذا ما يسمح بتعدّد حقيقي للمستخدمين في لينكس حيث يمتلك كلّا منهم مستويات مختلفة من التحكّم لحماية ملفاته. يُحدّد الأمر umask الأذونات الافتراضية للملفات التي ينشئها كل مستخدم على حدى، كما يتيح إمكانية تعديل هذه الأذونات لاحقًا لضمان حماية عالية للملفات، أو لتوسيع الأذونات بغرض مشاركة الملفات مع الآخرين، اعتمادًا على احتياجاتك الخاصة ومتطلبات النظام. نتناول في هذا الدليل أساسيات التعامل مع الأذونات في لينكس، بحيث ترى فوائد إعداد umask بشكل صحيح، كما سنتكلم باختصار عن الأمر chmod باعتباره أحد أشهر الأدوات المرتبطة بإدارة الأذونات. فئات المستخدمينبالنسبة للقادمين من Windows قد تبدو مسألة الأذونات في لينكس غامضة بعض الشيء، إلا أنه حالما تتعرف على الطريقة التي نرمّز بها للأذونات فسيغدو كلّ شيء واضحًا تمامًا، وستتمكن من التعديل بسهولة على تصاريح الملفات والمجلدات. فئة المالكصُمم لينكس ليسمح بتعدّدٍ حقيقي للمستخدمين، وهذا يعني أن كلّ ملف مملوك من قبل مستخدم واحد فقط، وحتى لو كنتَ المستخدم الوحيد لحاسبك أو خادومك الخاص، فإنه لا يزال هناك عدد آخر من المستخدمين المُنشئين مسبقًا بغرض تشغيل برامج أو خدمات معينة، ويمكنك بطباعة الأمر التالي الحصول على قائمة بأسمائهم: cat /etc/passwdroot:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/bin/sh man:x:6:12:man:/var/cache/man:/bin/sh lp:x:7:7:lp:/var/spool/lpd:/bin/sh mail:x:8:8:mail:/var/mail:/bin/sh news:x:9:9:news:/var/spool/news:/bin/sh uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh . . .يعرض الخرج السابق محتويات ملف etc/passwd/ وهي عبارة عن معلومات المستخدمين المنشئين على نظام تشغيلك؛ موزعةً على عدّة أسطر (سطر لكل مستخدم)، حيث تضم الخانة الأولى من كل سطر الاسم المميز لكل مستخدم، والذي غالبًا ما يرتبط بخدمات وتطبيقات مختلفة. إذ تنشئ بعض البرامج عادةً اسم مستخدم مستقل بحيث تدار جميع الخدمات المتعلقة بها من خلاله، مما يعطينا قدرة على التحكم بالوصول لهذه الخدمات. فئة المجموعة المالكةإضافة إلى فئة المالكين يمكن إسناد الأذونات إلى "مجموعة المالك" لملف أو مجلّد معيّن، وكما ذكرنا مع فئة المالك، لا يمكن أن تعود ملكية الملف سوى لمجموعة واحدة فقط، بينما يمكن لأي مستخدم أن ينضم لأكثر من مجموعة، وأن تضم كل مجموعة عدّة أعضاء أو مستخدمين. لمعرفة المجموعات التي ينتمي لها مستخدمك الحالي، اطبع الأمر: groups سيعرض الخرج أسماء المجموعات التي سبق لمستخدمك الانضمام لها، وبشكل افتراضي ينتمي أي مستخدم لمجموعة واحدة على الأقل (والتي تسمى باسمه وتعتبر مجموعته الخاصة)، إضافة إلى مجموعة أخرى. بينما يمكن استعراض جميع المجموعات المنشأة على نظامك الحالي من خلال الأمر: cat /etc/group root:x:0: daemon:x:1: bin:x:2: sys:x:3: adm:x:4: tty:x:5: disk:x:6: lp:x:7: . . .يطبع الأمر السابق محتويات الملف etc/group/ على الشاشة، وهو يتألف من عدّة أسطر، يمثّل كلّ واحدٍ منها مجموعة ما، ويحمل الحقل الأول من كل سطر اسم المجموعة. وباعتبار أنه لا يمكن امتلاك الملف سوى من قبل مستخدم وحيد، ولتسهيل عملية المشاركة يتيح لينكس إمكانية إعطاء صلاحيات مخصصة لمجموعة من المستخدمين، تسمى هذه المجموعة بالمجموعة المالكة للملف. فئة الآخرينأخيرًا يمكن إعطاء صلاحيات الملفات في لينكس إلى فئة ثالثة تسمى "الآخرين"، ونقول عن مستخدم ما أنه ينتمي لتصنيف الآخرين، إذا لم يكن مالكًا للملف وليس عضوًا في مجموعة المالكين له. يتيح لك هذا التصنيف إمكانية وضع الأذونات العامة المتاحة لمن هم خارج التصنيفين السابقين (المالك، والمجموعة المالكة). أنواع الأذوناتيمكن لكل فئة من الفئات الثلاث السابقة (المالك، المجموعة المالكة، والآخرين) الحصول (أو عدم الحصول) على واحدة أو أكثر من الصلاحيات التالية: القراءة، الكتابة، والتنفيذ. بالنسبة للملف، فإن صلاحية القراءة تعني إمكانية استعراض محتوى الملف، وصلاحية الكتابة ترتبط بالقدرة على التعديل عليه (بما في ذلك حذفه)، بينما تعني صلاحية التنفيذ القدرة على تشغيل الملف فيما لو كان نصًا تنفيذًا script أو برنامجًا. أما فيما يتعلق بالمجلدات، تمنح صلاحية القراءة إمكانية الاستعلام ls عن محتويات المجلد (من ملفات ومجلدات)، أما صلاحية الكتابة فتسمح بتعديل محتوياته، وصلاحية التنفيذ تسمح بالدخول إلى المجلد cd والتعديل عليه. تُمثّل الصلاحيات في لينكس بطريقتين، تدعى الأولى بالترميز الأبجدي ويستخدم فيها الأحرف، بينما تسمى الأخرى بالترميز العددي (الثُماني) وتستخدم فيها الأرقام. الترميز الأبجدييمتاز الترميز الأبجدي للصلاحيات بأنه أقرب للفهم وأسهل في الاستخدام كما أنه مستعمل من قبل عدّة برامج شائعة لإدارة الأذونات في لينكس، حيث يرمّز لكل واحدة من الصلاحيات بحرفٍ واحد: صلاحية القراءة تأخذ الحرف r.صلاحية الكتابة تأخذ الحرف w.صلاحية التنفيذ تأخذ الحرف x.ويجب الانتباه هنا إلى أن الصلاحيات في لينكس تُحدّد دومًا وفق هذا الترتيب. لإسناد صلاحية معينة لملف ما يتم استخدام الحرف المقابل لها، أما لمنع الصلاحية عن الملف فنستخدم الشرطة (-)، ويتم إعطاء الصلاحية عبر تمرير ثلاث مجموعات من القيم بشكل متتابع، تحدّد الأولى صلاحية المالك، وتحدّد الثانية صلاحية المجموعة المالكة، بينما تحدّد الأخيرة صلاحية الآخرين. يُرجع الأمر ls مع الخيار l- قائمة بمحتويات المجلد الحالي مزودةً بعمود يعرض صلاحيات كل منها بالأسلوب الأبجدي: cd /etc ls -l drwxr-xr-x 3 root root 4096 Apr 26 2012 acpi -rw-r--r-- 1 root root 2981 Apr 26 2012 adduser.conf drwxr-xr-x 2 root root 4096 Jul 5 20:53 alternatives -rw-r--r-- 1 root root 395 Jun 20 2010 anacrontab drwxr-xr-x 3 root root 4096 Apr 26 2012 apm drwxr-xr-x 3 root root 4096 Apr 26 2012 apparmor drwxr-xr-x 5 root root 4096 Jul 5 20:52 apparmor.d drwxr-xr-x 6 root root 4096 Apr 26 2012 apt …وكما نرى فإن العمود الأول من اليسار يعرض أذونات الملفات والمجلدات بالترميز الأبجدي ضمن خانة مؤلفة من عشرة محارف، يحدّد الأوّل منها نوع الملف حيث يعطي الشرطة (-) للملفات، حرف (d) للمجلدات، وحرف (l) للروابط... الخ، بينما تُحدّد المحارف التسعة المتبقية صلاحيات الفئات الثلاث (المالك، المجموعة المالكة، والآخرين) من إمكانية قراءة، كتابة، وتنفيذ. لنقرأ أذونات السطر الأول من الخرج السابق مجددًا، الحرف d يرمز إلى أن acpi هو مجلد وليس ملف، يمنح مالكه الصلاحيات الثلاث (قراءة، كتابة، وتنفيذ)، في حين تمنح كلا من المجموعة المالكة وفئة الآخرين صلاحيتا القراءة والتنفيذ فقط. بينما تحدّد الشرطة (-) من أذونات السطر الرابع أن anacrontab هو ملف وليس مجلد، يمنح لمالكه صلاحيات القراءة والكتابة، أما المجموعة المالكة وفئة الآخرين فتمنح صلاحية القراءة فقط. الترميز العددي (الثماني)يعطي الترميز العددي طريقة أكثر إيجازًا لكن أقل بداهةً في التعامل مع الصلاحيات، وفق هذا الأسلوب تُحدّد صلاحيات كل فئة من الفئات الثلاث (المالك، المجموعة المالكة، والآخرين) برقم ضمن المجال بين 0 و 7. لمعرفة الرقم الصحيح الذي نرغب باختياره نقوم بتحديد الصلاحيات المطلوبة من الجدول التالي، ومن ثم جمع أعدادها: صلاحية القراءة تأخذ الرقم 4.صلاحية الكتابة تأخذ الرقم 2.صلاحية التنفيذ تأخذ الرقم 1.وهكذا يجب علينا جمع هذه الأرقام ثلاث مرات منفصلة (مرة لكل فئة) للحصول على الترميز المطلوب لملف ما، حيث يتم إعطاء الرقم 7 للفئة التي نريد إسناد صلاحيات القراءة والكتابة والتنفيذ لها (4+2+1) بينما تحصل الفئة التي نرغب بمنعها من كافة الصلاحيات على الرقم (0). لنعود مجددًا إلى مجلد acpi السابق كمثال، وباعتبار أن مالكه يجمع الصلاحيات الثلاث معًا فهو يأخذ الرقم 7، بينما تأخذ كل من المجموعة المالكة وفئة الآخرين الرقم (5)، ليكون الترميز الكامل للمجلد على الشكل 755. وكما في الترميز الأبجدي، يمكن للترميز العددي أن يضم بادئة تعبّر عن نوع الملف، وهذا يتبع لصلاحيات المالك، والمجموعة المالكة، وفئة الآخرين على الترتيب. استخدام الأمر chmodيعتبر الأمر chmod الطريقة الأكثر انتشارًا لتعديل صلاحيات ملف ما باستخدام الترميز العددي (الثماني)، لنأخذ مثالًا عمليًا على الفور: سوف ننشئ في مجلد المنزل ملفًا فارغًا باسم testfile لذلك: cd touch testfile ولنستعرض الآن الصلاحيات التي تعطى للملف بشكل افتراضي عند إنشاءه: ls -l testfile -rw-rw-r-- 1 demouser demouser 0 Jul 10 17:23 testfileوكما هو واضح فإن كلًا من مالك الملف والمجموعة المالكة له تملك أذونات القراءة والكتابة، بينما لا تملك فئة الآخرين سوى صلاحية القراءة. عند تحويل الترميز الأبجدي السابق إلى ترميز عددي، سيحصل كل من المالك والمجموعة المالكة على القيمة (6) (4 للقراءة و 2 للكتابة)، بينما تحصل فئة الآخرين على القيمة (4) فقط (للقراءة)، وهكذا يمكن تمثيل صلاحيات الملف testfile وفق الترميز العددي بالقيمة (664). لنفترض مثلًا أن الملف السابق يضم نصّ تنفيذي script، ونريد أن نضيف صلاحيات التنفيذ للمالك فقط، إضافةً لسحب صلاحيات التعديل عن المجموعة المالكة، بينما لا نعطى فئة الآخرين أيّة صلاحيات على الإطلاق. يمكن تمثيل الصلاحيات الجديدة بعد التعديل وفق الترميز الأبجدي كما يلي -rwxr-----، بينما تأخذ القيمة (740) في التمثيل العددي، لنستخدم الأمر chmod للتعديل على أذونات الملف: chmod 740 testfile ls -l testfile -rwxr----- 1 demouser demouser 0 Jul 10 17:23 testfile وهكذا نتأكد أن حسابنا صحيح، وقد أسند للملف صلاحياته الجديدة، وبذات الطريقة يمكن إعادة ضبط الأذونات على ما كانت عليه: chmod 664 testfile ls -l testfile -rw-rw-r-- 1 demouser demouser 0 Jul 10 17:23 testfileضبط الأذونات الافتراضية باستخدام Umaskتتحكّم الأداة umask بالأذونات المبدئية للملفات والمجلدات عند إنشائها بناء على صلاحيات الأساس "base"، حيث تعطى الصلاحية ذات القيمة (666) للملفات فور إنشائها، والتي تشمل أذونات القراءة والكتابة لفئات المستخدمين الثلاث (المالك، المجموعة المالكة، والآخرين)، ولا تشمل الأذونات الافتراضية صلاحية التنفيذ لأيّ من الملفات المنشأة، باعتبار أن معظمها لا يضم نصوصًا تنفيذية، كما أن إعطاء صلاحية التنفيذ بشكل افتراضي يفتح الباب أمام بعض المخاوف الأمنية. أما المجلدات فتعطى الصلاحية ذات القيمة (777) أي القراءة والكتابة والتنفيذ لجميع المستخدمين. يسمى الأسلوب الذي تعمل به الأداة umask بقناع الطرح subtractive mask، فطالما أن صلاحية التنفيذ لا يمكن أن تعطى بشكل افتراضي، فهذا يعني أن umask يعطي افتراضيًا أعلى الأذونات الممكنة، وهكذا فالتعديل الوحيد الممكن على قيمه الافتراضية هو بتقليل تلك الأذونات، وبعبارة أخرى إنشاء طبقة (أو قناع) تطرح بعض الأذونات المبدئية من صلاحيات الأساس. فعلى سبيل المثال، لو رغبنا بطرح صلاحية الكتابة من فئة الآخرين للمجلدات المنشأة (بحيث تبقى للمالك والمجموعة المالكة فقط)، فهذا يعني أن الأذونات الافتراضية يجب أن تصبح برقم (755)، ولإدخال التعديلات باستخدام الأداة umask نطرح الأذونات الأساسية من الأذونات المطلوبة لنحصل على قناع الطرح لحالتنا هذه: 777 - 775 ------ 002الناتج (002) هو القيمة التي سنمررها إلى umask لإدخال التعديلات المرغوبة، وفي الحقيقة يصادف أحيانًا أن تكون هذه هي القيمة الافتراضية لبعض الأنظمة كما مرّ معنا سابقًا عندما أنشأنا ملف جديد باستخدام الأمر touch، لنعيد المثال مرّة أخرى: touch test2 ls -l test2 -rw-rw-r-- 1 demouser demouser 0 Jul 10 18:30 test2 وإذا أردنا تأمين حماية أفضل لنظام تشغيلنا، فيمكن تعديل الأذونات المبدئية للملفات المنشأة بحيث لا تتيح لغير المالك أية صلاحيات على الإطلاق، عبر تمرير قناع الطرح (077) للأداة umask لتصبح صلاحيات الأساس الجديدة (600): umask 077 touch restricted ls -l restricted -rw------- 1 demouser demouser 0 Jul 10 18:33 restricted ولقلب العملية، أي لإعطاء كامل الصلاحيات لكافة فئات المستخدمين للملفات والمجلدات المنشأة فإننا نستخدم قناع الطرح (000): umask 000 touch openfile ls -l openfile -rw-rw-rw- 1 demouser demouser 0 Jul 10 18:36 openfile تُطبّق القيم الجديدة لصلاحيات الأساس عبر umask للجلسة الحاليّة فقط، وهذا يعني أنه عند إعادة التشغيل أو تسجيل الخروج، سيتم إعادة ضبط umask للقيم الافتراضية التي تُحدّدها توزيعتك، أما لجعل تغييراتك دائمة لكافة الجلسات القادمة فيجب تمرير قناع الطرح المطلوب إلى ملف bashrc. الخاص بمستخدمك: cd nano .bashrcتأكد أولًا فيما إذا كان هناك سطر يحدّد قيمة قناع الطرح umask، في هذه الحالة أدخل التعديل على القيمة المسندة له فقط، في غير ذلك أضف السطر التالي إلى نهاية الملف بالقيم التي تريد: umask 022 في مثالنا هذا مررنا كامل الصلاحيات لفئة المالك، بينما سحبنا صلاحيات الكتابة لكل من المجموعة المالكة وفئة الآخرين، بعد تحديد القناع الذي ترغب باختياره قم بحفظ الملف وإعادة تسجيل الدخول. إشعار تحذيريجب لفت الانتباه لنقطة مهمة تتعلق بتعديل الأذونات، حيث أن بعض ملفات النظام، وبعض الخدمات أو العمليات تتطلب صلاحيات معينة لتعمل بشكل صحيح، وإلا فستؤدي الصلاحيات غير الملائمة لأخطاء في التشغيل. إضافةً إلى أن توزيع الصلاحيات بشكل متساهل (مثل تمرير أذونات التنفيذ لفئة الآخرين بشكل تلقائي) قد تعرّضك لمشاكل أمنية. لهذه الأسباب (وغيرها) لا يُنصح بتعديل أذونات الملفات أو المجلدات خارج نطاق دليل المنزل الخاص بك، إلا إذا كنتَ على درايةً دقيقة بما تقوم به. أمرٌ آخر أودّ الإشارة إليه هنا، لأولئك الذين يقومون بضبط البرامج بشكل يدوي، وهي أهمية محاولة تمرير أقل صلاحيات ممكنة للبرنامج مع مراعاة ألّا يؤثر ذلك بالطبع على وظائفه. وفيما إذا كنتَ المستخدم الوحيد لجهازك (مدير خادوم مثلًا) فأنت تحتاج إلى صلاحيات مطلقة على الملفات، لكن إسناد أية صلاحيات لفئة الآخرين (كالكتابة أو حتى القراءة) لا داعي له سوى جلب المخاطر الأمنية، لا سيما في حال كانت كلمة المرور خاصتك مخزنة في ملف نصيّ غير مشفّر plain-text. وبالاستفادة من فئة (المجموعة المالكة) وإسناد الأذونات المناسبة لها، ومن ثم إضافة الأشخاص اللازمين من فريق العمل إليها، يمكن تحقيق أفضل منفعة ممكنة من إدارة الصلاحيات في لينكس، إضافةً إلى إلغاء صلاحيات "الآخرين" فيما لو لم يكن هناك حاجةٌ إليها، مما يحقق مستوىً عالٍ من الأمان. * الأذونات أو Permissions: هي مجموعة من القواعد تحدّد أولئك الذين يحق لهم أو لا يحق لهم امتلاك إمكانية القراءة، الكتابة، أو التعديل، على الملفات والمجلدات، وقد استخدمنا لها عدّة ترجمات في هذا الدليل؛ الأذونات، الصلاحيات، التصاريح. ترجمة -وبتصرّف- للمقال Linux Permissions Basics and How to Use Umask on a VPS.

هناك العديد من لغات قواعد البيانات SQL التي تعمل على أنظمة اللينكس واليونكس، ومن أشهر لغات قواعد البيانات العلائقية التي تعمل في بيئات الخوادم هما MySQL وMariaDB. ومع ذلك، مثل أغلب البرامج، هذه الأدوات يمكن أن تكون الاحتياجات الأمنية إذا تم تكوينها بشكل غير صحيح، هذا الشرح التعليمي سوف يرشدك لبعض الخطوات الأساسية التي يمكن اتخاذها لتأمين قاعدة البيانات الخاصة بك سواء MariaDB أو MySQL، والتأكد من أنها ليست بابًا مفتوحًا إلى VPS الخاص بك. من أجل البساطة والوضوح، سوف نستخدم MySQL على خادوم Ubuntu كمثال، ومع أن هذه التقنيات يمكن تطبيقها على توزيعات لينكس الأخرى، ويمكن استخدامها مع MariaDB كذلك. الإعداد الأوليMySQL يمنحك فرصة لاتخاذ الخطوة الأولى نحو تحقيق الأمن أثناء التثبيت، وسوف نطلب منكم وضع كلمة سر root (الجذر). $ sudo apt-get install mysql-server Configuring mysql-server-5.5 While not mandatory, it is highly recommended that you set a password for the MySQL administrative "root" user. If this field is left blank, the password will not be changed. New password for the MySQL "root" user:يمكنك دائما تعيين كلمة سر root في وقت لاحق، ولكن ليس هناك سبب لتخطي هذه الخطوة، لذلك يجب تأمين حساب المسؤول الخاص بك من البداية. بمجرد اكتمال التثبيت، يجب علينا تشغيل عدد قليل من النصوص المدرجة. أولاً، سوف نستخدم "mysql_install_db" وهو سكريبت نصي لإنشاء تصميم قواعد البيانات الخاصة بنا. $ sudo mysql_install_dbبعد ذلك، قم بتشغيل السكريبت الذي يسمى "mysql_secure_installation"، وسيرشدنا لبعض الإجراءات التي من شأنها إزالة بعض الافتراضات التي تشكل خطرا على استخدامها في بيئة الإنتاج. $ sudo mysql_secure_installationأولاً سوف يطلب منك إدخال كلمة السر الجذر وستقوم بإدخالها أثناء التثبيت، وبعد ذلك مباشرة ، سوف يطلب منك سلسلة من الأسئلة، بدءا من إذا كنت ترغب في تغيير كلمة سر الجذر. هذه هي فرصة أخرى لتغيير كلمة المرور الخاصة بك إلى أي شيء آمن إذا لم تكن قد فعلت ذلك بالفعل. يجب أن تكون الإجابة "Y" (نعم) لجميع الأسئلة المتبقية. سيؤدي ذلك إلى إزالة قدرة أي شخص لتسجيل الدخول إلى MySQL افتراضيا، وتعطيل تسجيل الدخول عن بعد على حساب المسؤول، وإزالة بعض قواعد بيانات الاختبار غير الآمنة، وتحديث قاعدة البيانات التي تعمل حاليا لاعتماد هذه التغيرات. اعتبارات أمنيةالقاعدة البسيطة لزيادة حماية MySQL (ومعظم الأنظمة الأخرى) هو إعطاء صلاحيات النفاذ فقط عند الضرورة. أحيانا لكي تكون بياناتك آمنة يجب أن توزان بين الراحة والأمان. في هذا الدليل، سوف نميل إلى الجانب الأمني، لذا فإن استخدامك الخاص لقاعدة البيانات يمكن أن يدفعك لإنتقاء أحد هذه الخيارات. زيادة الأمن من خلال ملف My.cnfملف الإعدادت الرئيسية في MySQL هو ملف يسمى "my.cnf" الموجود في "/etc/mysql/" هذا الامتداد على أوبونتو وامتداد "/etc/" على بعض الخواديم الأخرى. سوف نقوم بتغيير بعض الإعدادات في هذا الملف لتأمين MySQL الخاصة بنا. فتح الملف مع صلاحيات الجذر، تغيير مسار الامتداد حسب الحاجة إذا كنت تتبع هذا الشرح التعليمي على نظام مختلف: $ sudo nano /etc/mysql/my.cnfالإعداد الأولي التي يجب علينا أن نتحقق منه "وضع عنوان IP" ضمن قسم "[mysqld]". ويجب تعيين هذا الإعداد على جهاز الشبكة المحلي loopback ، وهو "127.0.0.1". $ bind-address = 127.0.0.1هذا يجعل من أن MySQL لا تقبل الاتصالات من أي مكان باستثناء الجهاز المحلي. إذا كنت بحاجة للوصول إلى قاعدة البيانات من جهاز آخر، خذ بالاعتبار الاتصال عن طريق SSH للقيام بالاستعلام وادارة قاعدة البيانات الخاصة بك محليا وإرسال النتائج من خلال قناة SSH. الفجوة التالية التي سوف نعدلها، هي وظيفة تتيح لك الوصول إلى نظام الملفات من داخل MySQL، يمكن أن يكون لها تداعيات أمنية خطيرة ويجب ايقافها إلا إذا كنت في حاجة شديدة لها. في نفس المقطع من الملف، سوف نقوم بإضافة التوجيه لتعطيل هذه القدرة على تحميل الملفات المحلية: local-infile=0إذا كان لدينا مساحة كافية ولا تعمل على قاعدة بيانات ضخمة، فإنه يمكن أن يكون مفيدا لتسجيل معلومات إضافية لمراقبة أي نشاط مثير للشبهة. تسجيل معلومات أكثر من اللازم يضعف الأداء، لذلك قم بوزن أي شيء تحتاجه بعناية. يمكنك وضع تسجيل الأحداث المتغيرة داخل القسم نفسه "[mysqld]" التي قمنا بالإضافة فيها: log=/var/log/mysql-logfileتأكد من أن سجل MySQL يعمل، سجل الأخطاء، وسجل MySQL ليس سهل القراءة: $ sudo ls -l /var/log/mysql* -rw-r----- 1 mysql adm 0 Jul 23 18:06 /var/log/mysql.err -rw-r----- 1 mysql adm 0 Jul 23 18:06 /var/log/mysql.log /var/log/mysql: total 28 -rw-rw---- 1 mysql adm 20694 Jul 23 19:17 error.logتأمين MySQL من الداخلهناك عدد من الخطوات التي يمكنك اتخاذها أثناء استخدام MySQL لتحسين الوضع الأمني. سوف نقوم بإدخال الأوامر في هذا القسم في بداخل واجهة MySQL ، لذلك نحن بحاجة إلى تسجيل الدخول. $ mysql -u root -pسيطلب منك إدخال كلمة سر الجذر التي قمت بإعدادها في وقت سابق. تأمين كلمات السر والمستخدمين المرتبطينأولاً، تأكد من وجود مستخدمين بدون كلمة مرور أو المضيف المرتبط في MySQL: SELECT User,Host,Password FROM mysql.user; +------------------+-----------+-------------------------------------------+ | user | host | password | +------------------+-----------+-------------------------------------------+ | root | localhost | *DE06E242B88EFB1FE4B5083587C260BACB2A6158 | | demo-user | % | | | root | 127.0.0.1 | *DE06E242B88EFB1FE4B5083587C260BACB2A6158 | | root | ::1 | *DE06E242B88EFB1FE4B5083587C260BACB2A6158 | | debian-sys-maint | localhost | *ECE81E38F064E50419F3074004A8352B6A683390 | +------------------+-----------+-------------------------------------------+ 5 rows in set (0.00 sec)كما ترون في مثالنا هذا "المستخدم التجريبي " ليس لديه كلمة مرور، وهو ساري المفعول بغض النظر عن ما هو عليه في المضيف، ويعتبر هذا آمن جدا. يمكننا وضع كلمة سر للمستخدم مع هذا الأمر Change "كلمة المرور الجديدة" أدخل كلمة المرور التي ترغب بها. UPDATE mysql.user SET Password=PASSWORD('newPassWord') WHERE User=""demo-user";إذاً علينا التحقق من جدول المستخدم مرة أخرى، وسوف نرى أن المستخدم التجريبي لديه الآن كلمة سر: SELECT User,Host,Password FROM mysql.user;+------------------+-----------+-------------------------------------------+ | user | host | password | +------------------+-----------+-------------------------------------------+ | root | localhost | *DE06E242B88EFB1FE4B5083587C260BACB2A6158 | | demo-user | % | *D8DECEC305209EEFEC43008E1D420E1AA06B19E0 | | root | 127.0.0.1 | *DE06E242B88EFB1FE4B5083587C260BACB2A6158 | | root | ::1 | *DE06E242B88EFB1FE4B5083587C260BACB2A6158 | | debian-sys-maint | localhost | *ECE81E38F064E50419F3074004A8352B6A683390 | +------------------+-----------+-------------------------------------------+ 5 rows in set (0.00 sec)إذا ما نظرت هذا الحقل"host"، سترى أن لا يزال لدينا "٪"، هي عبارة عن بطاقة بديلة وهذا يعني أي مضيف. وليس هذا ما نريده، دعونا نغيرها إلى " localhost". UPDATE mysql.user SET Host='localhost' WHERE User="demo-user";إذا تحققنا مرة أخرى، يمكننا أن نرى أن جدول المستخدم لديه الآن الحقول المناسبة. SELECT User,Host,Password FROM mysql.user;إذا كان لدينا جدول يحتوي على مستخدمين فارغين (لا يجب في هذه المرحلة أن يكونوا "mysql_secure_installation", سنغطي هذه الناحية بأي حال من الأحوال لاحقا)، وينبغي علينا إزالتهم. للقيام بذلك، يمكننا استخدام الأمور التالي لحذف المستخدمين الفارغين من جدول الوصول: DELETE FROM mysql.user WHERE User="";بعد أن يتم تعديل جدول المستخدم، نحن بحاجة إلى إدخال الأمر التالي لتنفيذ صلاحيات جديدة: FLUSH PRIVILEGES;إنشاء مستخدمين محددين لتطبيقات معينة طريقة تشغيل العمليات داخل لينكس تكون معزولة لكل مستخدم على حدى، وتستخدم قاعدة بيانات MySQL نفس طريقة العزل. كل تطبيق يستخدم MySQL يجب أن يمتلك مستخدم خاص به ولديه صلاحيات محدودة ويستطيع الوصول إلى قواعد البيانات التي يحتاج لتشغيلها فقط. عندما نقوم بإعداد تطبيق جديد لاستخدام MySQL، يجب أن ننشئ قواعد البيانات التي يحتاجها هذا التطبيق: create database testDB; Query OK, 1 row affected (0.00 sec)بعد ذلك، يجب علينا إنشاء مستخدم لإدارة قاعدة البيانات، ومنحه الصلاحيات التي يحتاجها فقط، وهذه تختلف من تطبيق لآخر، وبعض الاستخدامات تحتاج لصلاحيات مفتوحة أكثر من غيرها. لإنشاء مستخدم جديد، استخدم الأمر التالي: CREATE USER 'demo-user'@'localhost' IDENTIFIED BY 'password';يمكننا منح المستخدم الجديد صلاحيات على الجدول الجديد بالأمر التالي. انظر الشرح التعليمي حول كيفية إنشاء مستخدم ومنح صلاحيات جديدة في MySQL لمعرفة المزيد عن الصلاحيات المحددة: GRANT SELECT,UPDATE,DELETE ON testDB.* TO 'demo-user'@'localhost';وكمثال على ذلك، إذا كنا بحاجة إلى وقت لاحق لإلغاء الصلاحيات من الحساب، يمكن أن نستخدم الأمر التالي: REVOKE UPDATE ON testDB.* FROM 'demo-user'@'localhost';إذا كنا بحاجة إلى كافة الصلاحيات على قاعدة بيانات معينة، يمكننا تحديد ذلك بما يلي: GRANT ALL ON testDB.* TO 'demo-user'@'localhost';لإظهار الصلاحيات الحالية للمستخدم، علينا أولا أن ننفذ الصلاحيات حددناه باستخدام أمر "flush privileges"، ثم بعد ذلك يمكننا الاستعلام عن الصلاحيات التي بحوزة المستخدم. FLUSH PRIVILEGES; show grants for 'demo-user'@'localhost'; Grants for demo-user@localhost GRANT USAGE ON *.* TO 'demo-user'@'localhost' IDENTIFIED BY PASSWORD '*2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19' GRANT SELECT, UPDATE, DELETE ON `testDB`.* TO 'demo-user'@'localhost' 2 rows in set (0.00 sec)دائما امسح الصلاحيات عندما تنتهي من إجراء التغييرات. تغيير المستخدم الجذرخطوة إضافية واحدة وهي، ربما تريد تغيير اسم الجذر(root login name )، فإذا كان الهاكر يحاول أن يقوم بتسجيل الدخول باسم الروت في MySQL ، فسوف يحتاج إلى تنفيذ خطوة إضافية هي العثور على اسم المستخدم. تستطيع تغيير اسم المستخدم روت باستخدام الأمر التالي: rename user 'root'@'localhost' to 'newAdminUser'@'localhost';يمكننا أن نرى التغيير باستخدام نفس الاستعلام الذي استخدمناه لقاعدة بيانات المستخدم: select user,host,password from mysql.user;مرة أخرى، يجب علينا مسح الصلاحيات التغيرات التي حدثت: FLUSH PRIVILEGES;تذكر أنه سوف تسجل دخول إلى MySQL مثل اسم مستخدم تم إنشاؤه حديثا عندما ترغب في أداء المهام الإدارية: mysql -u newAdminUser -pبأي حال من الأحوال هذه قائمة شاملة من الاجراءات الأمنية لقواعد البيانات MySQL, MariaDB، وقد أصبح لديك مقدمة جيدة لأنواع القرارات التي ستتخذها عندما تريد تأمين قواعد البيانات الخاصة بك. يمكن الاطلاع على مزيد من المعلومات حول الإعدادت والأمن في قواعد بيانات المواقع MySQL وMariaDB إضافة الى صفحات المختصين، ويمكن للتطبيقات التي اخترت استخدامها أن تقدم المشورة الأمنية. ترجمة -وبتصرّف- للمقال: How To Secure MySQL and MariaDB Databases in a Linux VPS.