سطح مطلب: عمومی//
سلامی گرم به دوستان، فعالین و علاقه‌مندان حوزه امنیت شبکه. اگر در حوزه تحلیل امنیت دستی بر آتش دارید که نیاز به مقدمه‌چینی نیست ولی در صورتی که بتازگی وارد این زمینه شده‌اید باید توضیح داده شود که در آنالیز امنیت و بطور کلی تحلیل امنیتی اتفاقاتی که در شبکه رخ می‌دهد، نیاز است تا بطور جزئی با عملکردهای شبکه‌ای، مِن جمله همین موضوعی که مورد بحث مقاله ما هم هست، آشنا بود تا بتوان با تکیه بر ریزترین علائم موجود، تحلیلی درست از حادثه رخ داده شده ارائه نمود. همانطور که میدانید یا با این یادآوری متوجه آن خواهید شد، یکی از ابتدایی‌ترین اقدامات برای نفوذ به شبکه و هک آن، اسکن کردن پورتهای باز هدف می‌باشد. در تحلیل لاگ‌های امنیتی بکرات با این موضوع مواجهه خواهید شد؛ بنابراین لازم است تا برای تحلیلی صحیح و همچنین اولویت بندی حادثه رخ داده شده، با مفاهیم اساسی اسکن پورت آشنا باشیم.
پورتهای شبکه برای سیستمی که به اینترنت متصل است به منزله نقاط ورودی آن محسوب می‌شوند. سرویسی که بر روی یک پورت، شنود می‌کند، این توانایی را دارد تا از سمت کلاینت دیتا را دریافت کرده، پردازش کند و متعاقبا آن را بسمت کلاینت برگرداند. در این میان کلاینت‌هایی هستند که خواسته یا ناخواسته آسیب پذیری‌های موجود بر روی سرور را اکسپلویت و از طریق ریموت به اطلاعات حساس دسترسی پیدا کرده و یا آن که کدهای آلودهای را بر روی سیستم هدف اجرا می‌کنند. این همان علتی است که بررسی تمام پورتهای یک سیستم را به منظور کشف نقاط ضعف و قوت، ضروری می‌کند. اسکن پورت معمولا در فاز ابتدایی یک تست نفوذ صورت می‌پذیرد تا توسط آن تمام نقاط ورودی یک سیستم شناسایی شده و وضعیت آنها مشخص شود. اسکن پورت با دو شیوه متفاوت بر روی پورتهای TCP و پورتهای UDP صورت می‌پذیرد.
همانطور که میدانید TCP یک پروتکل connection-oriented است. به این معنی که سیستم‌ها در صورت استفاده از پروتکل TCP باید قبل از ارسال هرگونه دیتا بسمت یکدیگر، کانکشنی مطمئن و پایدار بین خود ایجاد کنند؛ این فرآیند در اصطلاح عمومی به ” Three-way handshake ” معروف است. از آنجایی که این فرآیند در یک کانکشن پایدار و قوی با سرعت انجام می‌شود، منطقا انتظار می‌رود در مورد یک پورت باز TCP ، نتیجه اسکن در زمان کمتری حاصل شود. نحوه کار به این صورت است که اسکنر، پکت‌هایی را به مقصد هریک از پورتهای TCP ارسال می‌کند و منتظر پاسخ می‌ماند. این مدل اسکن ” SYN Scan ” نامیده می‌شود که در آن پکت‌های TCP SYN به هریک از پورتهای TCP مشخص شده برای اسکن، ارسال می‌شوند. اگر پورت مورد نظر با SYN+ ACK پاسخ دهد، یه عنوان یک پورت باز تلقی شده و RST Flag را بسمت ابزار اسکنر ما بر می‌گرداند. در این مدل اسکن، کانکشن کامل TCP بین مبداء و مقصد برقرار نخواهد شد. در اسکن TCP با وجود آنکه اجرای فرآیند three-way handshake ممکن‌ست باعث کندی شود، اما عدم وجود بازه زمانی time-out در مکانیزم اجرایی آن، باعث شده است تا این نوع اسکن نسبتا سریع و دقیق باشد .
با وجود آنکه سرویس‌های مبتنی بر پروتکل UDP به نسبت سرویس‌های مشابه در TCP از محبوبیت کمتری برخوردارند اما وجود یک سرویس آسیب پذیرِ UDP در شبکه به اندازه یک سرویس آسیب پذیرِ TCP می‌تواند خطرناک باشد.بنابراین شناسایی و کشف تمام پورتهای باز UDP نیز در بحث تست نفوذ بسیار مهم بوده و دارای ارزش امنیتی می‌باشد. در طرف دیگر ماجرا، UDP ، یک پروتکل connectionless است. در مورد ارتباطات UDP ، ترافیک‌ها بر این مبنا ارسال خواهند شد که از طرف دیگر ارتباط، انتظاری برای تائید و یا تکذیب دریافت ترافیک نمی‌رود. بنابراین در اینگونه اسکن‌ها قبل از آن که بنا بر بسته بودن یک پورت گذاشته شود، باید بازه time-out نسبتا طولانی را لحاظ کرد. پس از سپری شدن بازه زمانی time-out ، با وجود آنکه با قطعیت و بطور صد در صدی نمی‌توان گفت که پورت بسته است، اما با این وجود نتیجه حاصله مبنی بر بسته بودن پورت، معتبر فرض خواهد شد.
در مورد اسکن پورتهای UDP ، پورتهای باز و یا فیلترشده، بندرت پاسخی را برگردانند؛ در مورد پورتهای بسته نیز، آنها معمولا یک خطای ” icmp port unreachable ” در پاسخ برخواهند گرداند. اما مشکلی که وجود دارد اینست که بسیاری از host ها میزان جریان (rate) پیامهای ” icmp port unreachable ” را بطور پیش فرض محدود می‌کنند. به عنوان مثال لینوکس و سولاریس در این مورد سختگیری بیشتری دارند. مثلا کرنل لینوکس ۴٫۴٫۲
میزان جریان پیامهای از جنس ” destination unreachable ” را به یک پیام در ثانیه محدود کرده است. این موضوع با سرعتی که اسکن UDP در ذات خود دارد، تناقض ایجاد کرده و باعث مشکل و خطا در نتیجه اسکن خواهد شد. فرآیند port scanning (با nmap و یا ابزارهای دیگر) هم مانند نمونه‌های گفته شده است. Nmap با علم به این موضوع، این محدودیت را تشخیص داده و تا حدی که از لحاظ شبکه مقصد، میزان drop شدن پکت‌های بی هدف، جریان ترافیک محسوب نشود، سرعت اسکن را پایین می‌آورد. این کاهش سرعت، زمانی خود را نشان خواهد داد که بخواهیم ۶۵۵۵۶ پورت UDP را روی یک هاست از خانواده لینوکس اسکن کنیم که در اینصورت بیش از ۸۱ ساعت این اسکن بطول می‌انجامد. راههای مختلفی برای سرعت بخشی به اسکن UDP وجود دارد که از آن جمله می‌توان به اجرای اسکن‌های موازی از هاست‌های مبداء مختلف، اجرای اسکن فقط برای پورتهای معروف و شناخته شده، اجرای اسکن از پشت فایروال و استفاده از سوئیچ –host-timeout برای صرفنظر کردن از هاست‌های کُند، اشاره کرد.
یکبار دیگه مطالب بالا را بطور خلاصه مرور می‌کنیم:
TCP و UDP پروتکلهای متفاوتی نسبت به همدیگر هستند؛ در UDP شما باید به میزان بازه زمانی مشخص شده time-out، منتظر پاسخ اسکن بمانید اما در TCP ، پس از انجام فرآیند three-way handshake فورا نسبت به باز یا بسته بودن پورت، مطلع می‌شوید. اگر پورت بسته باشد، بلافاصله یک پکت با RST flag بشما بازخواهد گشت و شما می‌توانید سریعا اسکن پورت بعدی را آغاز نمایید. اما در مورد UDP ، nmap پکت‌های UDP را به هرکدام از پورتهای مشخص شده در فرمان اسکن، ارسال می‌کند. اگر مقصد با ” icmp port unreachable ” پاسخ دهد، nmap مطمئن خواهد شد که پورت مورد نظر بسته است؛ در غیر اینصورت، یعنی اگر پیام ” icmp port unreachable ” دریافت نشود، nmap درخواهد یافت که پورت مورد نظر یا باز است، یا توسط فایروالی فیلتر شده است و یا آنکه پکت در مسیر گم شده و یا از بین رفته است. در این صورت nmap بشما پاسخ ” open | filtered ” را بر خواهد گرداند.
مانا باشید
احسان امجدی / کارشناس و مدرس دوره‌های تحلیل امنیت
“اگر بر این باورید که با نقض قانون کپی رایت، وضعیتی بهتر در انتظارمان خواهد بود، بدون ذکر نام نویسنده و منبع، مجاز به انتشار مطالب هستید. “