چرا دستور netstat منسوخ شده است؟ دستور ss در لینوکس به خاطر قابلیت های امنیتی و سرعت بالا، جایگزین netstat در لینوکس شده است و در این مقاله، به نحوه ی برسی اتصالات و نقش دستور ss در incident response و Threat Hunting پرداخته می شود.

دستور netstat از فایل سیستم /proc اطلاعات رو می خواند اما معماری دستور ss به این گونه است که برخلاف netstat برای دریافت اطلاعات از مکانیزم (Netlink Socket API) استفاده می کند. به همین خاطر دقت و سرعت بسیار بالایی دارد.

دستورات پایه ی ss

کاربرد دستور ss در Incident Response

پیدا کردن اتصالات مشکوک (Backdoor و Bind Shell) با دستور "ss"، دو نمونه دستور پر کاربرد:

ss -lnt

ss -tulpn

شناسایی Reverse Shell مخفی شده در ترافیک وب

شرح سناریو: بسیاری از بدافزارها و نفوذگران برای پنهان ماندن از دید فایروال‌ها و مدیران سیستم، از پورت‌های استاندارد مانند 80 (HTTP) یا 443 (HTTPS) برای برقراری ارتباط با سرور فرماندهی (C2) استفاده می‌کنند. در این سناریو، یک نفوذگر موفق شده است یک دسترسی شل معکوس (Reverse Shell) روی سرور لینوکسی ایجاد کند که ترافیک آن روی پورت 443 رمزگذاری شده است. ابزارهای مانیتورینگ معمولی ممکن است این ترافیک را با ترافیک وب‌ گردی یا آپدیت سیستم اشتباه بگیرند.

روش شناسایی با دستور ss: قدرت اصلی دستور ss در ستون "Process" نهفته است. ما می‌ توانیم با بررسی اینکه "چه پروسه‌ ای" در حال استفاده از پورت 443 است، نفوذ را شناسایی کنیم.

دستور مورد استفاده:

sudo ss -ntup state established

تحلیل خروجی (Threat Hunting): در تصویر زیر، لیست اتصالات برقرار شده (Established) را مشاهده می‌کنید.

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

۱. بررسی ستون Local/Peer Address: یک اتصال به مقصد 10.30.30.4:443 برقرار شده است. تا اینجا همه چیز عادی به نظر می ‌رسد (شبیه به یک درخواست HTTPS).

۲. بررسی ستون Process (نقطه طلایی): با نگاه به ستون آخر، می‌بینیم که نام پروسه ‌ای که این اتصال را ایجاد کرده، bash است (همراه با PID مشخص 1296).

۳. نتیجه‌ گیری: پروسه ‌هایی مانند bash, sh, python, perl یا nc هیچ‌ گاه نباید به صورت مستقیم اتصال خروجی به اینترنت (Outbound) داشته باشند(مگر در شرایط خاص مدیریتی). مرورگرها یا ابزارهایی مثل curl و apt کاربران مجاز پورت 443 هستند (سرور نباید مرورگر باز داشته باشد، این مورد را در سرور خود برسی کنید). مشاهده اتصال bash به یک IP خارجی، نشان ‌دهنده قطعی یک Reverse Shell است.

این سطح از جزئیات که دقیقاً کدام PID و کدام پروسه سوکت را باز کرده است، در دستورات قدیمی netstat به این سرعت و دقت (بدون سوئیچ‌های کند کننده) در دسترس نبود.

نکته: نفوذگر های حرفه ای نام پردازش رو جعل می کنند (Process Masquerading) به عبارتی کد مخرب را در پردازش هایی مثل "nginx" یا "apache" قرار می دهند و شناسایی را سخت می کنند.

نکته: این روش ممکن است برای روت کیت های سطح کردنل (Kernel-level Rootkit) کار نکند، زیرا روت کیت ها برای دستکاری پردازش ها و مخفی سازی خودشان طراحی شدند.

نکته حرفه ای: اگر با تعداد زیادی ارتباط روی یک پورت خاص رو به رو هستید، می توانید اتصالات (مثلا پورت 22) را فیلتر کنید تا فقط موارد مشکوک باقی بمانند:

