راهنمای جامع محافظت سرور در برابر باج‌افزار

تماس‌هایی که بعد از حملهٔ باج‌افزار می‌گیرم معمولاً یک جملهٔ مشترک دارند: «یک‌دفعه همه‌چیز رمز شد». ولی وقتی لاگ‌ها را با هم مرور می‌کنیم، تقریباً هیچ‌وقت یک‌دفعه نبوده است. مهاجم چند روز یا چند هفته پیش با یک رمز ضعیف RDP یا یک VPN آسیب‌پذیر وارد شده، AnyDesk نصب کرده، شبکه را با یک اسکنر گشته، رمز ادمین دامین را پیدا کرده، Shadow Copyها را پاک کرده، و تازه آخر کار، معمولاً شب جمعه یا تعطیلات، رمزگذاری را شروع کرده است. لحظهٔ رمزگذاری آخرین مرحلهٔ حمله است، نه اولین.

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

حمله چطور جلو می‌رود

جزئیات از گروهی به گروه دیگر فرق دارد، ولی بیشتر حمله‌های باج‌افزاری که به سازمان‌ها می‌شوند این مراحل را طی می‌کنند. ستون سوم مهم‌ترین ستون جدول است: ردی که هر مرحله روی سرور می‌گذارد.

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

ورود اولیه: درهایی که باید بسته شوند

در گزارش‌های رسمی، از جمله راهنمای مشترک CISA و همکارانش، سه در ورودی بارها تکرار می‌شوند: سرویس‌های دسترسی از راه دور در معرض اینترنت (به‌ویژه RDP)، آسیب‌پذیری‌های وصله‌نشده در تجهیزات لبه مثل VPN و فایروال، و فیشینگ. در شبکه‌های ایرانی که دیده‌ام، اولی به‌طور خاص رایج است: پورت 3389 یک سرور برای «دسترسی پیمانکار» یا «کار از خانه» روی اینترنت باز شده، و حساب Administrator با رمزی ساده.

• RDP را هرگز مستقیم روی اینترنت نگذارید. پشت VPN یا RD Gateway با احراز هویت چندمرحله‌ای. تغییر پورت به عدد دیگر محافظت نیست؛ اسکنرها همهٔ پورت‌ها را می‌گردند.
• سیاست قفل حساب. قفل موقت پس از چند تلاش ناموفق، حملهٔ حدس رمز را عملاً کند می‌کند.
• وصلهٔ تجهیزات لبه. VPN، فایروال و هر چیزی که از اینترنت دیده می‌شود، اولویت اول آپدیت است.
• حساب Administrator پیش‌فرض. نامش را عوض کنید یا غیرفعالش کنید، و رمز ادمین محلی هر سرور را یکتا نگه دارید (Windows LAPS برای همین است).

برای دیدن اینکه همین الان چه کسی دارد رمز حدس می‌زند، رویدادهای 4625 را بر اساس آی‌پی گروه‌بندی کنید (دستورش را در راهنمای پایش ویندوز سرور آورده‌ام). اگر روی سروری که «فقط از داخل استفاده می‌شود» آی‌پی‌های خارجی در فهرست دیدید، جایی پورتی باز است که نباید.

شکار ردپای مهاجم پیش از رمزگذاری

فاصلهٔ بین ورود و رمزگذاری، طلایی‌ترین زمان دفاع است. چند نشانه که در این مرحله می‌شود دید:

ابزارهای پرخطر. مهاجمان معمولاً ابزارهای مشروع را به کار می‌گیرند، چون آنتی‌ویروس جلویشان را نمی‌گیرد: AnyDesk یا ScreenConnect برای دسترسی پایدار، Advanced IP Scanner یا SoftPerfect Network Scanner برای شناسایی، PsExec برای اجرا روی سرورهای دیگر، rclone یا ابزارهای مشابه برای بیرون بردن داده، ngrok برای تونل. هیچ‌کدام بدافزار نیستند، ولی نصبشان روی یک سرور تولیدی بدون اطلاع شما، نشانهٔ جدی است. مقایسهٔ منظم فهرست نرم‌افزارهای نصب‌شده و سرویس‌ها با دفعهٔ قبل، این را نشان می‌دهد.

حساب‌ها و گروه‌ها. حساب تازه (4720)، عضو تازهٔ Administrators یا Domain Admins (4732، 4728)، حسابی که سال‌ها غیرفعال بود و ناگهان وارد شد.

