بهبود امنیت SSH در ابر

سرویس‌های رایانش ابری مانند سرویس های ابر آوند از SSH به عنوان اصلی‌ترین روش تأیید هویت سرورهای لینوکس استفاده می‌کنند. به عقیده بسیاری از متخصصان انتخاب پروتکل SSH، یک انتخاب درخشان و نتیجه‌بخش است که دلیل آن کاهش بروکراسی‌هایی‌ست که بخشی از پروتکل‌های تایید اعتبار را تشکیل می‌دهند. زیرا اجرای پروتکل‌های فعلی که توسط ارائه‌دهندگان ابری مورد استفاده قرار می‌گیرد از کارآیی بالایی بهره‌مند نیست.

روش‌های انجام شده:

برای اینکه اعتبار یک دستگاه را تائید کنید، به یک فایل pem که حاوی کلید خصوصی‌ست، نیاز خواهید داشت. کلید عمومی مرتبط به سرویس سرو (یا توسط کاربر بارگذاری شده یا توسط خود سرویس تولید شده است) نیز شناسایی می‌شود و هنگام ساخت سرور مجازی، فایل pem مورد نظر به آن منتقل خواهد شد. در نهایت پس از شروع کار Daemon SSHD، کاربران دارای کلید خصوصی می‌توانند وارد دستگاه شوند.

اشکال کار در چیست؟

مدیریت فایل‌های pem (کلیدهای خصوصی) به دلایل مختلفی که در این قسمت به آن می‌پردازیم، مشکلاتی را با خود به همراه دارد:

انتقال کلید‌های ناامن:

به منظور دسترسی بیشتر از یک کاربر به یک گروه در حال اجرا، فایل‌های pem نیز باید به نوعی انتقال پیدا کنند. با توجه به تجربیاتی که در این راستا به‌دست آمده، کاربران با استفاده از ایمیل یا فضای ذخیره‌سازی مشترک در دسترس برای کل شرکت، فایل‌های pem (کلید خصوصی) را ارسال می‌کنند. این مسئله می‌تواند یک حفره امنیتی بسیار بزرگی را با خود به همراه داشته باشد، زیرا پس از انتقال، پیگیری آن کاری بس دشوار است. هیچ اطمینانی از اینکه کلید در دست چه کسانی قرار می‌گیرد وجود نخواهد داشت.

گمشدن/دزدیدن لپ‌تاپ:

وقتی شخصی لپ‌تاپ خود را با فایل‌‌های کلید خصوصی pem موجود در آن از دست می‌دهد، معمولا فرآیند آنالیز ریسک خطرناک آغاز می‌شود. همه به نوعی در تلاش‌اند تا پرونده‌های pem موجود در آن را کشف کرده و همچنین روش‌های چگونگی باطل‌کردن آن را بیاموزند. این کار معمولا تحت استرس و بلاتکلیفی بسیار زیادی صورت می‌گیرد و حتی سایر افراد نیازمند به دسترسی ماشین‌ها را نیز آشفته می‌کند.

گم کردن پرونده‌های pem:

هرچند بروز این اتفاق امری نادر است اما با این‌حال باید احتمالات را در نظر گرفت. سوالی که در این‌جا ذهن بسیاری از افراد را به خود مشغول می‌کند این است که اگر یک فایل pem حاوی کلید خصوصی از بین برود و شما همچنان تمایل به استفاده از آن باشید چه اتفاقی رخ می‌دهد؟

راه‌حل:

استفاده از SSH با مجوز و گواهینامه (CA) برای اعتبارسنجی مشتریان یکی از بهترین راه‌حل‌های موجود است. یکی از جالبترین ویژگی‌هایSSH ، که همواره از آن یاد می‌شود امکان استفاده از CA برای ایجاد گواهینامه‌های مشتریان است. با استفاده از این روش، توسعه‌دهندگان که به دسترسی یک ماشین نیاز دارند، به راحتی یک کلید خصوصی و عمومی ایجاد کرده و کلید عمومی را برای بخش مدیریت ارسال می‌نمایند. (توجه داشته باشید که کلید خصوصی هرگز از دستگاه توسعه‌دهنده خارج نمی‌شود). بخش مدیریت نیز یک گواهی از کلید عمومی تولید می‌کند و آن را با استفاده از کلید خصوصی CA امضا و گواهینامه را برای توسعه‌دهنده می‌فرستد. (این گواهی هیچ رمزی ندارد). این دستگاه‌ها به منظور استفاده از کلید عمومی CA و برای اعتبارسنجی تنظیم شده‌اند و به‌طور دوره‌ای به‌روزرسانی می‌شوند.

