ردپای نفوذ در لاگ‌ها؛ مانیتورینگ سرور و تشخیص ورود مشکوک

ساعت ۲:۱۴ بامداد، ورود ناموفق به SSH چند بار تکرار می‌شود. چند دقیقه بعد، یک ورود موفق از حسابی ثبت شده که معمولاً فقط در ساعات اداری استفاده می‌شود. CPU طبیعی است؛ وب‌سایت هم پاسخ می‌دهد. بااین‌حال ممکن است مسئله‌ای جدی در جریان باشد. مانیتورینگ سرور فقط برای فهمیدن کندی و قطعی نیست؛ لاگ‌های ورود و تغییرات غیرعادی نیز می‌توانند نخستین نشانه یک حادثه امنیتی باشند.

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

چرا سالم‌بودن سرویس، به معنای امن‌بودن سرور نیست؟

یک فرایند ناخواسته ممکن است برای مدت طولانی منابع کمی مصرف کند. دسترسی غیرمجاز نیز می‌تواند بدون توقف Nginx یا دیتابیس رخ دهد. به همین دلیل باید وضعیت سرویس‌ها را از وضعیت کنترل دسترسی جدا کرد. مانیتورینگ امنیتی مجموعه‌ای از رویدادهای ورود، تغییر مجوز، اجرای فرایندهای حساس و تغییر فایل‌های مهم را با خط مبنای رفتار عادی مقایسه می‌کند.

البته هر تغییر غیرعادی نشانه نفوذ نیست. مدیر سیستم ممکن است برای رفع مشکل اضطراری، نیمه‌شب وارد سرور شود. رویداد باید زمینه داشته باشد: حساب، زمان، روش احراز هویت، تغییرات ثبت‌شده و مجوز کار. تبدیل هر ورود خارج از ساعت اداری به «نفوذ قطعی» نه دقیق است و نه کمک‌کننده.

پنج گروه رویدادی که ارزش پایش دارند

رویداد	چه چیزی را بررسی کنیم؟	تفسیر محتاطانه
ورودهای ناموفق SSH	افزایش دفعات، حساب هدف و بازه زمانی	ممکن است ربات عمومی اینترنت باشد، نه نفوذ موفق
ورود موفق غیرمنتظره	حساب، کلید یا روش ورود، زمان و تغییرات بعدی	بدون زمینه نمی‌توان آن را غیرمجاز دانست
تغییر دسترسی sudo	فرمان انجام‌شده، کاربر و علت تغییر	می‌تواند بخشی از عملیات مجاز باشد
تغییر حساب یا کلید SSH	اضافه‌شدن کاربر، تغییر authorized_keys	نیازمند تطبیق با درخواست تغییر مجاز
توقف یا پاک‌شدن غیرعادی لاگ	وضعیت journald، syslog و فاصله رویدادها	همیشه حمله نیست، ممکن است تنظیم لاگ باشد

برای هر رویداد باید مشخص باشد آیا سازمان آن را صرفاً ثبت می‌کند، هشدار می‌دهد یا فرایند رسیدگی امنیتی را آغاز می‌کند. راهنمای ثبت رویدادهای امنیتی OWASP بر ثبت اطلاعات کافی برای تحلیل و در عین حال محافظت از داده‌های محرمانه تأکید می‌کند.

از کجا لاگ ورود SSH را در لینوکس ببینیم؟

محل ذخیره رویدادها به توزیع، نسخه و پیکربندی لاگ بستگی دارد. روی سیستم‌های مبتنی بر systemd می‌توان وضعیت سرویس SSH را از Journal مشاهده کرد. در برخی توزیع‌ها نیز فایل‌هایی مثل /var/log/auth.log یا /var/log/secure حاوی رخدادهای ورود هستند؛ اما وجود آن‌ها در همه سیستم‌ها تضمین‌شده نیست.

sudo journalctl -u ssh --since "1 hour ago" --no-pager
sudo journalctl -u sshd --since "1 hour ago" --no-pager
sudo last -n 10

