راهنمای جامع به‌روزرسانی و آنتی‌ویروس سرورها

اگر از مدیران شبکه بپرسید سرورهایشان آپدیت‌اند یا نه، تقریباً همه می‌گویند «بله، آپدیت خودکار روشن است». اگر بپرسید آخرین آپدیت هر سرور کِی نصب شده، جواب معمولاً سکوت است. بارها پیش آمده که در نگاه اول به یک شبکه، سروری پیدا کرده‌ام که یک سال آپدیت نگرفته بود؛ نه چون کسی تصمیم گرفته بود، بلکه چون سرویس Windows Update روی آن خراب بود یا یک GPO قدیمی آن را به WSUSی وصل کرده بود که دیگر وجود نداشت.

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

چرا وصله هنوز مهم‌ترین کنترل امنیتی است

بخش بزرگی از نفوذهایی که در گزارش‌های رسمی آمده، از آسیب‌پذیری‌هایی است که وصله‌شان ماه‌ها پیش منتشر شده بود. CISA فهرستی به نام کاتالوگ KEV نگه می‌دارد که فقط آسیب‌پذیری‌هایی را در بر دارد که شواهد سوءاستفادهٔ واقعی از آن‌ها هست، و نگاهی به آن نشان می‌دهد محصولات رایج در شبکه‌های ما (ویندوز، Exchange، VPNها، فایروال‌ها) مرتب در آن تکرار می‌شوند. استراتژی وصله لازم نیست پیچیده باشد؛ لازم است منظم باشد و نتیجه‌اش پایش شود.

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

چرخهٔ ماهانهٔ وصلهٔ ویندوز

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

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

دیدن وضعیت واقعی آپدیت روی ویندوز

اولین قدم این است که برای هر سرور بدانید آخرین آپدیت کِی نصب شده و چه چیزی معوق است. Get-HotFix سریع است ولی فقط بخشی از به‌روزرسانی‌ها را نشان می‌دهد. روش کامل‌تر، پرسیدن از خود Windows Update Agent است:

# Last installed updates (quick view)
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5

# Pending updates according to Windows Update Agent
$session  = New-Object -ComObject Microsoft.Update.Session
$searcher = $session.CreateUpdateSearcher()
$result   = $searcher.Search("IsInstalled=0 and Type='Software' and IsHidden=0")
$result.Updates | Select-Object Title, MsrcSeverity, @{n='KB';e={$_.KBArticleIDs -join ','}}

# Where does this server get updates from? (WSUS or Microsoft)
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' -ErrorAction SilentlyContinue |
  Select-Object WUServer, WUStatusServer
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU' -ErrorAction SilentlyContinue |
  Select-Object UseWUServer, NoAutoUpdate, AUOptions

دستور سوم مهم‌تر از آن است که به نظر می‌رسد. سروری که WUServer آن به WSUSی اشاره می‌کند که سال‌هاست خاموش شده، هرگز آپدیت نمی‌گیرد و هیچ خطای آشکاری هم نمی‌دهد. اگر Windows Update خراب است، لاگش را با Get-WindowsUpdateLog (که فایل متنی روی Desktop می‌سازد) بخوانید.

WSUS یا مستقیم از مایکروسافت؟

WSUS به شما اجازه می‌دهد آپدیت‌ها را یک بار دانلود و بین سرورها پخش کنید و تصمیم بگیرید چه چیزی کِی نصب شود. برای شبکه‌هایی با پهنای باند بین‌المللی محدود یا با تعداد زیاد سرور، هنوز ارزشمند است. ولی خودش نگه‌داری می‌خواهد: پایگاه دادهٔ WSUS بدون پاک‌سازی منظم (Server Cleanup Wizard) کند و بزرگ می‌شود، و اگر کسی آپدیت‌ها را تأیید (approve) نکند، سرورها هیچ‌چیز نمی‌گیرند. مایکروسافت هم WSUS را در فهرست قابلیت‌های منسوخ (deprecated) گذاشته است؛ هنوز کار می‌کند و پشتیبانی می‌شود، ولی توسعهٔ تازه‌ای نمی‌گیرد. اگر WSUS دارید، دست‌کم ماهی یک بار بررسی کنید که سرورها واقعاً به آن گزارش می‌دهند.

