راهنمای جامع امنیت سرور برای مدیران شبکه

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

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

اول ببینید چه چیزی از بیرون دیده می‌شود

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

• فهرست قوانین NAT و Port Forward فایروال لبه را دربیاورید و برای هر ردیف بپرسید: چه کسی خواسته، هنوز لازم است، و آیا محدود به آی‌پی مشخص است؟
• از یک ماشین بیرون از شبکه، آی‌پی‌های عمومی خودتان را اسکن کنید (فقط آی‌پی‌های متعلق به خودتان). نتیجه را با فهرست بالا تطبیق دهید.
• روی هر سرور، پورت‌های در حال شنود را ببینید. سرویسی که روی 0.0.0.0 گوش می‌دهد ولی فقط باید محلی باشد، اصلاح شود.

# Windows: listening TCP ports with process name
Get-NetTCPConnection -State Listen |
  Select-Object LocalAddress, LocalPort, @{n='Process';e={(Get-Process -Id $_.OwningProcess).ProcessName}} |
  Sort-Object LocalPort -Unique

# Linux
sudo ss -tulpn

RDP و SSH: دو دری که همیشه زیر حمله‌اند

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

• Network Level Authentication (NLA) روشن باشد تا احراز هویت پیش از ساخت نشست کامل انجام شود.
• دسترسی RDP در فایروال به آی‌پی‌های مشخص محدود شود.
• فقط حساب‌های لازم در گروه Remote Desktop Users باشند، نه همهٔ Domain Users.
• سیاست قفل حساب فعال باشد (پایین‌تر).

برای SSH روی لینوکس، سه تنظیم در /etc/ssh/sshd_config بیشترین اثر را دارند. پیش از ری‌استارت، با sshd -t درستی فایل را بسنجید و یک نشست باز نگه دارید تا اگر اشتباه کردید، خودتان را بیرون نیندازید:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowGroups ssh-users
MaxAuthTries 3

sudo sshd -t && sudo systemctl reload ssh     # "sshd" on RHEL family

ابزارهایی مثل fail2ban آی‌پی‌هایی را که تلاش ناموفق زیاد دارند موقتاً در فایروال می‌بندند و نویز لاگ را کم می‌کنند. ولی اگر ورود با رمز بسته باشد، fail2ban لایهٔ دوم است، نه اصلی.

حساب‌ها و دسترسی‌ها

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

چه کسی ادمین است؟

روی تک‌تک سرورها، اعضای گروه Administrators محلی را ببینید. تقریباً همیشه چیزهای غافلگیرکننده پیدا می‌شود: حساب پیمانکاری که دو سال پیش رفته، گروه «IT» که بیست عضو دارد، یا حتی Domain Users که برای حل یک مشکل دسترسی «موقتاً» اضافه شده.

# Local Administrators on this server
Get-LocalGroupMember -Group Administrators

# Domain-level privileged groups
Get-ADGroupMember -Identity 'Domain Admins' -Recursive | Select-Object Name, SamAccountName
Get-ADGroupMember -Identity 'Enterprise Admins' -Recursive | Select-Object Name

# Enabled accounts that have not logged on for 90 days
Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly |
  Where-Object Enabled | Select-Object Name, LastLogonDate

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

• حساب جدا برای مدیریت. مدیر شبکه با حساب عادی ایمیل می‌خواند و وب می‌گردد، و فقط برای کار مدیریتی با حساب ادمین وارد می‌شود. رمز ادمینی که روی ایستگاه کاری آلوده تایپ نشود، دزدیده نمی‌شود.
• Domain Admin فقط برای DC. برای مدیریت سرورهای عضو، گروهی جدا با دسترسی ادمین فقط روی همان سرورها بسازید.
• رمز ادمین محلی یکتا. اگر همهٔ سرورها یک رمز Administrator محلی دارند، مهاجم با پیدا کردن یکی به همه می‌رسد. Windows LAPS (در Windows Server 2019 و بعد با آپدیت‌های اخیر، داخلی است) رمز هر سرور را یکتا و دوره‌ای عوض می‌کند.
• حساب سرویس با کمترین دسترسی. سرویسی که با حساب Domain Admin اجرا می‌شود، رمزش روی هر سروری که آن سرویس دارد قابل استخراج است. از gMSA یا حساب با دسترسی محدود استفاده کنید.

