با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
SSH ارتباط Shell رمزگذاریشده میدهد
SSH کانال رمزنگاریشده برای Shell و مدیریت Remote فراهم میکند؛ Key-based Authentication و محدودسازی دسترسی Admin امنیت را بهتر میکند باز گذاشتن Password Login عمومی روی اینترنت ریسک حمله را بالا میبرد نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که در Linux بهتر است هر تغییر را با شناخت Service و فایل پیکربندی مربوط انجام دهی؛ وضعیت Process، Socket، Permission و Log معمولاً سرنخهای اصلی هستند؛ systemd و journal ابزارهای مرکزی در بسیاری از توزیعهای مدرناند و NetworkManager نیز در RHEL برای مدیریت شبکه استفاده میشود؛ قبل از ویرایش، نسخه فایل و راه بازگشت نگه داشته شود در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که Permission و مالکیت در Linux باید با نیاز واقعی Service هماهنگ باشد؛ اجرای همه چیز با root مشکل را پنهان میکند و سطح ریسک را بالا میبرد؛ User و Group مناسب، حداقل Permission لازم و sudo کنترلشده روش قابل نگهداریتری است؛ بعد از تغییر، هم دسترسی مورد نیاز و هم عدم دسترسی ناخواسته بررسی شود برای کامل شدن تصویر این موضوع، در این درس Linux را از دید یک پشتیبان شبکه بررسی میکنیم؛ لازم نیست همه جزئیات سیستمعامل را حفظ کنی، اما باید ساختار فایلها، User و Permission، Serviceها، Network و Log را بشناسی؛ هدف این است که قبل از تغییر بدانی کدام Service و فایل درگیر است، از Log شواهد بگیری و تغییر را با حداقل دسترسی و امکان بازگشت انجام بدهی
Public Key میتواند جای Password استفاده شود
در SSH احراز هویت با Key میتواند جای Password را بگیرد؛ Private Key باید محرمانه بماند و Public Key روی حساب مقصد مجاز میشود راهنمای CISA و NIST بر چند پایه تکرارشونده تأکید دارد: استفاده از MFA برای حسابهای مهم، بهروزرسانی منظم، محدود کردن دسترسی مدیریتی، نگهداری Backup قابل بازیابی، ثبت رویدادها و آموزش مقابله با فیشینگ؛ در رخداد مشکوک، هدف اول حفظ شواهد و محدود کردن دامنه اثر است، نه انجام تغییرهای متعدد و بدون ثبت؛ حسابهای مدیریتی باید از حساب روزمره جدا باشند و سطح دسترسی فقط به اندازه نیاز کاری داده شود برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که Permission و مالکیت در Linux باید با نیاز واقعی Service هماهنگ باشد؛ اجرای همه چیز با root مشکل را پنهان میکند و سطح ریسک را بالا میبرد؛ User و Group مناسب، حداقل Permission لازم و sudo کنترلشده روش قابل نگهداریتری است؛ بعد از تغییر، هم دسترسی مورد نیاز و هم عدم دسترسی ناخواسته بررسی شود برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، در Linux بهتر است هر تغییر را با شناخت Service و فایل پیکربندی مربوط انجام دهی؛ وضعیت Process، Socket، Permission و Log معمولاً سرنخهای اصلی هستند؛ systemd و journal ابزارهای مرکزی در بسیاری از توزیعهای مدرناند و NetworkManager نیز در RHEL برای مدیریت شبکه استفاده میشود؛ قبل از ویرایش، نسخه فایل و راه بازگشت نگه داشته شود
Root Login مستقیم بهتر است محدود شود
محدود کردن SSH مستقیم برای root باعث میشود ورود با کاربر مشخص و سپس sudo قابلردیابیتر باشد؛ قبل از غیرفعالسازی مطمئن شو مسیر مدیریتی جایگزین کار میکند پایش مؤثر فقط جمع کردن عدد و Log نیست؛ باید وضعیت عادی سرویس شناخته شود، Metricهای معنادار انتخاب شوند و Alert زمانی ایجاد شود که نیاز به اقدام دارد؛ Syslog چارچوبی برای انتقال پیامهای رویداد ارائه میدهد و SNMP برای مشاهده و مدیریت بسیاری از تجهیزات شبکه استفاده میشود؛ همگام بودن زمان سیستمها برای ارتباط دادن رویدادهای چند دستگاه ضروری است و Log باید در کنار وضعیت سرویس و تغییرات همان بازه تحلیل شود در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: در Linux بهتر است هر تغییر را با شناخت Service و فایل پیکربندی مربوط انجام دهی؛ وضعیت Process، Socket، Permission و Log معمولاً سرنخهای اصلی هستند؛ systemd و journal ابزارهای مرکزی در بسیاری از توزیعهای مدرناند و NetworkManager نیز در RHEL برای مدیریت شبکه استفاده میشود؛ قبل از ویرایش، نسخه فایل و راه بازگشت نگه داشته شود برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، Permission و مالکیت در Linux باید با نیاز واقعی Service هماهنگ باشد؛ اجرای همه چیز با root مشکل را پنهان میکند و سطح ریسک را بالا میبرد؛ User و Group مناسب، حداقل Permission لازم و sudo کنترلشده روش قابل نگهداریتری است؛ بعد از تغییر، هم دسترسی مورد نیاز و هم عدم دسترسی ناخواسته بررسی شود
Host Key هویت Server را تأیید میکند
SSH Host Key به Client کمک میکند Server قبلی را بشناسد؛ تغییر ناگهانی Fingerprint میتواند از نصب مجدد Server یا حمله واسط باشد و نباید بدون بررسی Warning را حذف کنی نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که در Linux بهتر است هر تغییر را با شناخت Service و فایل پیکربندی مربوط انجام دهی؛ وضعیت Process، Socket، Permission و Log معمولاً سرنخهای اصلی هستند؛ systemd و journal ابزارهای مرکزی در بسیاری از توزیعهای مدرناند و NetworkManager نیز در RHEL برای مدیریت شبکه استفاده میشود؛ قبل از ویرایش، نسخه فایل و راه بازگشت نگه داشته شود در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: Permission و مالکیت در Linux باید با نیاز واقعی Service هماهنگ باشد؛ اجرای همه چیز با root مشکل را پنهان میکند و سطح ریسک را بالا میبرد؛ User و Group مناسب، حداقل Permission لازم و sudo کنترلشده روش قابل نگهداریتری است؛ بعد از تغییر، هم دسترسی مورد نیاز و هم عدم دسترسی ناخواسته بررسی شود برای کامل شدن تصویر این موضوع، در این درس Linux را از دید یک پشتیبان شبکه بررسی میکنیم؛ لازم نیست همه جزئیات سیستمعامل را حفظ کنی، اما باید ساختار فایلها، User و Permission، Serviceها، Network و Log را بشناسی؛ هدف این است که قبل از تغییر بدانی کدام Service و فایل درگیر است، از Log شواهد بگیری و تغییر را با حداقل دسترسی و امکان بازگشت انجام بدهی
تغییر Port بهتنهایی امنیت واقعی نیست
تغییر Port بهتنهایی امنیت واقعی نیست Port عدد منطقی داخل TCP یا UDP است که سرویس مقصد را مشخص میکند؛ برای تست سرویس باید IP مقصد، پروتکل و Port را با هم بدانیم Port فیزیکی Switch با Port نرمافزاری TCP/UDP یکی نیست راهنمای CISA و NIST بر چند پایه تکرارشونده تأکید دارد: استفاده از MFA برای حسابهای مهم، بهروزرسانی منظم، محدود کردن دسترسی مدیریتی، نگهداری Backup قابل بازیابی، ثبت رویدادها و آموزش مقابله با فیشینگ؛ در رخداد مشکوک، هدف اول حفظ شواهد و محدود کردن دامنه اثر است، نه انجام تغییرهای متعدد و بدون ثبت؛ حسابهای مدیریتی باید از حساب روزمره جدا باشند و سطح دسترسی فقط به اندازه نیاز کاری داده شود در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که Permission و مالکیت در Linux باید با نیاز واقعی Service هماهنگ باشد؛ اجرای همه چیز با root مشکل را پنهان میکند و سطح ریسک را بالا میبرد؛ User و Group مناسب، حداقل Permission لازم و sudo کنترلشده روش قابل نگهداریتری است؛ بعد از تغییر، هم دسترسی مورد نیاز و هم عدم دسترسی ناخواسته بررسی شود
فرض کن در Server Linux مشکلی گزارش شده و احتمال میدهی به SSH و مدیریت Remote مربوط باشد. قبل از تغییر، وضعیت فعلی را با systemctl، journalctl، ip، ss، df، free و ps بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- در SSH احراز هویت با Key میتواند جای Password را بگیرد؛ Private Key باید محرمانه بماند و Public Key روی حساب مقصد مجاز میشود
- SSH Host Key به Client کمک میکند Server قبلی را بشناسد. تغییر ناگهانی Fingerprint میتواند از نصب مجدد Server یا حمله واسط باشد و نباید بدون بررسی Warning را حذف کنی
- تغییر دادن تنظیمات مرتبط با SSH و مدیریت Remote قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با SSH و مدیریت Remote، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با systemctl، journalctl، ip، ss، df، free و ps وضعیت مرتبط با SSH و مدیریت Remote را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با SSH و مدیریت Remote بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- SSH ارتباط Shell رمزگذاریشده میدهد
- Public Key میتواند جای Password استفاده شود
- Root Login مستقیم بهتر است محدود شود
- Host Key هویت Server را تأیید میکند
- تغییر Port بهتنهایی امنیت واقعی نیست
- با root دائمی کار نکن و قبل از ویرایش فایل تنظیمات نسخه برگشت داشته باش
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
این نکته را با یک مثال توضیح بده: SSH ارتباط Shell رمزگذاریشده میدهد. بعد بگو در عمل چطور آن را بررسی میکنی.
SSH کانال رمزنگاریشده برای Shell و مدیریت Remote فراهم میکند؛ Key-based Authentication و محدودسازی دسترسی Admin امنیت را بهتر میکند
این نکته را با یک مثال توضیح بده: Public Key میتواند جای Password استفاده شود. بعد بگو در عمل چطور آن را بررسی میکنی.
در SSH احراز هویت با Key میتواند جای Password را بگیرد؛ Private Key باید محرمانه بماند و Public Key روی حساب مقصد مجاز میشود
این نکته را با یک مثال توضیح بده: Root Login مستقیم بهتر است محدود شود. بعد بگو در عمل چطور آن را بررسی میکنی.
محدود کردن SSH مستقیم برای root باعث میشود ورود با کاربر مشخص و سپس sudo قابلردیابیتر باشد؛ قبل از غیرفعالسازی مطمئن شو مسیر مدیریتی جایگزین کار میکند
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