سرویس و Task جدید. رویداد 7045 در لاگ System هر نصب سرویس را ثبت می‌کند؛ بسیاری از ابزارهای حرکت جانبی یک سرویس موقت می‌سازند. رویداد 4698 هم ساخت Scheduled Task را ثبت می‌کند (اگر ممیزی Other Object Access Events روشن باشد).

# New services installed in the last 7 days
Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045; StartTime=(Get-Date).AddDays(-7)} |
  ForEach-Object { $d = ([xml]$_.ToXml()).Event.EventData.Data
    [pscustomobject]@{ Time=$_.TimeCreated
      Name=($d | Where-Object Name -eq 'ServiceName').'#text'
      Path=($d | Where-Object Name -eq 'ImagePath').'#text' } }

تخریب ریکاوری: آخرین هشدار پیش از فاجعه

تقریباً همهٔ باج‌افزارهای جدی پیش از رمزگذاری سعی می‌کنند راه برگشت شما را ببندند. در چارچوب MITRE ATT&CK این تکنیک T1490 (Inhibit System Recovery) نام دارد. روی ویندوز معمولاً یعنی اجرای یکی از این ابزارها با پارامترهایی که Shadow Copyها یا کاتالوگ بکاپ را پاک می‌کنند یا ریکاوری بوت را خاموش می‌کنند:

برای دیدن این اجراها، ویندوز باید ایجاد پروسس را ثبت کند (رویداد 4688) و بهتر است خط فرمان کامل هم ثبت شود. این به‌طور پیش‌فرض خاموش است. روشن کردنش:

# Check
auditpol /get /subcategory:"Process Creation"
# Enable locally (in a domain, use GPO: Advanced Audit Policy > Detailed Tracking)
auditpol /set /subcategory:"Process Creation" /success:enable
# Include command line in 4688 (GPO: Administrative Templates > System > Audit Process Creation)
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f

با روشن شدن 4688 حجم لاگ امنیتی بیشتر می‌شود؛ اندازهٔ لاگ را هم متناسب بزرگ کنید. وضعیت فعلی Shadow Copyها را هم بدانید؛ اگر روی فایل‌سرور هیچ Shadow Copyی ندارید، این یکی از ارزان‌ترین لایه‌های برگشت است که از دست داده‌اید:

vssadmin list shadows
vssadmin list shadowstorage

توجه کنید Shadow Copy بکاپ نیست؛ روی همان دیسک است و مهاجمی که ادمین شده می‌تواند پاکش کند. ولی برای حمله‌هایی که در مرحلهٔ تخریب ریکاوری شکست می‌خورند، یا برای بازگرداندن سریع فایل‌هایی که کاربر اشتباهی پاک کرده، ارزشمند است.

تشخیص در لحظهٔ رمزگذاری

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

فایل طعمه (canary). فایل‌هایی با نام و محتوای معمولی (مثلاً یک فایل Word یا Excel) در جاهایی که باج‌افزار حتماً از آن‌ها رد می‌شود: ریشهٔ درایوهای داده، پوشه‌های اشتراکی، Public Documents. هیچ کاربر واقعی این فایل‌ها را تغییر نمی‌دهد؛ پس هر تغییر، تغییر نام یا حذفشان تقریباً بدون هشدار کاذب یعنی چیزی دارد فایل‌ها را رمز می‌کند. نکتهٔ مهم: نام فایل را طوری انتخاب کنید که در ترتیب الفبایی اول بیاید (باج‌افزارها اغلب پوشه را به ترتیب پیمایش می‌کنند) و فایل را مخفی نکنید، چون برخی باج‌افزارها فایل‌های مخفی را رد می‌کنند.

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

یادداشت باج. تقریباً همهٔ باج‌افزارها در هر پوشه یک فایل متنی یا HTML با نام‌هایی مثل README_DECRYPT، HOW_TO_RESTORE یا RECOVER-FILES می‌سازند. ظاهر شدن چنین فایلی در چند پوشه در چند دقیقه، نشانهٔ روشنی است.