نام سرویس در توزیع‌های مختلف ممکن است ssh یا sshd باشد. فرمان‌ها برای مشاهده‌اند و به‌تنهایی اقدامی برای جلوگیری از حمله انجام نمی‌دهند. گزارش خروجی می‌تواند نام کاربر و نشانی IP را داشته باشد؛ آن را در محیط عمومی یا کانال بدون کنترل دسترسی منتشر نکنید.

چرا شمارش ورود ناموفق به‌تنهایی کافی نیست؟

سرور متصل به اینترنت ممکن است مرتب هدف آزمون رمز عبور قرار بگیرد؛ این موضوع لزوماً به معنی موفقیت مهاجم نیست. ترکیب «تعداد تلاش‌های ناموفق»، «ورود موفق پس از آن»، «روش احراز هویت» و «تغییرات پس از ورود» تصویر دقیق‌تری می‌دهد. همچنین تغییر IP یا شبکه مدیران دورکار ممکن است تشخیص مبتنی بر موقعیت را به‌اشتباه فعال کند.

چه چیزی پس از ورود مشکوک مهم‌تر است؟

اگر یک حساب حساس در زمان غیرمعمول وارد شده است، بهتر است هم‌زمان چند نشانه بررسی شود: ایجاد حساب جدید، تغییر مجوزها، ویرایش کلیدهای SSH، اجرای دستورهای مدیریتی غیرمنتظره و ایجاد سرویس زمان‌بندی‌شده تازه. این کار به مجوز و ابزارهای مناسب نیاز دارد؛ مانیتور عمومی CPU و RAM به‌طور خودکار تاریخچه همه این تغییرات را ندارد.

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

چگونه میان تغییر مجاز و رخداد مشکوک تفاوت بگذاریم؟

یک خط مبنای ساده بسازید: چه کسانی دسترسی مدیریتی دارند، ورود آن‌ها معمولاً با کدام روش انجام می‌شود، چه سامانه‌ای تغییرات را ثبت می‌کند و در چه موقعیت‌هایی ورود اضطراری قابل انتظار است. در مرحله بعد، رویدادهای جدید را با این خط مبنا مقایسه کنید. هدف این نیست که هر رفتار متفاوتی مسدود شود؛ تفاوت‌ها باید بررسی و مستند شوند.

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

چه زمانی هشدار فوری بفرستیم؟

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

مانیتورینگ یکپارچگی فایل چه چیزی را آشکار می‌کند؟

برخی تغییرات مهم بدون افزایش محسوس مصرف CPU رخ می‌دهند: ویرایش فایل تنظیمات سرویس، تغییر مجوز پوشه وب یا اضافه‌شدن یک کلید SSH. File Integrity Monitoring با ثبت خط مبنای فایل‌های انتخاب‌شده و مقایسه تغییرات بعدی، به تشخیص این موارد کمک می‌کند. این کار باید برای فایل‌های حساس و با قوانین مشخص انجام شود؛ هشدار برای هر فایل کش یا لاگِ دائماً در حال تغییر، نویز زیادی تولید می‌کند.

اگر می‌خواهید این قابلیت را پیاده‌سازی کنید، مراقب باشید Hash گرفتن از فایل‌ها یا بررسی پیاپی مسیرهای بسیار بزرگ می‌تواند I/O ایجاد کند. همچنین «تغییر فایل» با «خرابکاری» برابر نیست؛ برای نتیجه‌گیری باید تغییر را با Deploy، تنظیمات مدیریتی و حساب اجراکننده تطبیق دهید.

حفاظت از لاگ امنیتی؛ اگر مهاجم به سرور دسترسی داشت چه می‌شود؟

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

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

نمونه سناریو: ده تلاش ناموفق و یک ورود موفق

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