ss -tn sport != :22

اتصالات Established مانند تصویر به همراه پورت نمایش داده می شوند. در این نمونه ما اتصال مشکوک 10.30.30.4:4444 را داریم. به عنوان ادمین شبکه باید اطلاع داشته باشید که پورت 4444 آیا مال سیستم است یا پورت باز  شده ی یک بد افزار است.

نکته: این یک نمونه ی ساده آزمایشی هست نفوذگر ها از پورت هایی مانند 4444 استفاده نمی کنند تا راحت شناسایی شوند. 

تحلیل حملات DoS با دستور ss

سناریوی دوم: تحلیل حملات DoS (SYN Flood) و شناسایی منبع حمله

در یک حمله SYN Flood، مهاجم پکت‌ های SYN (درخواست اتصال اولیه) را به پورت‌ های در حال شنود (مانند پورت وب 80) با سرعت بالا ارسال می ‌کند اما هرگز Handshake را تکمیل نمی‌ کند. این کار منجر به پر شدن صف سوکت ‌های نیمه‌ باز (Half-open) در حافظه کرنل سرور می ‌شود که در نهایت سرویس ‌دهی به همه ی کاربران را مختل می‌ کند. سرعت و سبک‌ وزنی ss برای مقابله با این حملات حیاتی است، زیرا netstat در این شرایط که بار سنگینی روی سرور است به ‌راحتی از کار می‌افتد.

گام اول: بررسی سلامت کلی شبکه مقایسه باss -s))

ابتدا یک نگاه کلی به وضعیت سوکت‌ها می‌اندازیم تا ببینیم آیا فشار غیرعادی وجود دارد.

'watch -n 0.5 'ss -s

نکته فنی (برای مقاله): اگر پورت هدف در وضعیت LISTEN باشد اما در خروجی ss -s عدد بزرگی در synrecv مشاهده نکردید، ممکن است سیستم شما از مکانیزم‌های دفاعی کرنل (مثل SYN Cookies) استفاده می‌ کند که با وجود حمله، از اشباع جدول سوکت‌ها جلوگیری می‌ کند. در این حالت، باید مستقیماً سراغ مرحله بعدی و لیست دقیق حمله‌ کنندگان رفت.

تحلیل خروجی: در حالت عادی (تصویر بالا)، عبارت synrecv یا وجود ندارد یا مقدار آن صفر است. با این حال، در زمان حمله فعال، این مقدار باید به هزاران عدد برسد.

گام دوم: شناسایی IP مهاجم با فیلترینگ داخلی

به جای استفاده از روش ‌های غیر بهینه مانند پایپ کردن خروجی(  grep| ) ، از فیلترینگ داخلی و سریع ss استفاده می ‌کنیم تا سوکت ‌های نیمه ‌باز (SYN-RECV) را مستقیماً از کرنل درخواست کنیم:

'watch -n 0.5 'ss -nt state syn-recv

تصویر زیر حالت گسترده دستور:

تحلیل خروجی:

نکته مهم: عدد 23094 (در ستون Peer Address:Port و پس از IP مهاجم) تعداد پکت ‌های ارسال شده نیست. این عدد شماره پورت مبدأ (Source Port) است که مهاجم برای ارسال پکت از آن استفاده کرده است.

نتیجه‌گیری نهایی: با مشاهده حجم بالای اتصالات در وضعیت SYN-RECV که همگی از IP مشخص 10.30.30.4 به پورت هدف سرور (مثلاً 80) می‌ آیند، هویت مهاجم (IP) و نوع حمله (SYN Flood) به ‌صورت قطعی شناسایی می ‌شود. در این مثال میلیون ها پکت از سرور کالی لینوکس با IP 10.30.30.4 به پورت 80 سرور دبین با IP 10.30.30.7 در حال ارسال است.

آیپی و شماره پورت مبدأ (Source Port) سمت مهاجم،  با دستور ss مشخص شد. اگر حمله مانند نمونه پیشرفته نبود و آیپی مهاجم مشخص بود،  به راحتی می توانید آن را بلاک کنید.

