با پورت ۲۲ چه باید کرد
سوژه‌ای از دل توییتر فارسی
چند روز پیش توی توییتر، برخی از دوستان درمورد پورت SSH و کلا بحث‌های امنیتی مرتبط با اون، توییت‌های مختلفی نوشتن که حسابی برام جالب بود. بعضی‌هاشو اینجا با یه مقدار توضیح اضافه که دیدگاه شخصی و تجربی خودم هست، می‌نویسم. شاید بعدا به درد دیگران بخوره 😉
ماجراها از جایی شروع شد که بعد از قضیه نقض اطلاعات شرکت تپسی، کاربری توییت کرده بود که پورت ssh وب‌سرور سایت tap30.ir، روی پورت پیش‌فرض تنظیم شده و این موضوع رو به‌عنوان یک ضعف امنیتی معرفی کرده بود.
فارغ از اینکه این حرف چقدر درسته یا نه، یکی از واکنش‌های جالب به این توییت رو هم اضافه می‌کنم که بعدش برسیم به منبر اختصاصی این موضوع 😆
روش‌های متداول برای ایمن‌سازی پروتکل SSH
پروتکل SSH و پورت 22 رو میشه با روش‌های مختلفی ایمن‌سازی و امن کرد که برخی از اون‌ها به‌نوعی استانداردهای امنیتی رسمی برای این پروتکل شناخته میشن؛ هرچند که هیچ اجباری نیست که همه‌ی این موارد که می‌خوام بگم همزمان و در کنار هم اعمال بشن، اما میشه با توجه به نوع کاربری این پروتکل برای میزبان یا صاحبان‌شون، یک یا چندتا از این موارد رو اعمال کرد.
۱- استفاده از تنظیمات فایروال برای تمام پورت‌ها و مشخصا فیلتر کردن پورت SSH
۲- استفاده از «TCP Wrappers» برپایه ACL یا همون تعریف فهرست کنترل دسترسی‌ها که میشه گفت شبیه فایروال‌ها عمل می‌کنه
۳- غیرفعال کردن اتصال از طریق یوزر Root
۴- ساخت و استفاده از SSH key به‌جای پسورد که یکی از مناسب‌ترین روش‌ها محسوب میشه
۵- استفاده از پسورد قوی برای SSH key و حتی یوزرهای خود سیستم میزبان
۶- تنظیم Idle Timeout به شدت برای ادارات، سازمان‌ها و استارتاپ‌هایی که کارمند دفتری دارن، توصیه میشه!
۷- غیرفعال‌سازی دسترسی یوزرهای بدون پسورد سیستم با تنظیم PermitEmptyPasswords در sshd_config
۸- استفاده از پکیج‌های حفاظتی مثل Fail2ban برای مقابله با brute force
۹- محدود‌سازی تلاش‌های ناموفق برای اتصال با تنظیم MaxAuthTries در sshd_config
۱۰- اضافه کردن نوتیفیکیشن ارسال ایمیل، برای آگاهی از لاگین‌ها
۱۱- حتی حوصله داشتید فعال‌سازی احراز هویت چند عاملی برای SSH
۱۲- و در نهایت تغییر پورت پیش‌فرض
تغییر پورت پیش‌فرض و به‌عبارتی بودن یا نبودن، مساله این است
راستش من مخالف تغییر پورت پیش‌فرض نیستم و معتقدم در جاهایی شاید حتی به درد هم میخوره! البته که تاکید می‌کنم هیچ اجباری به این کار نیست؛ وقتی برای مثال شما در فایروال سرورت whitelist داری، لاگین‌ها فقط با کلید انجام میشن و Fail2ban هم نصب و تنظیم کردی، در مجموع وضعیت امنیتی پروتکل SSH سرورت خوب و عالی پیکربندی شده و مشکلی به‌صورت کلی نیست؛ اما با این حال تغییر پورت یه سری جاها هم بد نیست، مثلا:
۱- زمانی که یک آسیب‌پذیری روز صفر خفن در openssl شناسایی میشه، این کار احتمال اینکه جزو اولین قربانیان اون آسیب‌پذیری باشین رو کاهش میده و «براتون مقداری زمان میخره»! نباید فراموش کنیم که بخش اعظم بات‌نت‌ها و حملات عمومی در شبکه، برپایه اسکن‌های کلی روی تنظیمات پیش‌فرض در کل اینترنت انجام میشه که خب هر چیزی که توی نتایج اولیه بیاد رو همیشه روی هوا می‌زنن!
بی‌ربط نیست این «CVE-2018-10933» رو ببینید.
۲- لاگ تمیز براتون ذخیره میشه و از شر لاگ مزخرف حاصل از تلاش‌های جوجه هکرها با یه مشت تولز مسخره راحت میشید. چیه خنده‌تون گرفته؟ 😂 باور کنید بعضی وقت‌ها کلی چرت و پرت سر همین مساله روی لاگ سرور ثبت میشه و آدم نمی‌فهمه با یه هکر خفن طرفه یا یه مشت جوجه هکر بی‌کار...
اینکه آرآ «@irLinja» توی توییتش اشاره کرده بود رو من قبول دارم، تغییر پورت عملا نقطه‌ای که «درب ورود» محسوب میشه رو تغییر میده و در نهایت اون پورت با یه فاصله کوتاه، سر جای جدیدی قرار می‌گیره... اما مسیر عبور گوسفندها اینجوری بسته میشه و نمی‌تونن کله‌شون رو بندازن پایین و مستقیم، راه همیشگی رو طی کنن. ضمن اینکه بالاتر هم گفتم، این موضوع کمک می‌کنه که توی بررسی لاگ‌ها، آدم متوجه بشه که بعضی وقت‌ها به‌صورت جدی تارگت (حرفه‌ای‌ها) شده یا نه.