به هر حال، لطفاً SSH PKI و X509 را اشتباه نگیرید. SSHها به هیچ‌عنوان جزء گواهینامه‌های X509 نیستند. SSH به دلایلی کدنویسی PKI خاص خود را دارد.

مزایای استفاده از SSH:

هیچ نیازی به ارسال رمز از طریق کانال‌های غیرایمن نیست.

اگر لپ‌تاپ خود را گم کنید، کلید‌های خصوصی به طور خودکار به لیست ابطال اضافه می‌شوند. بدون اینکه سایر کاربران نسبت به این موضوع اطلاعی پیدا کنند. این روش در به حداقل رساندن آسیب‌ها تاثیر بسیار زیادی دارد.

می‌توان گواهینامه را با زمان انقضا برای یک میزبان خاص و... صادر نمود که در صورت هک‌شدن، خطر را تا حدود زیادی کاهش می‌دهد.

چگونگی انجام آن:

این روزها اکثر کاربران از Hashicorp Vault برای ذخیره کلیدهای خصوصی CA و امضای کلیدهای کاربران و تولید گواهی استفاده می‌کنند. هرچند که به عقیده بسیاری از متخصصان Vault (نسخه 0.8.2.1) راه‌حل مناسبی برای این کار نیست زیرا توانایی ابطال لیست را ندارد اما با این‌حال روشی به مراتب بهتر در برابر ذخیره کلیدهای خصوصی CA در مکانی ناامن و بدون ممیز است.

پیکربندی سرورها به روش زیر کارآمدتر است:

در ابتدا باید به سراغ ایجاد یک گروه و مسیر برای ذخیره کلید عمومی CA و همچنین لیست ابطال بروید. ( هیچ رمزی وجود ندارد)، درواقع در این بخش تنها سیاستی برای خواندن ایجاد کرده‌اید و آن را به نقش‌های IAM مورد استفاده اضافه کرده‌اید. به عبارت بهتر با این روش در تمام دستگاه‌هایی که از زمان راه‌اندازی در حال فعالیت هستند سرویسی را اضافه کرده‌اید. اغلب توصیه می‌شود که این سرویس قبل از شروع SSH اضافه شود تا همواره امن بماند.

هرچند می‌توان به پرونده pem CA از طریق Vault نیز دسترسی پیدا کرد. اما تصمیم گرفته‌شده به دلیل پشتیبانی نکردن آن از سیستم لغو خودکار آن را در S3 قرار دهند. معمولا راه‌اندازی Vault به نوع SSH بستگی دارد.

یک مشکل کوچک:

برای مقابله با چنین شرایطی باید به سراغ استفاده از terraform بروید. متاسفانه terraform نسبت به چگونگی کار با کلید خصوصی و مجوزهای موجود آگاهی کاملی ندارد. از همین‌رو برای برطرف‌کردن این مشکل، باید از ssh-agent در shell  ماشینی که قصد تهیه آن را دارید استفاده کنید. شما باید کلید خصوصی و گواهینامه خود را اضافه کرده (با استفاده از ssh-add)، و سپس کلید خصوصی را از stanza پاک کنید. این گونه دستور “terraform apply” به جای این‌که سعی کند ssh را به صورت دستی به اجرا درآورد، از agent ها کمک می‌گیرد.

سخت کردن ssh

ما فقط توصیه‌های زیر را دنبال می‌کنیم:

https://ef.gy/hardening-ssh

پورت‌های SSH هرگز نباید با کلمات خارجی باز شوند.

پورت‌های SSH هرگز نباید در معرض اینترنت قرار گیرند. این امر با بهره‌گیری از گروه‌ها و قوانین موجود در SSH امکان‌پذیر است. به‌گونه‌ای که تنها در صورتی اجازه استفاده از اینترنت را می‌دهد که از آدرس IP استاتیک استفاده شده باشد. این آدرس IP به شما کمک می‌کند تا گروه امنیتی مختص خود را تنظیم کنید. فراموش نکنید باید Rule اعمال شده برای اتصال را پس از اتمام کار پاک کنید.