1. زمان و شناسه رویدادها را ثبت کنید و از کپی‌کردن عمومی اطلاعات حساب خودداری کنید.
2. روش احراز هویت ورود موفق و مطابقت آن با کلیدهای ثبت‌شده سازمان را بررسی کنید.
3. با مسئول حساب یا سامانه مدیریت دسترسی، مجازبودن ورود را تطبیق دهید.
4. تغییرات حساس پس از ورود را از لاگ‌های مستقل، ممیزی و سوابق Deploy بررسی کنید.
5. اگر شواهد به دسترسی غیرمجاز اشاره دارند، مطابق برنامه واکنش سازمان، حساب و دسترسی‌ها را ایمن کنید؛ پیش از پاک‌کردن شواهد یا خاموش‌کردن سرور هماهنگی لازم را انجام دهید.
6. پس از رسیدگی، علت هشدار، نتیجه بررسی و اقدام اصلاحی را ثبت کنید.

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

نقش Fail2ban، MFA و محدودسازی SSH در کنار پایش چیست؟

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

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

چطور لاگ امنیتی را بدون کاهش سرعت سرور بررسی کنیم؟

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

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

آوازتک مانیتورینگ چه کمکی به بررسی لاگ و سلامت میزبان می‌کند؟

Avaztek Monitoring طبق مستندات رسمی محصول، امکانات جمع‌آوری متریک سرور، وضعیت سرویس‌ها و Log Explorer را ارائه می‌کند. در Log Explorer می‌توان رخدادهای جمع‌آوری‌شده را با فیلتر سطح، بازه زمانی و جست‌وجوی متن بررسی کرد. این قابلیت برای کنار هم قراردادن زمان یک رخداد مشکوک با وضعیت منابع یا اختلال سرویس مفید است.

میزان پوشش لاگ امنیتی به این بستگی دارد که منبع لاگ انتخاب شده، Agent به آن دسترسی مجاز داشته باشد و داده واقعاً وارد سامانه شود. وجود Log Explorer به معنی شناسایی خودکار نفوذ، تحلیل رفتار مهاجم یا جایگزینی سامانه تخصصی SIEM نیست. برای هشدار امنیتی باید منبع، قانون و مسیر رسیدگی را آگاهانه طراحی کرد.

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

پرسش‌های متداول درباره مانیتورینگ امنیت سرور

آیا تلاش ناموفق SSH یعنی سرور هک شده است؟

خیر. تلاش‌های ناموفق روی سرورهای متصل به اینترنت رایج‌اند. برای قضاوت درباره نفوذ باید ورود موفق، روش احراز هویت، تغییرات پس از ورود و سایر شواهد بررسی شوند.

کدام لاگ لینوکس برای بررسی ورود کاربران مهم است؟

بسته به توزیع و تنظیمات، Journal سرویس SSH و فایل‌هایی مثل auth.log یا secure می‌توانند مفید باشند. وجود مسیر ثابت در همه توزیع‌ها تضمین نیست؛ منبع واقعی را از پیکربندی سیستم پیدا کنید.

آیا مانیتورینگ سرور می‌تواند باج‌افزار را تشخیص دهد؟

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

چرا نباید تمام متن لاگ‌های امنیتی را برای همه نمایش دهیم؟

لاگ ممکن است شامل نشانی IP، شناسه حساب، اطلاعات عملیاتی یا داده مشتری باشد. مجوز مشاهده، محدودیت نگهداری و حذف داده حساس را پیش از انتقال یا نمایش تنظیم کنید.

آیا Avaztek Monitoring یک SIEM کامل است؟

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

در کنار پایش لاگ و کنترل دسترسی، آزمون بازیابی نسخه پشتیبان بخشی از آمادگی برای حادثه است. برای جلوگیری از گم‌شدن اعلان حساس میان پیام‌های تکراری نیز آموزش کاهش هشدار کاذب را ببینید.

برای شناخت شاخص‌های عملیاتی پایه پیش از افزودن لاگ امنیتی، راهنمای مانیتورینگ سرور را بخوانید.

جمع‌بندی: سلامت سرور را از روی ردپاهایش هم بخوانید

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