البحث في الموقع
المحتوى عن 'sudo'.
-
تعتقد أنّك تعرف كل شيء عن sudo؟ فكّر بذلك مجدّدًا. يعرف الجميع sudo أليس كذلك؟ تُثبَّت هذه الأداة بشكل افتراضي على معظم أنظمة Linux وهي متوفّرة لمعظم توزيعات BSD (اختصارًا إلى Berkeley Software Distributions) ومختلف توزيعات يونكس التجاريّة. ومع ذلك كانت الإجابة الأكثر شيوعًا التي تلقيتها بعد التحدث إلى مئات مستخدمي sudo هي أنّ sudo أداة لتعقيد الحياة. يوجد لديك مستخدم جذر root ولديك أمر su، فلماذا يكون لديك أداة أخرى؟ كان sudo بالنسبة للكثيرين مجرّد بادئة للأوامر الإداريّة. ذكرت قلّة قليلة فقط أنّه يمكنك استخدام سجلات sudo لمعرفة من قام بعملٍ ما عندما يكون لديك العديد من المسؤولين في نفس النظام. ما هو sudo؟ وفقًا لموقع sudo الإلكتروني: يأتي sudo افتراضيًّا بضبط بسيط، حيث أن قاعدة واحدة تسمح للمستخدم أو لمجموعة من المستخدمين بالقيام بأي شيء عمليًا (المزيد حول ملف الضبط لاحقًا ضمن هذه المقالة): %wheel ALL=(ALL) ALL تعني «المعاملات» (parameters) في هذا المثال ما يلي: يحدّد المعامل الأول أعضاء المجموعة. يحدّد المعامل الثاني المُضيف (المضيفين) الذي يمكن لأعضاء المجموعة تشغيل الأوامر عليه. يحدّد المعامل الثالث أسماء المستخدمين التي يمكن بموجبها تنفيذ الأمر. يحدّد المعامل الأخير التطبيقات التي يمكن تشغيلها. لذلك يمكن لأعضاء مجموعة Wheel في هذا المثال تشغيل جميع التطبيقات مثل كافة المستخدمين على جميع المضيفين. حتى هذه القاعدة المتسامحة حقًا مفيدة لأنها تؤدي إلى تسجيل من قام بعملٍ ما على جهازك. الأسماء المستعارة (Aliases) بالطبع بمجرّد كونك لا تقوم أنت وصديقك المفضّل فقط بإدارة صندوق مشترك ما، فسوف تبدأ التفكير في ضبط الأذونات. يمكنك استبدال العناصر الموجودة في الضبط أعلاه بقوائم: قائمة المستخدمين، قائمة الأوامر، وما إلى ذلك. ستَنسخ على الأرجح وتلصق بعض هذه القوائم في الضبط الخاص بك. في مثل هذه الحالة حيث يكون استخدام الأسماء المستعارة في متناول اليد. يكون الحفاظ على نفس القائمة في أماكن متعدّدة عُرضة للخطأ. بالإمكان تعريف اسم مستعار مرّة واحدة وبعد ذلك يمكنك استخدامه مرّات عديدة. لذلك عندما تفقد الثقة في أحد أو بعض المسؤولين لديك، يمكنك إزالتَهم من خلال الاسم المستعار وينتهي الأمر. ولكن مع وجود قوائم متعددة بدلاً من الأسماء المستعارة فإنّه من السهل أن تنسى إزالة مستخدم ما من إحدى القوائم ذات الامتيازات العالية. تمكين الميزات لمجموعة معيّنة من المستخدمين يأتي الأمر sudo مزودًا بمجموعة كبيرة من الإعدادات الافتراضيّة. لا يزال هناك حالات تريد فيها تغيير بعضٍ من هذه الإعدادات. وذلك عند استخدام التعليمة Defaults في الضبط. عادةً ما يتم فرض هذه الإعدادات الافتراضيّة على كل مستخدم، ولكن يمكنك تضييق مجال هذه الإعدادات لتُطبّق فقط على مجموعة فرعيّة من المستخدمين بناءً على المضيف واسم المستخدم وما إلى ذلك. هنا مثال على أن مسؤول النظام الخاص بي (sysadmins) يُحبّ استخدام "التوبيخ" insults. وهي مجرّد بضع رسائل هزليّة تظهر كَتوبيخ عندما يُخطئ المستخدم في كلمة السرّ عند تنفيذ أوامر في sudo: czanik@linux-mewy:~> sudo ls [sudo] password for root: Hold it up to the light --- not a brain in sight! [sudo] password for root: My pet ferret can type better than you! [sudo] password for root: sudo: 3 incorrect password attempts czanik@linux-mewy:~> وبما أنه ليس الجميع معجب بفكاهة مدير النظام، تُعطّل هذه التوبيخات افتراضيًا. يوضّح المثال التالي كيفية تمكين هذا الإعداد فقط لمسؤولي النظام المتمرسين وهم أعضاء في المجموعة wheel: Defaults !insults Defaults:%wheel insults ليس لدي ما يكفي من الأصابع لتعداد الأشخاص الذين شكروني على إعداد هذه الرسائل. مُصادقة القيم المختصرة المشفرة (Digest verification) بالطبع هناك ميزات أكثر أهميّةً في sudo كذلك. إحدى الميزات هي «مُصادقة القيم المختصرة المشفرة» (digest verification). يمكنك تضمين مصادقة القيم المختصرة المشفرة للتطبيقات في الضبط الخاص بك: peter ALL = sha244:11925141bb22866afdf257ce7790bd6275feda80b3b241c108b79c88 /usr/bin/passwd يقوم sudo في هذه الحالة بفحص وموازنة القيمة المتخصرة المشفرة لتطبيق مع القيمة المشفرة المختصرة لتطبيق المخزّن في الضبط قبل تشغيله. فإذا لم يكونا متطابقين عندها يرفض sudo تشغيل التطبيق. على الرغم من صعوبة الحفاظ على هذه المعلومات في الضبط الخاص بك – حيث لا توجد أدوات تلقائية لهذا الغرض - إلا أنّ هذه الملخّصات يمكن أن توفر لك طبقة إضافيّة من الحماية. تسجيل الجلسة تسجيل الجلسة هو أيضًا ميزة أقل شهرةً لـ sudo. بعد عرضي التوضيحي يغادر كثير من الأشخاص محادثتي مع خطط عازمين على تنفيذها على بنيتهم التحتيّة. لماذا؟ لأن تسجيل الجلسة لا يتيح لك رؤية اسم الأمر فقط، بل كل ما يحدث في الجهاز الطرفي أيضًا. فبإمكانك معرفة ما يفعله المسؤولون لديك حتى لو كان لديهم وصول إلى الصدفة (shell) والسجلات تُظهر فقط أن bash بدأ العمل. توجد محدوديّة واحدة حاليًّا وهي أن السجلات تخزّن محليًّا، لذلك يمكن للمستخدمين حذف سجلات التتبع الخاصّة بهم إذا توفرت لهم أذونات كافية. ترقبوا الميزات القادمة. الإضافات تم تغيير sudo إلى بنية معياريّة قائمة على «الإضافات» (plugins) بدءًا من الإصدار 1.8. حيث أصبح بالإمكان استبدال أو توسيع وظائف sudo بسهولة عن طريق كتابة وظائفك الخاصّة، وذلك اعتمادًا على معظم الميزات التي نُفّذت كإضافات. يتوفر حاليًا كلًّا من الإضافات مفتوحة المصدر والإضافات التجاريّة لـ sudo. عَرضتُ في حديثي الإضافة sudo_pair والتي تتوفر على GitHub. طوّرت هذه الإضافة في Rust مما يعني أنه ليس من السهل «ترجمتها» (compile) والأكثر صعوبةً من ذلك هو نشر النتائج. تُوفّر الإضافات من ناحيةٍ أخرى وظائف مثيرة للاهتمام، مُتطلبةً من مسؤولٍ ثانٍ الموافقة (أو الرفض) لتشغيل الأوامر من خلال sudo. ليس ذلك فحسب، بل يمكن أيضًا تتبع الجلسات على الشاشة وإنهاؤها في حال وجود نشاط مشبوه. في عرضٍ توضيحيّ قدمته خلال حديثي مؤخرًا في مؤتمر "All Things Open" شعرت كمن يجلب لنفسه السمعة السيئة. czanik@linux-mewy:~> sudo rm -fr / كان الجميع يحبس أنفاسهم لمعرفة ما إذا كان جهاز الحاسوب المحمول قد دُمّر عند رؤية الأمر المعروض على الشاشة، لكنه نجا. السجلات يُعدّ التسجيل والتنبيه جزءًا مهمًا من sudo كما ذكرت سابقًا في البداية. إذا لم تقم بفحص سجلات sudo الخاصّة بك بانتظام فليس هناك قيمة كبيرة لاستخدام sudo. تُنبّه هذه الأداة عن طريق البريد الإلكتروني عن الأحداث المحدّدة في الضبط وتُسجل جميع الأحداث في syslog. يمكن تشغيل سجلات التنقيح (Debug) واستخدامها لتصحيح القواعد أو الإبلاغ عن «الأخطاء» (bugs). التنبيهات Alerts تعد تنبيهات البريد الإلكتروني من النمط القديم الآن، ولكن إذا كنت تستخدم syslog-ng لتَجميع رسائل السجل الخاصّة بك، فستُنقّح رسائل سجل sudo تلقائيًا. يمكنك بسهولة إنشاء تنبيهات مخصّصة وإرسالها إلى مجموعة واسعة من الوجهات، بما في ذلك Slack أو Telegram أو Splunk أو Elasticsearch. الضبط تحدثنا كثيرًا عن ميزات sudo وحتى شاهدنا بضعة أسطر من «الضبط» (Configuration). دعنا الآن نلقي نظرة أقرب على كيفيّة ضبط sudo. الضبط نفسه متاح في /etc/sudoers وهو ملف نصيّ بسيط. ومع ذلك ما يزال لا يُنصح بتحرير هذا الملف مباشرة، استخدم بدلاً من ذلك visudo حيث تتحقق هذه الأداة من بناء الجملة النحويّ أيضًا. بإمكانك إذا كنت لا تحب vi تغيير المحرّر المُستخدَم عن طريق ضبط متغير البيئةEDITOR إلى الخيار المفضل لديك. تأكّد قبل البدء في تحرير ضبط sudo من معرفة كلمة مرور المستخدم root. (نعم، حتى على Ubuntu حيث الـ root ليس لديه كلمة مرور افتراضيًّا.) بما أنّ visudo يتحقّق من البناء النحويّ للجملة فمن السهل إنشاء ضبط صحيح نحويًّا يمنعك من الولوج إلى نظامك. يمكنك عندما تتوفر لديك كلمة مرور جذر في حالة الطوارئ البدء في تحرير الضبط الخاص بك. هناك شيء واحد مهم يجب تذكره عندما يتعلق الأمر بملف sudoers وهو أنّه: يُقرأ هذا الملف من الأعلى إلى الأسفل وبالتالي يُنفّذ الإعداد الأخير. ما تعنيه هذه الحقيقة بالنسبة لك هو أنّه يجب أن تبدأ بالإعدادات العامّة وتضع الاستثناءات في النهاية، وإلا فإنّ الإعدادات العامة ستُلغي الاستثناءات. يمكنك العثور على ملف sudoers بسيط أدناه اعتمادًا على ذلك الموجود في CentOS وإضافة بضعة أسطر كنا قد ناقشناها سابقًا: Defaults !visiblepw Defaults always_set_home Defaults match_group_by_gid Defaults always_query_group_plugin 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 secure_path = /sbin:/bin:/usr/sbin:/usr/bin root ALL=(ALL) ALL %wheel ALL=(ALL) ALL Defaults:%wheel insults Defaults !insults Defaults log_output يبدأ هذا الملف عن طريق تغيير عدد من الإعدادات الافتراضيّة. ثم تأتي القواعد الافتراضيّة المعتادة: المستخدم root وأعضاء مجموعة wheel لديهم أذونات كاملة على الجهاز. نُمكّن بعد ذلك insults لمجموعة wheel ونعطّلها للجميع. يفعّل السطر الأخير تسجيل الجلسة. الضبط أعلاه صحيح نحويًّا، لكن هل يمكنك اكتشاف الخطأ المنطقي؟ نعم، هناك خطأ: تُعطّل insults للجميع عند آخر إعداد عام حيث يُلغي الإعداد السابق الإعداد الأكثر تحديدًا. وبمجرّد تبديل السطرين يعمل الإعداد كما هو متوقع: يتلقى أعضاء مجموعة wheel رسائل هزليّة في حين أنً باقي المستخدمين لن يتلقونها. إدارة الضبط بمجرد أن تضطر إلى الاحتفاظ بملف sudoers على أجهزة متعدّدة فمن المرجح أنك تريد إدارة الضبط الخاص بك مركزيًا. لدينا هنا احتمالان رئيسيان مَفتوحا المصدر. لكلٍ منهما مزايا وعيوب. يمكنك استخدام أحد تطبيقات إدارة الضبط التي تستخدمها أيضًا لضبط بقية البنية التحتيّة الخاصّة بك. تحتوي Red Hat Ansible و Puppet و Chef على وحدات لضبط sudo. المشكلة في هذا النهج هي أنّ تحديث الضبط بعيد عن الوقت الحقيقي. كما أنه لا يزال بإمكان المستخدمين تحرير ملف sudoers محليًا وتغيير الإعدادات. يمكن للأداة sudo أيضًا تخزين ضبطها في خادم LDAP. تكون تغييرات الضبط في هذه الحالة في الوقت الحقيقي ولا يمكن للمستخدمين العبث بملف sudoers. ولكن من ناحية أخرى لهذه الطريقة محدوديّة أيضًا. حيث لا يمكنك على سبيل المثال استخدام الأسماء المستعارة aliases أو استخدام sudo عندما يكون خادم LDAP غير متوفر. ميزات جديدة هناك نسخة جديدة من sudo قاب قوسين أو أدنى. سيتضمن الإصدار 1.9 العديد من الميزات الجديدة المثيرة للاهتمام. فيما يلي أهم الميزات المُخطط لها: خدمة تسجيل لجمع تسجيلات الجلسة مركزيًا والتي توفر العديد من المزايا مقارنة بالتخزين المحلي: أكثر ملاءمة للبحث حيث يتم ذلك في مكان واحد. تتوفر التسجيلات حتى ولو كان جهاز المرسل متوقفا. لا يمكن حذف التسجيلات بواسطة شخص يريد حذف سجلات التتبع الخاصّة به. لا تضيف الإضافة "Audit" ميزات جديدة إلى sudoers، ولكنها توفّر واجهة برمجة تطبيقات API للإضافات للوصول بسهولة إلى أي نوع من سجلات sudo. تمكّن هذه الإضافة إنشاء سجلات مخصّصة من أحداث sudo باستخدام الإضافات. تُمكّن إضافة approval موافقات الجلسة دون استخدام إضافات خارجية (third-party plugins). والميزة المفضّلة لدي شخصيًا: دعم Python للمكونات الإضافيّة والتي تمكّنك من توسيع sudo بسهولة باستخدام شيفرة Python بدلاً من كتابة شيفرة أصليّة في C. الخلاصة آمل أن يكون هذا المقال قد أثبت لك أن sudo أكثر بكثير من مجرّد بادئة بسيطة. هناك الكثير من الاحتمالات لضبط الأذونات على نظامك. فأنت هنا لا تتمكن من ضبط الأذونات فحسب بل تتمكن أيضًا من تحسين الأمان عن طريق التحقق من عمليات مصادقة digests. تُمكّنك تسجيلات الجلسة من التحقّق مما يحدث على أنظمَتك. بإمكانك أيضًا توسيع وظيفة sudo باستخدام الإضافات، إما باستخدام شيء متاح مُسبقًا أو كتابة ما تريد بشكل خاص. أخيرًا وبالنظر إلى قائمة الميزات القادمة يمكنك أن ترى أنه حتى لو كان عمر sudo عقودًا إلاّ أنّه مشروع حيّ يتطور باستمرار. إذا كنت ترغب بمعرفة المزيد عن sudo فإليك بعض الموارد: موقع sudo الإلكتروني مدونة sudo ترجمة وبتصرف للمقال What you probably didn’t know about sudo لصاحبه Peter Czanik
-
- 1
-
- sudo
- مدير النظام
-
(و 3 أكثر)
موسوم في:
-
يُمثِّل الفصل بين الامتيّازات Privileges أحد المبادئ الأمنيّة الأساسيّة المُدرجَة في Linux والأنظمة الشّبيهة بيونكس Unix-like. تجسيدًا لهذا المبدأ يعمل المسخدمون العاديّون بامتيّازات محدودة لحدّ دائرة تأثيرهم على بيئتهم الخاصّة وليس على كامل نظام التّشغيل. يوجد مستخدم خاصّ يُسمّى المستخدم الجذر root user ويملك امتيّازات “المستخدم الأعلى”. حساب المستخدم الجذر هو حساب إداريّ لا توجد عليه القيود الموجودة على المستخدمين العاديّين. يُمكن للمستخدمين العاديّين تنفيذ أوامر بامتيّازات المستخدم الأعلى (المستخدم الجذر) بطرق مختلفة. سنناقش في هذا الدّليل الطّريقة الصّحيحة والآمنة للحصول على امتيّازات المستخدم الجذر، مع التّركيز على ملفّ etc/sudoers/. سنطبّق الخطوات المشروحة هنا على خادوم Ubuntu 14.04؛ يجب أن تكون هذه الخطوات صالحة لأغلب توزيعات لينوكس الحديثة. نفترض في هذا الدّرس، أنّك أكملت خطوات درس الإعداد الابتدائي لخادوم أوبنتو.سجِّل الدّخول إلى خادوم أوبنتو بحساب مستخدم عادي (غير المستخدم الجذر). كيف يمكن الحصول على امتيّازات المستخدم الجذرتوجد ثلاث طرق للحصول على امتيّازات المستخدم الجذر، تختلف في مستوى صعوبتها. 1- تسجيل الدّخول بحساب المستخدم الجذرأسهل طريقة وأكثرها مباشرة للحصول على امتيّازات root هيّ تسجيل الدّخول بدْءًا بحساب المستخدم الجذر. يكون تسجيل الدّخول عن بعد عبر SSH على النّحو التّالي: ssh root@your_IP_address_or_domainحيث your_IP_address_or_domain يمثّل عنوان IP العموميّ للخادوم أو نطاق الموقع. سيُطلب منك إدخال كلمة السّر قبل الولوج. 2- الانتقال إلى حساب المستخدم الجذر عن طريق “su”لا يُنصَح بتسجيل الدّخول إلى الخادوم بحساب المستخدم الجذر؛ إذ قد يؤدّي ذلك إلى استخدام مُدير النّظام (root) في مهامّ غير إداريّة، وهو أمر خطير أمنيًّا. الطّريقة الثّانيّة تسمح بالحصول على امتيّازات المستخدم الجذر في أيّ وقت، حال الحاجة إليها. يؤدّي أمر su، وهو اختصار لsubstitute user (أي “غيّر المستخدم”)، هذه المهمّة: suسيُطلب منك إدخال كلمة سرّ حساب المستخدم الجذر، ثمّ تنتقل بعدها إلى جلسة Shell خاصّة بالمستخدم الأعلى. للخروج من جلسة المستخدم الجذر، بعد الانتهاء من أداء المهامّ الّتي تتطلّب امتيّازات إداريّة، نفّذ الأمر التّالي: exit3- استخدام “Sudo” لتنفيذ الأوامر بحساب المستخدم الجذرالطّريقة الأخيرة، والأكثر تعقيدًا للحصول على امتيّازات root هيّ استخدام أمر sudo. يسمح أمر sudo بتنفيذ أمر واحد بامتيّازات root، دون الحاجة لإنشاء جلسة Shell جديدة. تُنفَّذ الأوامر على النّحو التّالي (تُمثِّل command_to_execute الأمر المُراد تنفيذه بامتيّازات المستخدم الجذر): sudo command_to_executeعلى عكس su، يطلب أمر sudo كلمة سرّ المستخدِم الّذي يُنفّذ الأمر وليس كلمة سرّ حساب المستخدِم الجذر. لا يعمل أمر sudo افتراضيًّا، نظرًا لتداعيّاته الأمنيّة، ويجب أن يُضبَط قبل أن يؤدّي وظائفه. إذا كنت تابعت خطوات درس الإعداد الابتدائي لخادوم أوبنتو فقد أكملت الإعدادات الأساسيّة لضبط مستخدم بامتيّازات الجذر. سنناقش في الفقرة التّاليّة كيفيّة ضبط الإعداد بتفصيل أكثر. ماهو Visudo؟يُضبَط أمر sudo عبر ملفّ يُتَوَّصل إليه عبر المسار etc/sudoers/. ملحوظة: لاتحرّر أبدًا هذا الملفّ بمحرّر نصوص عاديّ. استخدِم دائمًا أمر visudo لهذا الغرض. من المهمّ جدًّا استخدام أمر sudo لتحرير ملفّ sudoers، إذ يمكن أن يؤدّي استعمال صيغة خاطئة في هذا الملفّ إلى جعل نظام التشغيل في وضع لا يصحّ معه الحصول على امتيّازات إداريّة. يعرض أمر visudo محرّر نصوص شبيهًا بالمحرّرات العاديّة، ولكنّه يُضيف آليّة للتحقّق من صيغة التّعليمات الموجودة في الملفّ؛ تعمل عند محاولة الحفظ. تحول هذه الآليّة دون وجود أخطاء تمنع عمليّات sudo. ملحوظة: استخدِم الزرّيْن CTRL وO معًا لحفظ الملفّ ثمّ Enter للتّأكيد. للخروج اضغط زرّيْ CTRL وX. تاريخيًَا، كان أمر visudo يفتح ملفّ etc/sudoers/ في محرّر vi للنّصوص (اسم الأمر visudo هو مزيج من vi وsudo)، إلّا أنّه في أوبنتو مُعَدّ لاستخدام محرّر nano. في حال أردت العودة لاستخدام vi لتحرير ملفّ sudoers فالأمر التّالي يؤدّي هذه المهمّة sudo update-alternatives --config editorمثال على النّتيجة: There are 3 choices for the alternative editor (providing /usr/bin/editor). Selection Path Priority Status ------------------------------------------------------------ * 0 /bin/nano 40 auto mode 1 /bin/nano 40 manual mode 2 /usr/bin/vim.basic 30 manual mode 3 /usr/bin/vim.tiny 10 manual modeاختر العدد الموافق للمحرّر الّذي تريد اختيّاره. على CentOS، يمكن تغيير هذه القيمة بالتّعديل على السّطر التّالي، الموجود في ملفّ bashrc./~ (تمثّل /path/to/editor المسار إلى المحرّر المطلوب): export EDITOR=/path/to/editorلأخذ التّغييرات في الحسبان، نفِّذ الأمر: ~/.bashrcنفّذ الأمر التّالي، بعد الانتهاء من ضبط visudo، للوصول إلى ملفّ etc/sudoers/: sudo visudoكيف تحرّر ملفّ Sudoersسيظهر - بعد تنفيذ أمر visudo - ملفّ sudoers في محرّر النّصوص. أدناه ملفّ sudoers في أوبنتو 14.04 بعد حذف التّعليقات (يتضمّن الإعدادات الّتي ضبطناها في درس كيف تُضيف أو تحذف المستخدمين على خادوم أوبنتو 14.04). في CentOS يحوي الملفّ أسطرًا أكثر؛ لن نناقشَها كلَّها في هذا الدّليل. Defaults env_reset Defaults mail_badpass Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" root ALL=(ALL:ALL) ALL %admin ALL=(ALL) ALL %sudo ALL=(ALL:ALL) ALLفلنلقِ نظرة على عمل هذه الأسطر. 1- أسطر Defaultsالسّطر الأوّل Defaults env_reset يُعيد تعيين بيئة عمل الطّرفيّة من أجل حذف المتغيّرات الخاصّة بالمستخدمين من بيئة العمل. هذا الإجراء احترازيّ لمسح متغيّرات قد تكون مضرّة من جلسة sudo، Sudo session. تعليمة Defaults mail_badpass تطلب إرسال بريد إلى عنوان إلكتروني تُحدّده تعليمة أخرى (mailto) عندما يُدخل مستخدم كلمة سرّ خاطئة أثناء تنفيذ أمر sudo. هذه التّعليمة مُعطَّلة افتراضيًّا. أمّا التّعليمة الّتي تبدأ ب =Defaults secure_path فتحدّد المسارات Paths الآمنة الّتي سيُبحَث فيها عن أمر sudo. يحول هذا الإجراء دون استخدام مسارات قد تحوي برامج ضارّة. 2- أسطر امتيّازات المستخدميتعلّق السّطر الرّابع بالامتيّازات الّتي ينالها المستخدم عند تنفيذه أمر sudo. root ALL=(ALL:ALL) ALLيُشير الحقل الأوّل من السّطر إلى المستخدِم الّذي تنطبق عليه التّعليمة (المستخدِم الجذر في هذه الحالة). قيمة الحقل التّالي (ALL) تُشير إلى أنّ القاعدة تُطبَّق على جميع المستضيفات Hosts.الحقل الثّالث يُعيّن المستخدمين الّذين يُمكن للمستخدم المحدّد في الحقل الأوّل من السّطر (root في هذه الحالة) تنفيذُ أوامر بامتيّازاتهم. قيمة ALL تعني “كلّ المستخدمين”.الحقل الرّابع يُعيّن مجموعات المستخدمين Groups الّتي يُمكن للمستخدم المحدّد في الحقل الأوّل من السّطر (root في هذه الحالة) تنفيذُ أوامر بامتيّازاتهم. قيمة ALL هنا تعني “كلّ المجموعات”.الحقل الأخير يُشير إلى الأوامر الّتي ينال المستخدم المحدّد في الحقل الأوّل من السّطر امتيّاز تنفيذها بامتيّازات إداريّة. قيمة ALL هنا تعني “جميع الأوامر”.يُمكن تفسير السّطر على النّحو التّالي: لدى المستخدم root امتيّاز تنفيذ sudo على أي أمر بشرط تقديمه لكلمته للسّر. 3- أسطر امتيّازات مجموعات المستخدمينيُشبه السّطران الأخيران سطرَ امتيّازات المستخدِم، لكنّها تحدّد امتيّازات مجموعة من المستخدمين. تُشير الكلمات الّتي تسبقها علامة % إلى أسماء مجموعات مستخدمين. نلاحِظ أن مجموعة المستخدمين admin يُمكنها تنفيذ أيّ أمر بامتيّازات أي مستخدم على جميع المستضيفات؛ أمّا مجموعة admin فلديها، زيّادةً على امتيّازات مجموعة admin، إمكانيّة تنفيذ أوامر بامتيّازات أي مجموعة مستخدمين. كيف تضبُط قواعد مخصَّصةنتناول، بعد التّعرف على الصّيغة العامة لقواعد ملفّ sudoers، في هذه الفقرة طريقة إنشاء قواعد جديدة. 1- كيف تُنشئ كِنى Aliasesيُمكن تنظيم ملفّ sudoers عن طريق تجميع بعض التّعليمات بواسطة كِنى مختلفة. يُنشئ المثال التّالي ثلاث مجموعات مستخدمين (تعليمة User_Alias)، بعضويّات متداخلة: User_Alias GROUPONE = abby, brent, carl User_Alias GROUPTWO = brent, doris, eric, User_Alias GROUPTHREE = doris, felicia, grantيجب أن يبدأ اسم المجموعة بحرف كبير Capital letter. يُمكننا الآن إنشاء قاعدة في ملفّ sudoers تسمح لأعضاء المجموعة GROUPTWO تحديث قاعدة بيانات apt-get : GROUPTWO ALL = /usr/bin/apt-get updateإن لم نُحدّد مستخدمًا أو مجموعة مستخدمين يُنفّذ بامتيّازاتها الأمر، فإن sudo تأخذ المستخدم الجذر root لتنفيذ الأوامر باسمه. في المثال أدناه نمنح أعضاء GROUPTHREE صلاحيّة إيقاف وإعادة تشغيل الجهاز؛ عبر إنشاء “كنية أوامر” Command alias (تعليمة Cmnd_Alias) واستخدامها في قاعدة للمجموعة GROUPTHREE: Cmnd_Alias POWER = /sbin/shutdown, /sbin/halt, /sbin/reboot, /sbin/restart GROUPTHREE ALL = POWERأنشأنا في السّطر الأوّل كنية باسم POWER تحوي أوامر لإيقاف وإعادة تشغيل الجهاز. ثمّ نعطي لأعضاء المجموعة GROUPTHREE امتيّاز تنفيذ هذه الأوامر. توجد أيضًا إمكانيّة إنشاء كنية بأسماء مستخدمين لتنفيذ الأوامر بامتيّازاتهم (Runas_Alias)، ثمّ إبدال جزء القاعدة الّذي يحدّد المستخدم الّذي لديه صلاحيّة تنفيذ الأمر بكنية أسماء المستخدمين. Runas_Alias WEB = www-data, apache GROUPONE ALL = (WEB) ALLفي المثال السّابق، أنشأنا كنية WEB لتنفيذ أوامر بامتيّازات www-data أو apache؛ ثمّ قاعدة تسمح لكلّ عضو في GROUPONE بتنفيذ أوامر بامتيّازات العضوَيْن المذكورَيْن. يجب الانتباه إلى أنّه في حال وجود تناقض بين قاعدتَيْن في ملفّ sudoers فإنّ القاعدة الأخيرة هيّ الّتي ستُطبَّق. 2- كيف تؤمِّن القواعدتوجد طرُق عدّة لتمكين تحكّم أكبر حول كيفيّة تفاعل sudo مع المستخدم. إذا أردنا مثلًا السّماح للمستخدمين بتنفيذ أمر updatedb، وهو أمر آمِن نسبيًّا، بامتيّازات المستخدم الجذر دون الحاجة لإدخال كلمة سرّ root فالقاعدة التّاليّة تؤدّي هذه المهمّة: GROUPONE ALL = NOPASSWD: /usr/bin/updatedbيظهر في القاعدة أعلاه وسم tag هو NOPASSWD والّذي يعني أنّه لن يُطلَب من المستخدم إدخال كلمة سرّ root. يوجد وسم آخر مصاحِب هو PASSWD (سلوك افتراضيّ) والّذي يطلُب إدخال كلمة السّر. ينطبق الوسم على بقيّة القاعدة ما لم يُذكر توءَمُه بعده. يُمكِن أن نجد قاعدةً على الشّكل التّالي مثلًا: GROUPTWO ALL = NOPASSWD: /usr/bin/updatedb, PASSWD: /bin/killيوجد وسم آخر مهمّ هو NOEXEC والّذي يُستخدم لمنع السّلوك غير الآمن لبعض البرامج. على سبيل المثال؛ تسمح بعض البرامج، مثل less، بتنفيذ أوامر أخرى داخل واجهتها: less fileحيثُ file اسم ملفّ يُنفَّذ عليه أمر less. الآن يُمكن تنفيذ أمر بنفس الصّلاحيّات الّتي نفّذنا بها less على النّحو التّالي (حيثُ command_to_run اسم أمر): !command_to_runلمنع هذا الأمر من الحصول، يُمكن كتابة قاعدة كالتّالية: username ALL = NOEXEC: /usr/bin/lessمعلومات متفرّقةنعرض في هذه الفقرة لمعلومات إضافيّة مفيدة عند التّعامل مع أمر sudo. إذا حدّدت مستخدمين، أو مجموعة مستخدمين، لتنفيذ أوامر بامتيّازاتهم عبر تعليمة Runas_Alias في ملفّ الإعداد؛ فيُمكنك تنفيذ أوامر بامتيّازات هؤلاء المستخدمين عن طريق خيّار u- أو g- على التّوالي: sudo -u run_as_user command sudo -g run_as_group commandحيثُ run_as_user وrun_as_group اسم المستخدم أو مجموعة المستخدمين على التّوالي، و command الأمر المُراد تنفيذه. يحفظ أمر sudo بعد استخدامه تفاصيلَ الاستيثاق Authentication (كلمة السّرّ) في الطّرفيّة الّتي نُفِّذ فيها لفترة من الوقت. يعني هذا أنّك لن تحتاج لإعادة كتابة كلمة السّرّ في كلّ مرّة تستخدم فيها sudo، ما لم تنقضِ فترة الحفظ. إن أردت تصفير المؤقّت، لأغراض أمنيّة مثلًا، نفّذ الأمر التّالي: sudo -kإذا رغبت في معرفة الامتيّازات المُعيَّنة للحساب الّذي تستخدمه فخيّار l- يعطيك هذه المعلومة: sudo -lسيعرض الأمر قائمة بالقواعد الّتي تعني حساب المستخدم ضمن ملفّ etc/sudoers/، وهو ما يُعطي فكرة جيّدة عن المسموح وغير المسموح به لمستخدم عند تنفيذ sudo. يحدُث أن تنسى كتابة sudo أمام أمر تريد تنفيذه بامتيّازات إداريّة، ممّا يؤدّي إلى فشل الأمر. يوجد الاختصار التّالي لتفادي كتابة الأمر مجدّدًا: sudo !!علامة التّعجّب مرّتين تعني “أعد تنفيذ الأمر الأخير”، وبما أنّها مسبوقة ب sudo فالأمر يُصبح “أعد تنفيذ الأمر الأخير بامتيّازات إداريّة”. إذا كنت تتمتّع بحسّ الفكاهة فيُمكنك إضافة تعليمة Defaults insults إلى ملفّ sudoers؛ عمل هذه التّعليمة يتلخّص في كتابة تقريع (بالإنجليزيّة) عندما يُخطئ المستخدم في كلمة السرّ عند تنفيذ أوامر بsudo: sudo visudoأضف التّعليمة التّاليّة بعد تعليمات Defaults الأخرى: Defaults insultsلتجربة الإعداد الأخير، نمسح كلمة السّرّ المحفوظة حتّى نتأكّد من أنّ sudo سيطلُب إدخال كلمة السّرّ: sudo -kثمّ ننفّذ الأمر التّالي، ونكتب كلمة سرّ خاطئة في المرّة الأولى: sudo lsمثال على النّتيجة: [sudo] password for demo: # أدخِل كلمة سرّ خاطئة Your mind just hasn't been the same since the electro-shock, has it? [sudo] password for demo: My mind is going. I can feel it.خاتمةيجب أن يكون لديك بعد إكمال هذا الدّرس فهمٌ جيّد لأساسيّات التّعامل مع ملفّ sudoers وطريقة قراءة وتعديل هذا الملفّ؛ إضافةً إلى معرفة طُرُق الحصول على امتيّازات إداريّة. تذكّر أنّه يوجد سبب لعدم منح امتيّازات المستخدم الأعلى للمستخدمين العاديّين؛ لذا من المهمّ جدًّا فهم آليّة عمل أيّ أمر قبل تنفيذه بامتيّازات root. لا تستهِر في التّعامل مع الصّلاحيّات الإداريّة، وتعلّم أفضل الطّرق لاستخدام هذه الأدوات لتلبيّة حاجاتك. احظُر أي ميزة لا ترى حاجة لاستخدامها. ترجمة بتصرّف لمقال How To Edit the Sudoers File on Ubuntu and CentOS لصاحبه Justin Ellingwood.
-
كتبت مؤخّرا برنامج 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.
-
توجد بعض الإعدادات التي يجب إجراؤها في البداية كجزء من عملية التثبيت الأولية عند إنشاء خادوم جديد. تؤدي هذه الخطوات إلى تعزيز أمان وقابلية استخدام 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.
-
- خادوم أوبنتو
- أوبنتو
-
(و 5 أكثر)
موسوم في:
-
يجب أن تضع الحماية نصب عينيّك عند تثبيت ونشر واستخدام أي نوع من أنظمة تشغيل الحاسوب؛ وعلى الرغم من أن تثبيتًا حديثًا لأوبنتو هو آمن نسبيًا للاستخدام الفوري على الإنترنت، لكن من المهم أن يكون لديك فهم متوازن لحالة حماية أنظمتك بناءً على طريقة استخدامها بعد «نشرها» (deployment). يزودك هذا الدرس بلمحة عن المواضيع المرتبطة بالحماية المتعلقة بنسخة خادوم أوبنتو 14.04، ويخط الخطوط العريضة للإجراءات التي يمكنك أن تستخدمها لحماية خادومك وشبكتك من أي عدد من التهديدات الأمنية المحتملة. إدارة المستخدمينإدارة المستخدمين هي جزء جوهري في الحفاظ على نظامٍ آمن؛ تقود الإدارة غير الكفء للمستخدمين والامتيازات عادةً إلى إضعاف أمان النظام؛ وبالتالي من الضروري أن تفهم كيف تحميه باستخدام تقنيات إدارة حسابات المستخدمين. أين هو حساب الجذر؟اتخذ مطورو أوبنتو قرارًا واعيًا بتعطيل حساب الجذر الإداري افتراضيًا في جميع حالات تثبيت أوبنتو؛ هذا لا يعني أن حساب الجذر محذوفٌ أو لا يمكن الوصول إليه، حيث أُسنِدَت إليه ببساطة كلمة مرور لا تُطابِق أيّة قيمة؛ أي أنك لا تستطيع الدخول إليه مباشرةً. لكن بدلًا من ذلك، يُحَثّ المستخدمون أن يستخدموا أداةً باسم sudo لتنفيذ مهام إدارة النظام؛ حيث تسمح sudo لمستخدم موثوق بترقية امتيازاته باستخدام كلمة مروره بدلًا من الحاجة لمعرفة كلمة المرور الخاصة بحساب الجذر. هذه الطريقة البسيطة تعطي المسؤولية لجميع أفعال المستخدم، وتمنح مدير النظام تحكمًا بالأفعال التي يستطيع القيام بها مع امتيازاته الحالية. إذا أردت تفعيل حساب الجذر لسبب ما، فببساطة أسند كلمة مرور لذاك الحساب: sudo passwdستطلب منك أداة sudo كلمة مرورك، ثم ستطلب منك توفير كلمة مرور جديدة لحساب الجذر كما هو موضح هنا: [sudo] password for username: (enter your own password) Enter new UNIX password: (enter a new password for root) Retype new UNIX password: (repeat new password for root) passwd: password updated successfullyاستخدم الأمر passwd بهذه الطريقة لتعطيل كلمة مرور حساب الجذر: sudo passwd -l rootلكن إذا أردت تعطيل الحساب نفسه، فاستخدم الأمر الآتي: usermod --expiredate 1تستطيع التعلم أكثر عن sudo بالنظر إلى صفحة الدليل المتعلقة بهذا الأمر: man sudoينتمي المستخدم الذي أُنشِئ أثناء تثبيت أوبنتو افتراضيًا إلى المجموعة «sudo» المُضافة إلى ملف /etc/sudoers كمستخدم sudo موثوق؛ إذا رغبت بمنح أيّ حساب آخر امتيازات الجذر كاملةً عبر sudo، فأضف ذاك الحساب إلى المجموعة sudo. إضافة وحذف المستخدمينعملية إدارة المستخدمين المحليين والمجموعات هي عملية بسيطة ومباشرة ولا تختلف إلا قليلًا بين أغلبية أنظمة تشغيل غنو/لينُكس الأخرى؛ تحث أوبنتو، والتوزيعات المبنية على دبيان، على استخدام الحزمة «adduser» لإدارة الحسابات. لإضافة حساب مستخدم جديد، استخدم الشكل العام الآتي، وأكمل مع الرسائل التي تطلب منك إعطاء كلمة مرور للحساب، وتعريف بعض الخاصيات مثل الاسم الكامل ورقم الهاتف ...إلخ. sudo adduser usernameاستخدم الأمر الآتي لحذف مستخدم ومجموعته الرئيسية: sudo deluser usernameلا يؤدي حذف حساب مستخدم إلى حذف مجلد المنزل الموافق له؛ هذا يعود لك إن كنت تريد أو لا تريد حذف المجلد يدويًا أو الإبقاء عليه وفقًا لسياساتك. تذكر أن أي مستخدم آخر يُضاف لاحقًا بنفس معرفَيّ UID/GID للمستخدم القديم سيحصل على وصول كامل لهذا المجلد إذا لم تتخذ الاحتياطات اللازمة. قد ترغب بتغيير قيم UID/GID إلى قيم أخرى ملائمة أكثر -كحساب الجذر مثلًا- وربما تريد أيضًا نقل المجلد لتفادي التضاربات المستقبلية: sudo chown -R root:root /home/username/ sudo mkdir /home/archived_users/ sudo mv /home/username /home/archived_users/لكي تقفل حساب مستخدم مؤقتًا أو تلغي قفله، فاستخدم الأمر passwd مع الخيارات الموافقة للعملية التي تريد إجراءها كما يلي (على التوالي وبالترتيب): sudo passwd -l username sudo passwd -u usernameلإضافة أو حذف مجموعة خاصة، فاستخدم الأمرين الآتيين على التوالي وبالترتيب: sudo addgroup groupname sudo delgroup groupnameاستخدم الشكل الآتي من أمر adduser لإضافة مستخدم إلى مجموعة: sudo adduser username groupnameأمن حساب المستخدمعندما يُنشأ مستخدمٌ جديد، فستُنشِئ الأداة adduser مجلد منزل جديد باسم /home/username، يتشكل ملف الحساب (profile) الافتراضي اعتمادًا على المحتويات الموجودة في مجلد /etc/skel الذي يحتوي على أساسيات ضبط الحساب. إذا كان سيحتوي خادومك على عدّة مستخدمين، فيجب أن تولي أذونات مجلد المنزل للمستخدم اهتمامًا شديدًا لتحقيق سرية بياناته؛ افتراضيًّا، مجلدات منزل المستخدم في أوبنتو تُنشَأ بأذونات القراءة والتنفيذ؛ هذا يعني أن كل المستخدمين يستطيعون الوصول والتجول في محتويات مجلدات المنزل للمستخدمين الآخرين، ربما لا يلائم ذلك احتياجات بيئة تشغيل نظامك. استخدم الأمر الآتي للتأكد من أذونات مجلد المنزل للمستخدمين الحاليين: ls -ld /home/usernameيُظهِر الناتج الآتي أن مجلد /home/username لديه أذن القراءة لجميع المستخدمين (العالم أو world): drwxr-xr-x 2 username username 4096 2007-10-02 20:03 usernameتستطيع إزالة أذن القراءة للجميع بتنفيذ الأمر: sudo chmod 0750 /home/usernameملاحظة: بعض الأشخاص يميلون لاستخدام الخيار التعاودي (-R [recursive]) دومًا دون تمييز الحالات التي يجب استخدامه فيها، الذي يُعدِّل أذونات المجلدات «الأبناء» والملفات التي فيها، لكن هذا ليس ضروريًا، وربما يتسبب ببعض النتائج غير المرغوب بها؛ يكفي تعديل أذونات المجلد «الأب» فقط لمنع المستخدمين غير المصرَّح لهم بدخول أي شيء داخل هذا المجلد الأب. طريقة أخرى أكثر فعاليةً هي تعديل ضبط الأذونات الافتراضية العام للأداة adduser عند إنشاء مجلدات المنزل للمستخدمين الجدد؛ عدِّل ببساطة الملف /etc/adduser.conf وغيِّر قيمة المتغير DIR_MODE إلى قيمةٍ مناسبةٍ، حيث ستحصل جميع مجلدات المنزل الجديدة على الأذونات الصحيحة: DIR_MODE=0750بعد تصحيح أذونات المجلد باستخدام إحدى الطرق السابق ذكرها، فتأكد من النتائج بالأمر: ls -ld /home/usernameالنتائج الآتية تُظهِر أنه قد أُزيل إذن القراءة لجميع المستخدمين: drwxr-x--- 2 username username 4096 2007-10-02 20:03 usernameسياسة كلمة المرورأحد أهم الجوانب في حماية نظامك هو استخدام سياسة قوية لكلمات المرور؛ إذ تتطلب العديد من الاختراقات الأمنية الناجحة استخدام هجمات «القوة القاسية» (brute force) وتخمين كلمات المرور الضعيفة من القاموس؛ إذا كنت تنوي توفير أي نوع من التحكم البعيد الذي يتطلب كلمة المرور المحلية للنظام، فتأكد أنك تحقق المتطلبات الدنيا من تعقيد كلمات المرور، ومدة كلمة المرور الدنيا، والتدقيق الرتيب لأنظمة الاستيثاق عندك. طول كلمة المرور الدنياتتطلب أوبنتو افتراضيًا طولًا أصغريًا لكلمة المرور يساوي ستة محارف، يمكن التحكم بهذه القيمة في ملف /etc/pam.d/common-password الظاهر هنا: password [success=2 default=ignore] pam_unix.so obscure sha512إذا أردت تغيير الحد الأدنى لطول كملة المرور إلى ثمانية محارف، فعدِّل المتغير الملائم إلى min=8؛ كما يلي: password [success=2 default=ignore] pam_unix.so obscure sha512 min=8ملاحظة: التحقق البسيط من كلمة المرور، والطول الأدنى لها لا يُطبَّق على الأوامر المُنفَّذة باستخدام sudo لإعداد مستخدم جديد. مدة صلاحية كلمة المرورعند إنشاء حسابات للمستخدمين، فيجب أن تُنشِئ سياسة لعمر كلمة المرور الأدنى والأقصى وإجبار المستخدمين على تغيير كلمات مرورهم عندما تنتهي مدتها. استخدم الأمر الآتي لعرض حالة حساب مستخدم: sudo chage -l usernameيُظهِر ناتج الأمر السابق حقائق مثيرة للاهتمام حول حساب المستخدم، ولنفترض أنه لا توجد أيّة سياسات مطبَّقة: Last password change : Jan 20, 2008 Password expires : never Password inactive : never Account expires : never Minimum number of days between password change : 0 Maximum number of days between password change : 99999 Number of days of warning before password expires : 7استخدم الأمر الآتي ببساطة وتابع مع الرسائل التفاعلية لضبط أيّة قيمة من هذه القيم: sudo chage usernameما يلي مثالٌ لطريقة تغيير تاريخ انتهاء الصلاحية (-E) إلى 01/31/2008، والعمر الأدنى لكلمة المرور (-m) إلى 5 أيام، والعمر الأقصى لكلمة المرور (-M) إلى 90 يومًا، ومدة الخمول (inactivity، الخيار -I) إلى 5 أيام بعد انتهاء صلاحية كلمة المرور، ومدة وقت التحذير (-W) إلى 14 يومًا قبل انتهاء صلاحية كلمة المرور. sudo chage -E 01/31/2008 -m 5 -M 90 -I 5 -W 14 usernameللتأكد من التعديلات، استخدم نفس الأمر المذكور آنفًا: sudo chage -l usernameيجب أن يُظهِر الناتج السياسات الجديدة التي أعددناها لهذا الحساب: Last password change : Jan 20, 2008 Password expires : Apr 19, 2008 Password inactive : May 19, 2008 Account expires : Jan 31, 2008 Minimum number of days between password change : 5 Maximum number of days between password change : 90 Number of days of warning before password expires : 14اعتبارات أمنية أخرىتستخدم العديد من التطبيقات آليات استيثاق أخرى يمكن أن يغفلها حتى مدراء الأنظمة الخبراء؛ وبالتالي فمن المهم فهم والتحكم في طريقة استيثاق المستخدمين وحصولهم على الوصول إلى الخدمات والتطبيقات على خادومك. وصول SSH من المستخدمين المعطلينلا يمنع تعطيل حساب مستخدم من دخوله إلى خادومك عن بعد إن كان قد ضبط استيثاق بمفتاح RSA عام؛ وسيتمكنون من الحصول على وصول إلى الصدفة (shell) في الخادوم دون الحاجة لأيّة كلمة مرور؛ تذكر أن تتحقق من مجلد المنزل للمستخدمين الذي يسمحون بهذا النوع من وصول SSH الذي تم الاستيثاق منه؛ أي /home/username/.ssh/authroized_keys. احذف أو أعد تسمية مجلد .ssh/ في مجلد المنزل للمستخدم لتعطيل إمكانيات الاستيثاق عبر SSH. تأكد أن تتحقق من أيّة اتصالات SSH قد أُنشِئت من المستخدم المعطَّل؛ حيث من الممكن أن يملكوا اتصالات داخلة أو خارجة موجودة مسبقًا، «اقتل» (kill) تلك العمليات إذا عثرت عليها. who | grep username # to get the pts/X terminal sudo pkill -f pts/Xاحصر الوصول عبر SSH إلى حسابات المستخدمين الذين يجب أن يحصلوا عليها فقط؛ فعلى سبيل المثال، ربما تنُشِئ مجموعة تسميها «sshlogin» وتضيف اسم المجموعة كقيمة مرتبطة بالمتغير AllowGroups الموجود في الملف /etc/ssh/sshd_config. AllowGroups sshloginثم أضف مستخدمي SSH المسموح لهم إلى المجموعة «sshlogin»، وأعد تشغيل خدمة SSH: sudo adduser username sshlogin sudo service ssh restartاستيثاق المستخدم بقواعد البيانات الخارجيةتتطلب معظم الشبكات المشاريع التجارية آليةَ استيثاقٍ مركزية والتحكم بالوصول إلى جميع مصادر النظام، إذا ضبطت خادومك ليستوثق من المستخدمين من قاعدة بيانات خارجية؛ فتأكد من تعطيل حسابات المستخدمين محليًا وخارجيًا، وبهذا تتأكد من أن البديل المحلي للاستيثاق غير متوفر. تأمين الطرفيةوكما غيرها من ترسانة الحماية التي تستخدمها لحماية خادومك، من القواعد الصارمة هو التأمين ضد الأضرار الناتجة عن شخص لديه الوصول الفيزيائي لبيئتك، على سبيل المثال، سرقة الأقراص الصلبة، أو خلل في الطاقة الكهربائية ...إلخ؛ وبالتالي يجب أن يكون تأمين الطرفية جزءًا رئيسيًا في استراتيجية الحماية الفيزيائية؛ سيحد «قفل الشاشة» (screen door) من تأثير مجرم عادي، أو على الأقل سيبطئ عمل مجرم مصمم على إلحاق الأذى بنظامك! لذلك من المستحسن إجراء بعض احتياطات الوقاية فيما يتعلق بحماية الطرفية. سيساعدك ما يلي في الدفاع عن خادومك ضد المشاكل التي قد تسبب عواقب وخيمة. تعطيل Ctrl+Alt+Deleteبادئ ذي بدء، يستطيع أي شخص لديه الوصول الفيزيائي للوحة المفاتيح ببساطة أن يستخدم تجميعة المفاتيح «Ctrl+Alt+Delete» لإعادة إقلاع الخادوم دون الحاجة لتسجيل الدخول؛ طبعًا يمكن لأي شخص إزالة كبل الكهرباء من المقبس، لكن ما يزال عليك منع استخدام هذه التجميعة على خادوم إنتاجي؛ وهذا يجبر المهاجم على اتخاذ إجراءات عنيفة لإعادة إقلاع الخادوم، وسوف يمنع إعادة الإقلاع غير المقصودة في نفس الوقت. لتعطيل إعادة إقلاع الخادوم بالضغط على تجميع الأزرار Ctrl+Alt+Delete، فضع رمز التعليق قبل السطر الآتي في ملف /etc/init/control-alt-delete.conf: #exec shutdown -r now "Control-Alt-Delete pressed"ترجمة -وبتصرف- للمقال Ubuntu Server Guide: User Management.