آمورش شناسایی بدافزارها و اتصالات مشکوک در لینوکس با دستور ss

دستور ss چیست و چه کاری انجام می دهد؟

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

در این مقاله، به نحوه ی برسی اتصالات و نقش دستور ss در incident response و Threat Hunting پرداخته می شود.

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

آپشن های پایه ی دستور ss

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

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

ss -tunab

 این دستور کاربردی اتصالات را با نوع کارت شبکه مورد استفاده نمایش میدهد.

ss -tulpn

این دستور پراسس را با اتصالش نمایش می دهد.

آموزش تشخیص Reverse Shell مخفی در لینوکس

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

روش شناسایی این شل معکوس با دستور ss:

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

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

sudo ss -tunp 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 است.

نکات مهم:

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

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

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

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

ss -tn sport != :22

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

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

5- با استفاده از دستور

<kill [options] <PID

 شل معکوس را می توانید ببندید.

6- بلافاصله بعد از بستن شل، حتما فایل "cron" را به آدرس زیر چک کنید که بدافزار یک "Task scheduler" ننوشته باشد تا دسترسی خود را پایدار "persistent" کند.

etc/crontab/

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

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

در یک حمله SYN Flood، مهاجم پکت‌ های SYN (درخواست اتصال اولیه) را به پورت‌ های در حال شنود (مانند پورت وب 80) با سرعت بالا ارسال می ‌کند اما هرگز Handshake را تکمیل نمی‌ کند. با توجه به استاندارد "three-way-handshake" برای بسته های tcp، سرور منتظر تکمیل پروسه ی Handshake می ماند و این کار منجر به پر شدن صف سوکت ‌های  نیمه‌ باز (Half-open) در حافظه کرنل سرور می ‌شود که در نهایت سرویس ‌دهی به همه ی کاربران و در برخی شرایط IPS و IDS ها را مختل می‌ کند. سرعت و سبک‌ بودن 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 هدف سرور (http) می‌ آیند، هویت مهاجم (IP) و نوع حمله (SYN Flood) به ‌صورت قطعی شناسایی می ‌شود. در این مثال میلیون ها پکت از سرور کالی لینوکس با IP 10.30.30.4 به پورت 80 سرور دبین با IP 10.30.30.7 در حال ارسال است.

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

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

نکته: این حمله نمونه ی ساده ی "DoS syc flood" بود و به همین خاطر آیپی مهاجم مشخص بود،حملات پیشرفته ی "DoS" و حملات بسیار پیشرفته تر "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" به عنوان ابزار شماره یک جعبه ابزار خود استفاده کنید.