ریبوت: نیمهٔ فراموش‌شدهٔ وصله

بیشتر آپدیت‌های ویندوز تا ریبوت اثر کامل ندارند. سروری که آپدیت را «نصب» کرده و ریبوت نشده، در عمل هنوز آسیب‌پذیر است. سرورهایی که «نباید ریبوت شوند» دقیقاً همان‌هایی‌اند که ماه‌ها در این وضعیت می‌مانند. روش بررسی ریبوت معوق از رجیستری را در راهنمای پایش ویندوز سرور آورده‌ام؛ اینجا فقط تأکید می‌کنم که ریبوت معوق باید مثل آپدیت معوق پایش شود. برای سرورهایی که واقعاً نمی‌توانند پایین بیایند، راه درست کلاستر یا افزونگی است، نه نصب نکردن آپدیت.

وصلهٔ لینوکس

در لینوکس مدیر بستهٔ توزیع همه‌چیز را آپدیت می‌کند: کرنل، کتابخانه‌ها، و نرم‌افزارهایی مثل nginx و OpenSSH. خبر خوب این است که نصب خودکار آپدیت‌های امنیتی ساده و امن است:

# Debian / Ubuntu
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades
tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log

# RHEL / Rocky / Alma
sudo dnf install dnf-automatic
# in /etc/dnf/automatic.conf:  upgrade_type = security   and   apply_updates = yes
sudo systemctl enable --now dnf-automatic.timer
dnf updateinfo list --security

دو دام رایج: اول، نرم‌افزارهایی که بیرون از مدیر بسته نصب شده‌اند (فایل باینری دانلودی، نصب از سورس، کانتینرهای Docker) با هیچ‌کدام از این‌ها آپدیت نمی‌شوند. image کانتینری که یک سال پیش ساخته شده، کتابخانه‌های یک سال پیش را دارد. دوم، آپدیت کرنل تا ریبوت اثر ندارد؛ uname -r را با نسخهٔ نصب‌شده مقایسه کنید. جزئیات بیشتر پایش لینوکس در راهنمای پایش سرور لینوکس آمده است.

آنچه Windows Update و apt آپدیت نمی‌کنند

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

• نرم‌افزارهای جانبی روی ویندوز سرور. Java Runtime، 7-Zip، Notepad++، مرورگرها، کلاینت‌های VPN، ابزارهای مدیریتی دانلودی. هر کدام آسیب‌پذیری‌های خودشان را دارند و Windows Update سراغشان نمی‌رود. ساده‌ترین قاعده: آنچه روی سرور لازم نیست، نصب نباشد.
• محصولات سرور مایکروسافت با چرخهٔ جدا. SQL Server (Cumulative Update و Security Update جدا)، Exchange (Security Update و Cumulative Update که اغلب باید دستی نصب شوند) و SharePoint. سرور Exchange وصله‌نشده در سال‌های اخیر یکی از پرسوءاستفاده‌ترین درهای ورود بوده است.
• میان‌افزار و firmware. BIOS و firmware کنترلر RAID و کارت شبکه، و به‌ویژه رابط‌های مدیریت از راه دور مثل iLO و iDRAC که آسیب‌پذیری‌هایشان جدی است.
• hypervisor. VMware ESXi و vCenter وصلهٔ جدا دارند و چون «زیر» همهٔ سرورها هستند، آسیب‌پذیری‌شان همه را در خطر می‌گذارد.
• تجهیزات لبه. فایروال، VPN و روتر. این‌ها اولویت اول‌اند چون مستقیم از اینترنت دیده می‌شوند.

برای دیدن نرم‌افزارهای نصب‌شده روی یک ویندوز سرور بدون استفاده از کلاس کند و پرعارضهٔ Win32_Product (که هنگام پرس‌وجو بسته‌های MSI را بازبینی و گاهی تعمیر می‌کند)، از رجیستری بخوانید:

$paths = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
         'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
