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