علاوه بر این‌ها، خود آنتی‌ویروس هم گاهی چیزی می‌بیند ولی کسی نگاه نمی‌کند: در لاگ Microsoft-Windows-Windows Defender/Operational رویداد 1116 یعنی تهدیدی تشخیص داده شد و 1117 یعنی اقدامی رویش انجام شد. تشخیص یک ابزار سرقت رمز روی سرور، حتی اگر Defender پاکش کرده باشد، یعنی کسی آن را آنجا گذاشته است.

لینوکس و میزبان‌های مجازی‌سازی هم هدف‌اند

این باور که باج‌افزار فقط مشکل ویندوز است، دیگر درست نیست. گروه‌های باج‌افزاری نسخه‌های لینوکسی دارند که به‌ویژه میزبان‌های VMware ESXi و سرورهای فایل لینوکسی را هدف می‌گیرند؛ رمز کردن فایل‌های دیسک مجازی روی یک میزبان، همهٔ ماشین‌های مجازی آن را یکجا از کار می‌اندازد. روی سرورهای لینوکس همان منطق تشخیص برقرار است: فایل طعمه در جاهایی مثل /srv، /home و /var/www، پایش تغییر انبوه فایل‌ها، کاربر جدید و عضو جدید sudo، و ورود SSH از آی‌پی ناآشنا.

دربارهٔ میزبان‌های مجازی‌سازی دو توصیهٔ عملی دارم. اول، رابط مدیریتی ESXi و vCenter نباید از شبکهٔ کاربران، چه رسد به اینترنت، در دسترس باشد. دوم، پایش داخل ماشین‌های مجازی جای پایش خود میزبان را نمی‌گیرد. اگر میزبان رمز شود، سنسورهای داخل ماشین‌ها فقط یک چیز گزارش می‌کنند: سکوت. به همین دلیل هشدار «قطعی» همزمان چند سرور روی یک میزبان، خودش نشانه‌ای است که باید فوراً بررسی شود، و پایش منابع و دسترس‌پذیری که در راهنمای جامع پایش سرور توضیح داده‌ام، اینجا نقش امنیتی هم پیدا می‌کند.

Controlled Folder Access و لایه‌های پیشگیری

Microsoft Defender قابلیتی به نام Controlled Folder Access دارد که فقط برنامه‌های مورد اعتماد را اجازه می‌دهد در پوشه‌های محافظت‌شده بنویسند. روی سرورهایی با نقش مشخص و برنامه‌های محدود، لایهٔ خوبی است؛ روی فایل‌سرورهایی که اپلیکیشن‌های مختلف در آن‌ها می‌نویسند، اول در حالت Audit چند هفته اجرا کنید تا ببینید چه چیزهایی مسدود می‌شوند:

Set-MpPreference -EnableControlledFolderAccess AuditMode
# later, after reviewing events 1124 (audited) in the Defender Operational log:
Set-MpPreference -EnableControlledFolderAccess Enabled
Add-MpPreference -ControlledFolderAccessProtectedFolders 'D:\Shares'
Add-MpPreference -ControlledFolderAccessAllowedApplications 'D:\App\app.exe'

لایه‌های پیشگیری دیگری که در عمل بیشترین اثر را دیده‌ام:

بکاپ: تنها چیزی که واقعاً نجاتتان می‌دهد

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

قاعدهٔ قدیمی ۳-۲-۱ هنوز نقطهٔ شروع خوبی است: سه نسخه از داده، روی دو نوع رسانهٔ متفاوت، یک نسخه بیرون از محل. برای باج‌افزار یک شرط دیگر هم لازم است: دست‌کم یک نسخه باید آفلاین یا تغییرناپذیر باشد؛ یعنی از حساب‌های دامین قابل دسترسی و پاک کردن نباشد. اشتباه‌های رایجی که دیده‌ام:

• سرور بکاپ عضو دامین است و مهاجمی که Domain Admin شده، به آن هم دسترسی دارد.
• بکاپ روی NAS است که به‌صورت درایو شبکه روی سرور map شده؛ باج‌افزار آن را هم مثل بقیهٔ درایوها رمز می‌کند.
• بکاپ هر شب انجام می‌شود ولی هیچ‌وقت آزمون بازیابی نشده؛ روز حادثه معلوم می‌شود ماه‌هاست ناقص است.
• فقط داده بکاپ گرفته می‌شود، نه پیکربندی؛ بازسازی DC و سرورهای اپلیکیشن از صفر چند روز طول می‌کشد.