سیاست رمز و قفل حساب

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

net accounts                               # local policy on this machine
Get-ADDefaultDomainPasswordPolicy          # domain policy
Search-ADAccount -LockedOut | Select-Object Name, LastLogonDate

سخت‌سازی سیستم‌عامل

سخت‌سازی یعنی خاموش کردن چیزهایی که لازم نیستند و سفت کردن تنظیماتی که پیش‌فرضشان برای سازگاری است نه امنیت. منبع اصلی، CIS Benchmark برای هر نسخهٔ سیستم‌عامل و خط مبنای امنیتی مایکروسافت (Security Baselines) است. اجرای کامل این‌ها روی شبکهٔ موجود بدون آزمون، معمولاً چیزی را می‌شکند؛ پس با این موارد پراثر و کم‌خطر شروع کنید:

برای خاموش کردن SMBv1 روی سرور:

Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force
# Windows Server: remove the feature entirely
Uninstall-WindowsFeature FS-SMB1

پیش از این کار مطمئن شوید دستگاه قدیمی (مثلاً یک اسکنر یا NAS خیلی قدیمی) به SMBv1 وابسته نیست. اگر هست، آن دستگاه مشکل امنیتی است، نه SMBv1 خاموش.

وصله: بی‌جذاب‌ترین و مؤثرترین کنترل

کاتالوگ آسیب‌پذیری‌هایی که CISA تأیید کرده واقعاً مورد سوءاستفاده قرار گرفته‌اند (KEV)، هر هفته بزرگ‌تر می‌شود و بخش بزرگی از آن مربوط به محصولات مایکروسافت، VPNها و تجهیزات لبه است. سروری که آپدیت نمی‌گیرد، دیر یا زود یکی از این‌ها را دارد. آپدیت امنیتی را در چرخهٔ منظم ماهانه نصب کنید، تجهیزات لبه را در اولویت بگذارید، و مهم‌تر از همه، پایش کنید که آپدیت‌ها واقعاً نصب شده‌اند و سرور ریبوت شده است. «فکر می‌کردیم آپدیت خودکار روشن است» جملهٔ تکراری گزارش‌های حادثه است. سرورهایی که دیگر آپدیت امنیتی نمی‌گیرند (مثل Windows Server 2012 R2) را یا ارتقا دهید، یا دست‌کم در شبکهٔ جدا و با دسترسی محدود نگه دارید.

پایش امنیتی: کنترل‌هایی که بی‌صدا خراب می‌شوند

هر کنترلی که بالا گفتم، روزی بی‌آنکه کسی بفهمد خراب می‌شود: فایروالی که برای عیب‌یابی خاموش شد، ادمینی که برای نصب اضافه شد، آنتی‌ویروسی که امضایش دو هفته است به‌روز نشده. پایش امنیتی دو بخش دارد: پایش وضعیت کنترل‌ها و پایش رویدادهایی که نشانهٔ حمله‌اند. سیاست ممیزی و جزئیات Event Log را در راهنمای پایش ویندوز سرور و معادل لینوکسی‌اش را در راهنمای پایش سرور لینوکس نوشته‌ام؛ اینجا فهرست اولویت‌دار رویدادها:

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

یک نفوذ معمولی و جاهایی که می‌شد متوقفش کرد

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

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

حالا نقطه‌های توقف را بشماریم:

1. بازبینی فهرست NAT پورت 3389 را پیدا می‌کرد.
2. سیاست قفل حساب، حدس رمز را عملاً کند می‌کرد.
3. هشدار روی تعداد بالای 4625 از یک آی‌پی، ساعت‌ها پیش از ورود موفق کسی را خبر می‌کرد.
4. حذف حساب‌های محلی بی‌صاحب، هدف حمله را از بین می‌برد.
5. هشدار «نرم‌افزار دسترسی از راه دور نصب شد» روز پنجشنبه زنگ می‌زد.
6. جدا بودن حساب ادمین دامین از کار روی سرورهای عضو، رمز را در دسترس نمی‌گذاشت.
7. هشدار «ادمین جدید» یا «سرویس جدید» روی سرورهای دیگر، گسترش را نشان می‌داد.
8. ثبت 4688 و هشدار روی حذف Shadow Copy، دقیقه‌ها پیش از رمزگذاری خبر می‌داد.

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

سرورهای لینوکس: فراتر از SSH

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

• فقط بسته‌های لازم. apt list --installed یا dnf list installed را مرور کنید؛ کامپایلر، ابزارهای شبکه و سرویس‌هایی که روی سرور تولیدی لازم نیستند، حذف شوند.
• سرویس‌های در حال شنود. هر سطر ss -tulpn باید دلیل داشته باشد. پایگاه داده‌ای که روی 0.0.0.0 گوش می‌دهد در حالی که فقط اپلیکیشن محلی به آن وصل می‌شود، باید به 127.0.0.1 محدود شود.
• sudo محدود. به‌جای ALL=(ALL) ALL برای همه، دسترسی را به دستورهای لازم محدود کنید و فایل‌های /etc/sudoers.d/ را بازبینی کنید.
• SELinux و AppArmor را خاموش نکنید. رایج‌ترین «راه‌حل» مشکل دسترسی در اینترنت، setenforce 0 است. به‌جایش لاگ را بخوانید (ausearch -m avc) و سیاست را درست کنید.
• کلیدهای SSH را بازبینی کنید. فایل ~/.ssh/authorized_keys هر کاربر، به‌ویژه root، فهرست کسانی است که بی‌رمز وارد می‌شوند. کلید کسی که از شرکت رفته، همان حساب فعال اوست.

# All authorized_keys files and how many keys each has
sudo find / -xdev -name authorized_keys -exec sh -c 'echo "$(wc -l < "$1") $1"' _ {} \;

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

امنیت خود ابزارهای مدیریت و پایش

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

• آیا روی سرورها پورت ورودی باز می‌کند؟ ابزاری که فقط ارتباط خروجی دارد، سطح حمله اضافه نمی‌کند.
• آیا از کنسول مرکزی می‌شود روی سرورها دستور اجرا کرد؟ اگر بله، امنیت آن کنسول هم‌تراز امنیت Domain Admin است.
• حسابی که با آن اجرا می‌شود چه دسترسی‌ای دارد، و رمز یا کلیدش کجا نگه‌داری می‌شود؟
• به‌روزرسانی‌هایش چطور تأیید می‌شوند؟ به‌روزرسانی امضانشده یعنی مسیر توزیع بدافزار.

این سؤال‌ها را هنگام طراحی سنسور ServerMug از خودمان پرسیدیم و جواب‌هایمان (ارتباط فقط خروجی، بدون اجرای دستور از راه دور، به‌روزرسانی امضاشده) را در امنیت سنسور و داده‌ها نوشته‌ایم. از هر ابزار دیگری هم همین سؤال‌ها را بپرسید.

برنامهٔ سی‌روزه

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

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

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

• CIS Critical Security Controls — فهرست اولویت‌دار کنترل‌های امنیتی با گروه‌بندی برای سازمان‌های کوچک تا بزرگ.
• خط مبنای امنیتی ویندوز (Microsoft Learn) — تنظیمات پیشنهادی مایکروسافت و ابزار اعمال آن‌ها.
• کاتالوگ آسیب‌پذیری‌های مورد سوءاستفاده (CISA KEV) — آسیب‌پذیری‌هایی که واقعاً در حمله‌ها استفاده شده‌اند؛ برای اولویت‌بندی وصله.
• مستندات auditpol — بررسی و تنظیم سیاست ممیزی پیشرفتهٔ ویندوز از خط فرمان.