Get-ItemProperty $paths -ErrorAction SilentlyContinue |
  Where-Object DisplayName |
  Select-Object DisplayName, DisplayVersion, Publisher, InstallDate |
  Sort-Object DisplayName

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

وقتی آپدیت چیزی را می‌شکند

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

• snapshot یا بکاپ پیش از آپدیت روی ماشین‌های مجازی مهم. snapshot را بعد از چند روز پاک کنید؛ snapshot ماندگار خودش مشکل کارایی و فضا می‌سازد.
• گروه آزمایشی، همان‌طور که بالا گفتم.
• دانستن راه برگشت. آپدیت تجمعی ویندوز را می‌شود با wusa /uninstall /kb:NNNNNNN یا از Settings حذف کرد؛ در لینوکس dnf history undo یا نصب نسخهٔ قبلی بسته با apt.
• بررسی پس از ریبوت. مهم‌ترین قدم: آیا سرویس‌های اصلی بالا آمده‌اند؟ بیشتر «خرابی‌های آپدیت» که دیده‌ام در واقع سرویسی بود که بعد از ریبوت شروع نشد و کسی تا صبح نفهمید.

آنتی‌ویروس روی سرور: Defender یا محصول دیگر

از Windows Server 2016 به بعد، Microsoft Defender Antivirus به‌طور پیش‌فرض نصب و فعال است. برای بسیاری از سازمان‌ها، Defender روشن با امضای تازه از یک آنتی‌ویروس دیگرِ نیمه‌پیکربندی‌شده بهتر است. اگر محصول دیگری (ESET، Kaspersky، Sophos، Trend Micro و…) دارید، این نکته را بدانید: برخلاف ویندوز ۱۰ و ۱۱، روی ویندوز سرور Defender با نصب آنتی‌ویروس دیگر خودبه‌خود کنار نمی‌رود. باید یا آن را حذف کنید یا در حالت Passive بگذارید، وگرنه دو موتور اسکن بلادرنگ با هم تداخل می‌کنند و کارایی و پایداری را پایین می‌آورند.

# Defender status
Get-MpComputerStatus | Select-Object AMRunningMode, AMServiceEnabled, RealTimeProtectionEnabled,
  AntivirusSignatureVersion, AntivirusSignatureLastUpdated, AntivirusSignatureAge, QuickScanAge

# Update signatures now
Update-MpSignature

# Recent detections
Get-MpThreatDetection | Select-Object InitialDetectionTime, ThreatID, ActionSuccess, Resources -First 10

مقدار AMRunningMode می‌گوید Defender در چه حالتی است: Normal (فعال)، Passive Mode (کنار محصول دیگر، بدون حفاظت بلادرنگ) یا حالت‌های دیگر. اگر این مقدار Normal نیست و محصول دیگری هم نصب نیست، سرور بی‌محافظ است.

امضا در شبکه‌های بدون اینترنت یا با اینترنت محدود

در بسیاری از شبکه‌های ایرانی، سرورها یا اصلاً به اینترنت دسترسی ندارند یا دسترسی‌شان به سرویس‌های به‌روزرسانی ناپایدار است. نتیجه، امضایی است که هفته‌ها کهنه می‌ماند و کسی متوجه نمی‌شود. Defender برای این وضعیت چند راه دارد: گرفتن امضا از WSUS، یا از یک پوشهٔ اشتراکی که یک ماشین متصل به اینترنت هر روز بستهٔ امضای تازه را در آن می‌گذارد. ترتیب منبع‌ها را با SignatureFallbackOrder تعیین می‌کنید:

# Try a UNC share first, then WSUS, then Microsoft Update
Set-MpPreference -SignatureDefinitionUpdateFileSharesSources '\\fileserver\DefenderUpdates'
Set-MpPreference -SignatureFallbackOrder 'FileShares|WindowsServerUpdateService|MicrosoftUpdateServer'
Set-MpPreference -SignatureUpdateInterval 4      # hours between checks
Get-MpPreference | Select-Object SignatureFallbackOrder, SignatureDefinitionUpdateFileSharesSources

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

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