بکاپ پایگاه داده‌های SQL Server ظرافت‌های خودش را دارد (زنجیرهٔ log، آزمون RESTORE، نگه‌داری خارج از سرور)؛ اگر SQL Server دارید، DBMug دقیقاً برای پایش و نگه‌داری بکاپ آن ساخته شده است.

اگر اتفاق افتاد: ساعت اول

این بخش را پیش از حادثه بخوانید و با تیم مرور کنید، چون روز حادثه کسی وقت خواندن ندارد. کلیات آنچه در راهنماهای رسمی (از جمله CISA) آمده و تجربه هم تأییدش کرده:

1. جدا کنید، خاموش نکنید. کابل شبکه یا پورت سوییچ سرورهای آلوده را قطع کنید. خاموش کردن ناگهانی ممکن است شواهد حافظه و گاهی کلید رمزگذاری را از بین ببرد. اگر رمزگذاری در حال گسترش است و راه دیگری ندارید، اولویت با توقف گسترش است.
2. دامنه را بفهمید. کدام سرورها؟ کدام اشتراک‌ها؟ از کدام حساب؟ فهرست نشست‌های SMB روی فایل‌سرور معمولاً منبع را نشان می‌دهد.
3. بکاپ‌ها را حفظ کنید. اگر سرور بکاپ هنوز سالم است، فوراً از شبکه جدایش کنید.
4. رمزهای حساب‌های ممتاز را عوض کنید، از سیستمی که مطمئنید پاک است. حساب krbtgt را هم طبق راهنمای مایکروسافت دو بار و با فاصله ریست کنید.
5. شواهد را نگه دارید. Event Logها، یادداشت باج، نمونهٔ فایل رمزشده. برای گزارش به مراجع و برای بررسی بعدی لازم‌اند.
6. پیش از بازگردانی، در ورود را پیدا کنید. بازگرداندن بکاپ روی شبکه‌ای که مهاجم هنوز در آن است، یعنی حملهٔ دوم در هفتهٔ بعد.

دربارهٔ پرداخت باج: نهادهای رسمی مثل CISA و FBI پرداخت را توصیه نمی‌کنند، چون تضمینی برای گرفتن کلید یا پاک شدن دادهٔ دزدیده‌شده نیست و چرخهٔ حمله را تغذیه می‌کند. این تصمیم ابعاد حقوقی و کسب‌وکاری هم دارد که باید پیش از حادثه، نه وسط آن، دربارهٔ آن فکر شده باشد.

چک‌لیست محافظت سرور در برابر باج‌افزار

بخش تشخیص این چک‌لیست (فایل طعمه، تغییر انبوه، یادداشت باج، حذف Shadow Copy از روی 4688، پاک شدن لاگ و تشخیص‌های Defender) همان کاری است که محافظ باج‌افزار ServerMug انجام می‌دهد و نتیجه را با پیامک فوری خبر می‌دهد؛ جزئیاتش در محافظ باج‌افزار: فایل طعمه و تغییر انبوه آمده است. این جایگزین آنتی‌ویروس یا EDR نیست و فایل رمزشده را برنمی‌گرداند؛ کارش این است که در دقیقهٔ اول، نه صبح روز بعد، کسی خبردار شود. برای اینکه این پیامک در ساعت سکوت هم برسد و اگر نفر اول جواب نداد به نفر دوم برود، تنظیم مخاطبان و ارجاع را ببینید.

اگر از این راهنما فقط یک کار انجام می‌دهید، این باشد: همین هفته بررسی کنید آیا مهاجمی که رمز Domain Admin را دارد، می‌تواند بکاپ‌هایتان را پاک کند یا نه. اگر جواب «بله» است، بقیهٔ کارها می‌توانند صبر کنند.

منابع و مطالعهٔ بیشتر

• راهنمای باج‌افزار CISA و همکاران — چک‌لیست پیشگیری و پاسخ که نهادهای امنیتی آمریکا مشترکاً منتشر کرده‌اند.
• NIST IR 8374: نیم‌رخ مدیریت ریسک باج‌افزار — نگاشت اقدام‌های ضدباج‌افزار به چارچوب امنیت سایبری NIST.
• MITRE ATT&CK T1490: Inhibit System Recovery — روش‌های تخریب ریکاوری و منابع داده برای تشخیص آن‌ها.
• Controlled Folder Access در Microsoft Defender — راه‌اندازی، حالت Audit و رویدادهای مربوط.