نکته: با این که دستور "ss" بسیار سبک تر از "netstat" هست اما در حملات سنگین DDOS حتی "ss" هم ممکن است پاسخ ندهد.

نکته: حملات پیشرفته ی DDOS آیپی های متغیر دارند و معمولا چندین متود مختلف (HTTP, SYC, PING, ...) استفاده می کنند، در این شرایط کشف مهاجم بسیار سخت تر خواهد بود.

شناسایی Backdoor با بررسی UNIX Sockets

شناسایی کانال‌های ارتباطی مخفی (Reverse Shell) بدافزار (Internal Backdoors) با بررسی UNIX Sockets

سناریو سوم: با استفاده از یک اسکریپت مخرب پایتونی یک سوکت جعلی به اسم /tmp/.systemd-private در دبین درست شده و از طریق این سوکت یک شل مخفی در سیستم قربانی (Debian) توسط اتکر (Kali) ایجاد شده است.

 بدافزار های پیشرفته لینوکسی ممکن است از UNIX Sockets برای ایجاد کانال مخفی استفاده کنند. برای  مشاهده ی تمام اطلاعات مربوط به سوکت ها و نوع ارتباط آنها، دستور زیر را وارد کنید:

'watch 'ss -xa

هر 1 ثانیه کل فرآیند نظارت بروز خواهد شد. سوکت ها را تحلیل کنید و سوکت های مشکوک را شناسایی کنید.

در سرور دبین یک ارتباط backdoor شکل گرفته که در آن IP 10.30.30.4 یک اتصال از پورت 443 ایجاد کرده:

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

برای پایان دادن به حمله بعد از شناسایی PID سوکت، از دستور kill استفاده کنید و سوکت را ببندید.

نکته: نفوذگر های حرفه ای، بعد از گرفتن دسترسی اولیه برای پایدار شدن روی سرور (Persistence) و یا ارتقای دسترسی (Privilege Escalation)  از "Abstract UNIX Domain Sockets" در لینوکس استفاده می کنند تا مشکلات دسترسی پذیری و شناسایی را برطرف کنند.

در این حالت اگر سوکت معمولی در مسیر "/tmp/my_socket" قرار دارد، این سوکت ها در مسیر ذخیره نمی شوند چون فایل ایجاد نمی شود و به جای مسیر، یک نام دارند که با کارکتر (/0) شروع می شود(مثلا(/0system-privet)). البته که این سوکت ها به طور خودکار بعد از ری استارت سیستم پاک می شوند و داخلی (Local) هستند و  از بیرون سرور قابل دسترسی نیستند اما مدیریت آنها ساده تر است چون نیاز به cleanup ندارند و معمولا برسی نمی شوند.

شناسایی این سوکت ها از دستور "ss -xlp --unix" امکان پذیر هست.

ss -xlp --unix 'src @*' | column -t

"| column -t " برای فشرده کردن خروجی هست. خروجی اصلی به صورت زیر است:

همین طور که مشاهده می کنید، "Abstract UNIX Domain Sockets" سوکت ما (@system-dc285115635aec12) ذخیره در جایی نیست و در حالت شنود قرار دارد، نفوذگر های حرفه ای بیشتر از این نوع سوکت استفاده می کنند.

نتیجه گیری

دستور "ss" ابزار قدرتمندی است که در کنار سایر ابزار های امنیتی به ادمین کمک می کند تا به سرعت دسترسی مستقیم به اطلاعات کرنل داشته باشد. تسلط کامل به دستور "ss" هنر اصلی ادمین در شناسایی تهدید هست چون با برسی دقیق، تفاوت ترافیک مخرب از عادی مشخص می شود. اگر تا به الان به ابزار قدیمی "netstat" عادت کرده اید و استفاده می کنید، زمان آن فرا رسیده تا آن را بازنشست کنید و از "ss" به عنوان ابزار شماره یک جعبه ابزار خود استفاده کنید.