مورد استثناها را جدی بگیرید. استثنا لازم است؛ آنتی‌ویروسی که فایل‌های پایگاه دادهٔ SQL Server یا پوشهٔ Exchange را اسکن کند، کارایی را به‌شدت پایین می‌آورد و گاهی خرابی می‌سازد. ولی استثنای بی‌حساب (مثلاً کل درایو D یا پسوند .exe) حفره است. فهرست فعلی:

Get-MpPreference | Select-Object ExclusionPath, ExclusionExtension, ExclusionProcess

مایکروسافت برای SQL Server فهرست رسمی استثناهای لازم را منتشر کرده (فایل‌های داده و log، پوشهٔ بکاپ، پروسس sqlservr.exe در برخی سناریوها). از همان فهرست استفاده کنید، نه از «کل درایو داده».

لینوکس آنتی‌ویروس لازم دارد؟

جواب کوتاه: بستگی به نقش دارد. سرور لینوکسی که فایل‌هایی را میزبانی می‌کند که کاربران ویندوزی باز می‌کنند (Samba، سرور ایمیل، آپلود وب)، باید آن فایل‌ها را اسکن کند؛ ClamAV رایج‌ترین انتخاب رایگان است. برای تشخیص نفوذ به خود سرور لینوکس، آنتی‌ویروس مبتنی بر امضا کمک زیادی نمی‌کند؛ EDRهای تجاری لینوکسی یا ترکیبی از پایش رویدادها (ورود SSH، کاربر جدید، sudo) مؤثرترند.

sudo systemctl status clamav-freshclam     # signature updater (Debian/Ubuntu unit name)
sudo freshclam                             # manual signature update
clamscan -ri /srv/samba/share              # recursive scan, only infected files listed

آنتی‌ویروس و باج‌افزار

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

اشتباه‌های رایج

• «آپدیت خودکار روشن است» به‌جای اندازه‌گیری. تعداد آپدیت معوق و تاریخ آخرین نصب را برای هر سرور بدانید.
• GPO قدیمی WSUS. سرورهایی که به WSUS ناموجود اشاره می‌کنند، بی‌صدا آپدیت نمی‌گیرند.
• نصب بدون ریبوت. «آپدیت نصب شده» در حالی که فایل‌های آسیب‌پذیر هنوز در حال اجرا هستند.
• دو آنتی‌ویروس با هم. Defender و محصول دیگر هر دو فعال روی ویندوز سرور.
• استثناهای بی‌حساب. کل درایو داده استثنا شده چون «کند بود».
• سرورهای پایان‌پشتیبانی. Windows Server 2012 R2 که دیگر وصله نمی‌گیرد و در گزارش وصله «سبز» دیده می‌شود چون آپدیت تازه‌ای برایش نیست.

پایش وضعیت وصله و آنتی‌ویروس

همهٔ وضعیت‌های بالا را می‌شود با اسکریپت جمع کرد، ولی ارزش واقعی وقتی است که روی همهٔ سرورها، همیشه، و با هشدار پایش شوند. در ServerMug چک «به‌روزرسانی سیستم‌عامل» تعداد آپدیت معوق و امنیتی و تاریخ آخرین نصب را برای ویندوز (از Windows Update Agent) و لینوکس (apt و dnf) می‌دهد، کنار چک ریبوت معوق و چک آنتی‌ویروس (Defender با سن امضا و حفاظت بلادرنگ، و تشخیص محصولات رایج دیگر از روی سرویس‌هایشان). جزئیات هر چک در مرجع چک‌ها و شیوهٔ تنظیم آستانه‌هایشان در قانون‌های هشدار آمده است.

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

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

• NIST SP 800-40 Rev. 4: برنامه‌ریزی مدیریت وصله در سازمان — چارچوب رسمی برای تبدیل وصله از کار دستی به فرایند قابل اندازه‌گیری.
• Microsoft Defender Antivirus روی ویندوز سرور — نصب، حالت Passive و تفاوت‌های نسخهٔ سرور با کلاینت.
• آنتی‌ویروس و SQL Server — فهرست رسمی استثناهای لازم برای سرور پایگاه داده.
• آپدیت خودکار در Ubuntu Server — تنظیم unattended-upgrades و گزینه‌های آن.