کنترل و محدود کردن پورت‌های شبکه؛ کاهش سطح حمله با سرویس‌های ضروری

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

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

چرا کنترل پورت‌ها مهم است؟

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

نمونه معروف، رخنه VTech Learning Lodge در سال ۲۰۱۵ بود. حمله از طریق وب‌سرویسی که روی اینترنت در دسترس بود و ضعف‌هایی مثل SQL Injection، نگهداری ضعیف رمزها و خطایابی ناامن داشت انجام شد. اصل ماجرا فقط یک آسیب‌پذیری نبود؛ سرویس منتشرشده درست کنترل، تست و محدود نشده بود.

اول Inventory سرویس‌ها، بعد بستن پورت‌ها

نمی‌شود چیزی را که نمی‌شناسیم امن کنیم. قبل از بستن پورت‌ها باید بدانیم روی هر سیستم چه سرویس‌هایی باز است، چرا باز است، مالک آن کیست و از کدام شبکه‌ها باید قابل دسترس باشد.

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

Default Deny را جدی بگیرید

روی فایروال میزبان، فایروال شبکه و ACLهای بین VLANها بهتر است اصل پیش‌فرض این باشد: همه چیز بسته است مگر چیزی که صریحا لازم است. این کار مخصوصا برای سرورهای منتشرشده روی اینترنت، سیستم‌های مدیریتی، دیتابیس‌ها و سرویس‌های داخلی حساس حیاتی است.

• دیتابیس نباید مستقیم از اینترنت قابل دسترس باشد.
• پنل مدیریت، SSH، RDP، WinRM و SNMP باید فقط از شبکه مدیریتی یا Jump Server مجاز باشند.
• سرویس‌های عمومی مثل وب باید فقط پورت‌های لازم را منتشر کنند.
• ارتباط بین سرورهای یک سرویس هم باید محدود و مستند باشد، نه کاملا آزاد.

سرورهای عمومی را از شبکه داخلی جدا کنید

سروری که از اینترنت قابل دسترس است نباید کنار Active Directory، فایل‌سرور داخلی یا دیتابیس‌های حساس در یک VLAN بی‌دفاع قرار بگیرد. طراحی درست این است که سرویس‌های عمومی در DMZ یا Zone جدا باشند و فقط مسیرهای لازم به داخل شبکه مجاز شود.

در محیط‌های کوچک هم همین اصل کاربرد دارد. اگر DMZ کامل ندارید، حداقل VLAN جدا، Ruleهای دقیق، لاگ کامل و محدودسازی دسترسی از اینترنت به سرویس‌های ضروری را پیاده کنید.

اسکن دوره‌ای و هشدار تغییرات

کنترل پورت‌ها یک کار یک‌باره نیست. امروز ممکن است همه چیز درست باشد، اما فردا یک نرم‌افزار نصب شود، یک سرویس Debug روشن بماند یا یک Rule موقت فراموش شود. برای همین باید اسکن دوره‌ای داشته باشید و تغییرات غیرمنتظره را ببینید.

• روی سرورها و تجهیزات حیاتی اسکن داخلی منظم انجام دهید.
• نتیجه اسکن را با Baseline مقایسه کنید.
• برای باز شدن پورت جدید روی سیستم حساس هشدار بسازید.
• پورت‌های اینترنتی را جداگانه و از بیرون شبکه بررسی کنید.

کنترل سرویس‌ها روی Endpoint

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

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

ابزارهای مفید

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

• Nmap و Masscan برای اسکن فنی و سریع؛
• Nessus، Qualys، Rapid7 InsightVM و Greenbone/OpenVAS برای ارزیابی آسیب‌پذیری؛
• فایروال، SIEM و EDR برای دیدن ارتباطات واقعی و تغییرات مشکوک؛
• CMDB یا حتی یک Inventory ساده برای ثبت مالکیت سرویس‌ها.

چک‌لیست سریع کنترل پورت‌ها

• آیا برای هر سرور و سیستم حساس لیست پورت‌های مجاز دارید؟
• آیا پورت‌های باز با نیاز واقعی سرویس تطبیق داده شده‌اند؟
• آیا سرویس‌های مدیریتی فقط از شبکه مدیریتی قابل دسترس هستند؟
• آیا سرورهای عمومی از شبکه داخلی جدا شده‌اند؟
• آیا باز شدن پورت جدید روی سیستم حساس هشدار تولید می‌کند؟
• آیا Ruleهای موقت تاریخ انقضا و مالک مشخص دارند؟

جمع‌بندی

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