مقدمه

یکی از نشانه‌های مهم نفوذ به یک سرور لینوکسی می‌تواند ایجاد یک Reverse Shell باشد.

در یک اتصال عادی مانند SSH، مدیر سیستم از بیرون به سرور متصل می‌شود:

Administrator
      |
      v
Linux Server

اما در Reverse Shell جهت ارتباط برعکس است. سیستم آلوده خودش یک Connection خروجی به سیستم دیگری ایجاد می‌کند و مهاجم از طریق همان ارتباط قادر به اجرای Command روی سرور می‌شود.

به همین دلیل ممکن است:

• هیچ SSH Login جدیدی مشاهده نشود.
• هیچ پورت Listener مشکوکی باز نباشد.
• Firewall ورودی نیز اتصال خاصی را ثبت نکرده باشد.
• اما همچنان یک Shell روی سرور در اختیار مهاجم قرار گرفته باشد.

در این مقاله بررسی می‌کنیم چگونه با ابزارهای داخلی لینوکس، Connectionهای مشکوک، Process مرتبط، Parent Process، File Descriptorها، Logها و Persistence احتمالی را بررسی کنیم.

هدف این مقاله شناسایی و پاسخ به Reverse Shell روی سرورهای تحت مدیریت خودتان است و شامل ساخت یا اجرای Reverse Shell نمی‌شود.

Reverse Shell چیست؟

در حالت عادی اگر بخواهیم به یک Linux Server متصل شویم، Client به Server اتصال ایجاد می‌کند.

برای مثال در SSH:

Client
   |
   | TCP Connection
   v
Server:22

اما در Reverse Shell معمولاً سیستم قربانی Connection خروجی ایجاد می‌کند:

Compromised Server
        |
        | Outbound Connection
        v
Remote System

سپس Input و Output یک Shell یا Process دیگر می‌تواند از طریق این Connection منتقل شود.

همین تفاوت باعث می‌شود شناسایی Reverse Shell فقط با بررسی پورت‌های Listening کافی نباشد.

چرا Reverse Shell خطرناک است؟

اگر مهاجم موفق به ایجاد Reverse Shell شود، بسته به Permission Process ممکن است بتواند:

• Command اجرا کند.
• فایل‌های سرور را مشاهده کند.
• Configurationها را بخواند.
• Credentialها را پیدا کند.
• ابزارهای دیگری اجرا کند.
• Persistence ایجاد کند.
• به سرویس‌های داخلی دسترسی پیدا کند.
• برای دسترسی به سیستم‌های دیگر شبکه تلاش کند.

اگر Process با Permission بالا اجرا شده باشد، Impact حادثه می‌تواند بسیار جدی‌تر باشد.

آیا هر Connection خروجی مشکوک است؟

خیر.

سرورهای لینوکسی معمولاً Connectionهای خروجی مختلفی دارند.

برای مثال:

DNS
NTP
Package Repository
Monitoring
Backup
API
SMTP
Database
Cloud Services

بنابراین مشاهده یک Connection خروجی به‌تنهایی اثبات Reverse Shell نیست.

معمولاً باید چند نشانه را کنار یکدیگر قرار دهیم:

Network Connection
       +
Process
       +
Parent Process
       +
Command Line
       +
User
       +
Logs

هرچه این شواهد بیشتر با یکدیگر هم‌خوانی داشته باشند، احتمال Incident بیشتر می‌شود.

اولین مرحله: مشاهده Connectionهای فعال

یکی از مهم‌ترین ابزارهای داخلی لینوکس:

ss

است.

برای مشاهده Connectionهای TCP:

sudo ss -tnp

گزینه:

-t

یعنی فقط TCP را نمایش بده.

گزینه:

-n

باعث می‌شود IP و Port به‌صورت Numeric نمایش داده شوند.

و:

-p

Process مرتبط با Socket را در صورت داشتن Permission نمایش می‌دهد.

مشاهده Connectionهای Established

برای تمرکز روی Connectionهایی که در حال حاضر برقرار هستند:

sudo ss -tnp state established

فرض کنید خروجی مشابه زیر مشاهده شود:

ESTAB 0 0 10.10.10.20:45822 203.0.113.10:4444 users:(("bash",pid=24891,fd=3))

اطلاعات مهم این خط عبارت‌اند از:

Local IP:
10.10.10.20

Local Port:
45822

Remote IP:
203.0.113.10

Remote Port:
4444

Process:
bash

PID:
24891

وجود bash با Connection مستقیم به یک IP خارجی غیرمنتظره دلیل خوبی برای بررسی فوری است، اما هنوز به‌تنهایی اثبات Reverse Shell نیست.

مشاهده تمام Connectionهای TCP و UDP

برای TCP:

sudo ss -tnap

برای UDP:

sudo ss -unap

برای مشاهده هر دو:

sudo ss -tunap

در Incident Response بهتر است قبل از ایجاد تغییر، خروجی را ذخیره کنید:

sudo ss -tunap > /root/ir-network-connections.txt

به این ترتیب وضعیت Connectionهای شبکه در لحظه بررسی ثبت می‌شود.

استفاده از lsof برای بررسی شبکه

ابزار مهم دیگر:

lsof

است.

برای مشاهده Network Connectionها:

sudo lsof -nP -i

برای مشاهده Connectionهای TCP برقرارشده:

sudo lsof -nP -iTCP -sTCP:ESTABLISHED

نمونه:

COMMAND   PID     USER      FD   TYPE   NAME

bash      24891   www-data  3u   IPv4   TCP 10.10.10.20:45822->203.0.113.10:4444 (ESTABLISHED)

در این مثال:

Process = bash
User = www-data

است.

اگر Web Server با Userهایی مانند:

www-data
apache
nginx

اجرا شود، وجود Shell متعلق به همان User که Connection خارجی نیز دارد، باید جدی بررسی شود.

پیدا کردن Process از روی PID

فرض کنیم ss نشان داده است:

pid=24891

ابتدا:

ps -fp 24891

را اجرا کنید.

برای مشاهده اطلاعات بیشتر:

ps -o pid,ppid,user,lstart,etime,args -p 24891

اطلاعات مهم عبارت‌اند از:

PID
PPID
USER
START TIME
ELAPSED TIME
COMMAND

یکی از مهم‌ترین موارد:

PPID

است.

PPID شناسه Parent Process است.

چرا Parent Process مهم است؟

فرض کنید Process موردنظر:

bash

است.

وجود Bash روی Linux کاملاً عادی است.

اگر Parent آن:

sshd

باشد، ممکن است Bash متعلق به یک Session عادی SSH باشد.

اما اگر Process Tree چنین چیزی باشد:

nginx
   |
   v
php-fpm
   |
   v
sh
   |
   v
bash

موضوع بسیار مشکوک‌تر خواهد بود.

یک Web Application معمولاً نباید بدون دلیل یک Shell ایجاد کند که هم‌زمان Connection خارجی نیز دارد.

مشاهده Process Tree

برای مشاهده Process Tree کامل:

pstree -ap

اگر PID مشخص داریم:

pstree -asp 24891

ممکن است چیزی شبیه زیر مشاهده شود:

systemd
  └─apache2
      └─php-fpm
          └─sh
              └─bash

این زنجیره باید با رفتار طبیعی Application مقایسه شود.

بررسی Command Line Process

برای مشاهده Command Line:

ps -p 24891 -o args=

همچنین اطلاعات Process داخل /proc وجود دارد:

cat /proc/24891/cmdline

برای نمایش خواناتر:

tr '\0' ' ' < /proc/24891/cmdline

به موارد زیر توجه کنید:

• Command ناشناخته
• اجرای Shell توسط Web Server
• Script داخل /tmp
• Script داخل /dev/shm
• Binary با نام غیرعادی
• Argumentهای مبهم
• اجرای Interpreter غیرمنتظره

بررسی Executable واقعی Process

برای مشاهده فایل اجرایی Process:

readlink -f /proc/24891/exe

برای مثال:

/usr/bin/bash

یا ممکن است مسیر غیرمعمولی مانند:

/tmp/.cache/example

نمایش داده شود.

اجرای Binary از Directoryهایی مانند:

/tmp
/var/tmp
/dev/shm

به‌خصوص توسط User مربوط به Web Server، نیازمند بررسی است.

بررسی Working Directory

برای مشاهده Current Working Directory:

readlink -f /proc/24891/cwd

اگر Process مشکوک از Directoryهایی مانند:

/tmp
/dev/shm
/var/www/.../uploads

اجرا شده باشد، این موضوع می‌تواند سرنخ مهمی باشد.

بررسی File Descriptorهای Process

هر Process در Linux دارای File Descriptor است.

برای بررسی Process:

sudo ls -la /proc/24891/fd/

ممکن است خروجی مشابه زیر باشد:

0 -> socket:[123456]
1 -> socket:[123456]
2 -> socket:[123456]
3 -> socket:[123456]

یا ترکیبی از:

socket
pipe
file
/dev/null

مشاهده شود.

سه File Descriptor مهم عبارت‌اند از:

0 = Standard Input
1 = Standard Output
2 = Standard Error

اگر Input و Output یک Shell به Socketهای غیرمنتظره متصل شده باشند، این موضوع یکی از نشانه‌هایی است که باید همراه سایر Evidenceها بررسی شود.

بررسی وضعیت کامل Process

برای مشاهده اطلاعات Process:

cat /proc/24891/status

موارد مهم عبارت‌اند از:

Name
State
Pid
PPid
Uid
Gid

همچنین می‌توان Environment Process را با Permission مناسب بررسی کرد:

sudo tr '\0' '\n' < /proc/24891/environ

گاهی Environment می‌تواند درباره Application یا نحوه اجرای Process اطلاعات بیشتری ارائه کند.

جستجوی Shellهای فعال

برای پیدا کردن Shell Processها:

ps auxww | grep -E '[b]ash|[d]ash|[s]h|[z]sh'

اما نتیجه این دستور به‌تنهایی ارزشی برای تشخیص قطعی Reverse Shell ندارد.

وجود:

bash
sh
dash

روی Linux طبیعی است.

باید مشخص شود:

• Process متعلق به چه Userی است؟
• Parent آن چیست؟
• Network Connection دارد؟
• از چه مسیری اجرا شده؟
• چه زمانی ایجاد شده؟

بررسی Processهای Web Server

اگر احتمال می‌دهید نفوذ از Web Application انجام شده باشد، Processهای User مربوط به Web Server را بررسی کنید.

در Ubuntu و Debian:

ps -u www-data -f

در بعضی سیستم‌های Apache:

ps -u apache -f

برای Nginx:

ps -u nginx -f

وجود Processهایی مانند:

sh
bash
python
perl

برای این Userها لزوماً مخرب نیست، اما علت آنها باید مشخص شود؛ مخصوصاً اگر Network Connection خارجی نیز داشته باشند.

مشاهده Connectionهای یک PID مشخص

اگر PID موردنظر مشخص شده است:

sudo lsof -Pan -p 24891 -i

همچنین:

sudo ss -tnp | grep 'pid=24891'

می‌تواند Connection مرتبط با Process را نشان دهد.

بررسی Destination IP

بعد از پیدا کردن Remote IP باید مشخص کنید این IP چه ارتباطی با سرویس دارد.

سؤالات مهم:

• آیا IP متعلق به Monitoring Provider است؟
• Backup Provider است؟
• API رسمی Application است؟
• CDN است؟
• SMTP Relay است؟
• Database خارجی است؟
• یا هیچ ارتباط شناخته‌شده‌ای با Server ندارد؟

یک Server Production بهتر است Baseline مشخصی از Destinationهای طبیعی خود داشته باشد.

Port غیرمعمول به معنی Reverse Shell نیست

Portهایی مانند:

4444
5555
8081
9001

ممکن است توجه مدیر سیستم را جلب کنند.

اما شماره Port به‌تنهایی معیار تشخیص نیست.

از طرف دیگر، Connection مشکوک می‌تواند روی Portهای کاملاً معمولی مانند:

80
443
53

نیز برقرار شود.

بنابراین تشخیص باید بیشتر بر اساس:

Process
+
Parent
+
Destination
+
Behaviour

باشد.

بررسی Connectionهای طولانی

برای مشاهده Established Connection به همراه Timer:

sudo ss -tnpo state established

برای مشاهده دوره‌ای:

watch -n 2 'ss -tnp state established'

Connection طولانی‌مدت به IP ناشناس می‌تواند ارزش بررسی داشته باشد، به‌خصوص اگر Process مرتبط نیز غیرعادی باشد.

بررسی Logهای systemd

برای مشاهده Logهای اخیر:

journalctl --since "1 hour ago"

برای Nginx:

journalctl -u nginx

برای Apache:

journalctl -u apache2

برای مشاهده Real-time:

journalctl -f

هدف این است که Eventهای نزدیک به زمان ایجاد Process مشکوک را پیدا کنیم.

بررسی Authentication Log

در Ubuntu و Debian:

sudo less /var/log/auth.log

در AlmaLinux، Rocky Linux و RHEL:

sudo less /var/log/secure

مواردی مانند:

• SSH Login
• sudo
• Authentication Failure
• Session Start
• User Creation

را بررسی کنید.

البته نبود SSH Login مشکوک، Reverse Shell را رد نمی‌کند.

بررسی Web Server Logها

اگر احتمال می‌دهید Incident از Web Application آغاز شده است، Access Log و Error Log اهمیت زیادی دارند.

برای Nginx:

/var/log/nginx/access.log
/var/log/nginx/error.log

برای Apache در Ubuntu:

/var/log/apache2/access.log
/var/log/apache2/error.log

برای مشاهده آخرین Requestها:

tail -n 200 /var/log/nginx/access.log

یا:

tail -n 200 /var/log/apache2/access.log

به Requestهای غیرمعمول نزدیک زمان ایجاد Process توجه کنید.

زمان Process را با Log تطبیق دهید

برای مشاهده زمان آغاز Process:

ps -o pid,lstart,args -p 24891

فرض کنید Process در ساعت:

14:32

ایجاد شده است.

اکنون Log مربوط به همان زمان را بررسی کنید:

grep '14:32' /var/log/nginx/access.log

یا:

grep '14:32' /var/log/apache2/access.log

اگر یک HTTP Request غیرعادی درست قبل از ایجاد Process ثبت شده باشد، Correlation بسیار مهمی ایجاد می‌شود.

بررسی فایل‌های جدید

اگر احتمال نفوذ از Web Application وجود دارد، فایل‌های جدید را بررسی کنید.

فایل‌های تغییرکرده طی 24 ساعت:

sudo find /var/www -type f -mtime -1 -ls

یا فایل‌های تغییرکرده در 60 دقیقه گذشته:

sudo find /var/www -type f -mmin -60 -ls

به‌خصوص Directoryهایی مانند:

uploads
cache
tmp
public

را بررسی کنید.

جدید بودن فایل به‌تنهایی نشانه Malware نیست و باید با فعالیت عادی Application مقایسه شود.

بررسی /tmp و /dev/shm

Directoryهای Writable مانند:

/tmp
/var/tmp
/dev/shm

نیز باید بررسی شوند.

برای مشاهده فایل‌های ایجاد یا تغییرکرده در دو ساعت اخیر:

sudo find /tmp /var/tmp /dev/shm -type f -mmin -120 -ls

به موارد زیر توجه کنید:

• فایل مخفی
• Executable ناشناس
• نام تصادفی
• Owner مربوط به Web Server
• Timestamp نزدیک Incident

بررسی فایل‌های حذف‌شده ولی در حال استفاده

گاهی یک Process هنوز فایلی را باز نگه داشته است که از Filesystem حذف شده است.

برای بررسی:

sudo lsof +L1

وجود چنین فایلی همیشه به معنی Malware نیست، اما Processهای ناشناخته در این خروجی باید بررسی شوند.

بررسی Persistence

حتی اگر Reverse Shell پیدا و متوقف شود، ممکن است مهاجم روش دیگری برای بازگشت ایجاد کرده باشد.

به همین دلیل بررسی Persistence ضروری است.

بررسی Cron Jobها

Cron مربوط به Root:

sudo crontab -l

Cron User فعلی:

crontab -l

همچنین:

sudo ls -la /etc/cron.d/

sudo ls -la /etc/cron.daily/

و بسته به Distribution:

sudo ls -la /var/spool/cron/

را بررسی کنید.

Jobهای جدید یا ناشناخته باید بررسی شوند.

بررسی systemd Serviceها

برای مشاهده سرویس‌های Running:

systemctl --type=service --state=running

برای Serviceهای Enable شده:

systemctl list-unit-files --type=service --state=enabled

همچنین:

ls -la /etc/systemd/system/

را بررسی کنید.

Service ناشناخته‌ای که برنامه‌ای را از:

/tmp
/dev/shm
/home

اجرا می‌کند باید جدی بررسی شود.

بررسی systemd Timerها

برای مشاهده Timerها:

systemctl list-timers --all

Timer جدید یا ناشناخته ممکن است یک Persistence Mechanism باشد.

بررسی SSH Authorized Keys

برای Root:

sudo cat /root/.ssh/authorized_keys

برای User فعلی:

cat ~/.ssh/authorized_keys

برای پیدا کردن فایل‌های Authorized Keys:

sudo find /home /root -path '*/.ssh/authorized_keys' -type f -ls

هر Key ناشناخته باید بررسی شود.

بررسی Userهای سیستم

تمام Userها:

cat /etc/passwd

Userهایی که Login Shell دارند:

awk -F: '$7 !~ /(nologin|false)$/ {print $1,$3,$6,$7}' /etc/passwd

به Accountهای جدید، UID غیرعادی یا Userهایی که انتظار ندارید Login داشته باشند توجه کنید.

استفاده از Auditd

در سیستم‌هایی که Linux Audit فعال است می‌توان اطلاعات ارزشمندی درباره اجرای Processها پیدا کرد.

ابتدا:

sudo systemctl status auditd

را بررسی کنید.

برای جستجوی Eventهای اجرایی اخیر:

sudo ausearch -m EXECVE -ts recent

اگر PID مشخص دارید:

sudo ausearch -p 24891

وجود Audit Logging قبل از Incident اهمیت زیادی دارد؛ Auditd نمی‌تواند Eventهایی را که قبلاً ثبت نشده‌اند بعداً بازسازی کند.

یک سناریوی عملی شناسایی

فرض کنید دستور:

sudo ss -tnp state established

خروجی زیر را نشان می‌دهد:

10.10.10.20:45822 -> 203.0.113.10:4444
users:(("bash",pid=24891,fd=3))

مرحله اول: بررسی Process

ps -o pid,ppid,user,lstart,args -p 24891

فرض کنیم User:

www-data

است.

این موضوع ارزش بررسی دارد.

مرحله دوم: بررسی Parent Process

pstree -asp 24891

فرض کنیم نتیجه:

apache2
 └─php-fpm
    └─sh
       └─bash

باشد.

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

مرحله سوم: بررسی Socketها

sudo ls -la /proc/24891/fd/

بررسی کنید File Descriptorهای Process به چه منابعی متصل هستند.

مرحله چهارم: تعیین زمان آغاز Process

ps -o lstart= -p 24891

فرض کنیم:

14:32

باشد.

مرحله پنجم: بررسی Web Log

grep '14:32' /var/log/apache2/access.log

اگر Request غیرمعمولی دقیقاً نزدیک این زمان وجود داشته باشد، شواهد قوی‌تر می‌شوند.

رویکرد صحیح Detection به این شکل است:

Network
   +
Process
   +
Parent
   +
File Descriptors
   +
Timeline
   +
Application Logs

اگر Reverse Shell پیدا کردیم چه کنیم؟

اگر شواهد جدی از Compromise وجود دارد، اولین اقدام نباید صرفاً:

kill PID

باشد.

با Kill کردن سریع Process ممکن است بخشی از Evidence از بین برود.

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

جمع‌آوری اولیه Evidence

زمان سیستم:

date

Network Connectionها:

sudo ss -tunap > /root/ir-network.txt

Processها:

ps auxwwf > /root/ir-processes.txt

Open Fileها:

sudo lsof -nP > /root/ir-lsof.txt

Logged-in Userها:

who

و:

w

اطلاعات مشکوک باید قبل از تغییر گسترده در سیستم ثبت شوند.

مرحله اول: Containment

اگر Compromise تأیید یا بسیار محتمل باشد، باید ارتباطات غیرضروری سیستم محدود شوند.

بسته به زیرساخت می‌توان از:

• Firewall
• Security Group
• VLAN
• Hypervisor
• Cloud Network Policy

استفاده کرد.

هدف این مرحله:

Containment

است.

در Incident جدی، Server را بدون برنامه خاموش نکنید؛ زیرا اطلاعات Volatile مانند Processها و Connectionهای شبکه از بین خواهند رفت.

مرحله دوم: حفظ Evidence

مواردی که ممکن است برای Investigation لازم باشند:

• Process List
• Network Connectionها
• Open Files
• Logged-in Userها
• Process Tree
• Command Lineها
• Logها
• Timeline
• Hash فایل‌های مشکوک
• Persistence Mechanismها

در Incidentهای مهم ممکن است Memory Capture و Disk Image نیز طبق رویه Forensics سازمان نیاز باشد.

مرحله سوم: Credentialها را بررسی کنید

اگر مهاجم توانسته روی Server Command اجرا کند، Secretهای موجود روی آن سرور ممکن است در معرض خطر قرار گرفته باشند.

برای مثال:

• SSH Private Key
• API Token
• Database Password
• Cloud Credential
• Backup Credential
• Application Secret

در صورت تأیید Incident، Credentialهای مرتبط باید براساس Scope حادثه Rotate شوند.

Rotation بهتر است از یک سیستم سالم انجام شود.

مرحله چهارم: Root Cause را پیدا کنید

حذف Reverse Shell مشکل اصلی را حل نمی‌کند.

باید مشخص شود مهاجم چگونه وارد Server شده است.

برای مثال:

• Vulnerable Web Application
• Plugin قدیمی
• Credential سرقت‌شده
• Weak Password
• Misconfiguration
• Exposed Management Panel
• Vulnerable Service
• Compromised Deployment Credential

تا Root Cause رفع نشود، احتمال بازگشت مهاجم وجود دارد.

مرحله پنجم: Rebuild یا Cleanup؟

اگر مهاجم دسترسی سطح بالا داشته یا Root Compromise محتمل باشد، Cleanup دستی همیشه قابل اعتماد نیست.

در چنین شرایطی باید گزینه:

Rebuild از Image سالم

جدی بررسی شود.

بعد از Rebuild نیز لازم است:

• Patch
• Hardening
• Credential Rotation
• Log Review
• Monitoring

انجام شوند.

چگونه احتمال Reverse Shell را کاهش دهیم؟

اقدامات دفاعی مهم عبارت‌اند از:

• Patch منظم سیستم‌عامل
• Update Web Application
• Update CMS و Pluginها
• Least Privilege
• Egress Filtering
• Application Isolation
• SELinux یا AppArmor
• EDR
• Audit Logging
• File Integrity Monitoring
• Web Application Firewall
• Network Monitoring

محدود کردن Outbound Traffic

یکی از اقدامات دفاعی مهم محدود کردن Connectionهای خروجی است.

یک Web Server ممکن است فقط به مواردی مانند:

DNS
NTP
Package Repository
Database
Monitoring
Approved APIs

نیاز داشته باشد.

اگر Server بتواند بدون محدودیت به هر IP و Port اینترنت متصل شود، شناسایی و جلوگیری از ارتباطات غیرعادی دشوارتر خواهد بود.

Egress Filtering می‌تواند سطح کنترل بیشتری ایجاد کند.

ایجاد Baseline شبکه

بهتر است مشخص باشد Server در حالت عادی به چه Destinationهایی متصل می‌شود.

برای مثال:

Web Server
 ├─ DNS Resolver
 ├─ Database
 ├─ Monitoring Server
 ├─ Backup Server
 └─ Approved APIs

اگر اتصال جدیدی خارج از این Baseline مشاهده شود، باید بررسی شود.

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

برخی اشتباهات رایج هنگام شناسایی Reverse Shell عبارت‌اند از:

• بررسی فقط Listening Portها
• تصور اینکه هر Bash مخرب است
• تصور اینکه هر Connection خارجی مخرب است
• تمرکز فقط روی Portهای غیرمعمول
• Kill کردن Process قبل از جمع‌آوری Evidence
• بررسی نکردن Parent Process
• بررسی نکردن Web Server Log
• نادیده گرفتن Persistence
• Rotate نکردن Credentialهای در معرض خطر
• حذف فایل مشکوک بدون یافتن Root Cause
• اعتماد مجدد به Server بدون بررسی Scope Compromise

بهترین روش‌ها

برای شناسایی صحیح Reverse Shell:

• Connectionهای Established را بررسی کنید.
• PID مربوط به Connection را پیدا کنید.
• User Process را مشخص کنید.
• Parent Process را بررسی کنید.
• Process Tree را مشاهده کنید.
• Command Line را بررسی کنید.
• Executable واقعی را پیدا کنید.
• Working Directory را بررسی کنید.
• File Descriptorها را بررسی کنید.
• Timeline را با Logها تطبیق دهید.
• فایل‌های جدید را بررسی کنید.
• Cron و systemd را بررسی کنید.
• SSH Keyها را بررسی کنید.
• قبل از Kill کردن Process Evidence لازم را ذخیره کنید.
• Root Cause را پیدا کنید.
• در Compromise جدی Rebuild را در نظر بگیرید.

چک‌لیست

اگر احتمال Reverse Shell روی Linux Server وجود دارد موارد زیر را بررسی کنید:

• Connectionهای Established بررسی شده‌اند.
• Remote IPهای ناشناخته مشخص شده‌اند.
• Process مربوط به Connection پیدا شده است.
• User Process بررسی شده است.
• Parent Process مشخص شده است.
• Process Tree بررسی شده است.
• Command Line بررسی شده است.
• Executable واقعی Process بررسی شده است.
• Working Directory بررسی شده است.
• File Descriptorها بررسی شده‌اند.
• Web Server Logها بررسی شده‌اند.
• Authentication Logها بررسی شده‌اند.
• فایل‌های جدید بررسی شده‌اند.
• /tmp و /dev/shm بررسی شده‌اند.
• Cron Jobها بررسی شده‌اند.
• systemd Serviceها بررسی شده‌اند.
• systemd Timerها بررسی شده‌اند.
• SSH Authorized Keyها بررسی شده‌اند.
• Evidence قبل از Containment ذخیره شده است.
• Root Cause بررسی شده است.
• Credentialهای در معرض خطر Rotate شده‌اند.

مطالعات بیشتر

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

• مستندات رسمی iproute2 درباره ss
  مرجع گزینه‌های ss برای مشاهده Socketها، TCP State و اطلاعات Process.
  https://github.com/iproute2/iproute2/blob/main/man/man8/ss.8?utm_source=maral.cloud
• Linux man-pages – proc_pid_fd
  توضیح رسمی ساختار /proc/PID/fd و File Descriptorهای مربوط به فایل، Pipe و Socket.
  https://man7.org/linux/man-pages/man5/proc_pid_fd.5.html?utm_source=maral.cloud
• systemd – journalctl
  مستندات رسمی مشاهده و Filter کردن Logهای systemd Journal.
  https://www.freedesktop.org/software/systemd/man/latest/journalctl.html?utm_source=maral.cloud
• Linux Audit – auditd
  مستندات Linux Audit Daemon و نحوه ثبت Audit Eventها.
  https://github.com/linux-audit/audit-userspace/blob/master/docs/auditd.8?utm_source=maral.cloud
• Linux Kernel / Userspace Interface Documentation
  مجموعه مستندات Linux man-pages برای Processها، /proc و Interfaceهای سیستم.
  https://www.kernel.org/doc/man-pages/?utm_source=maral.cloud

جمع‌بندی

Reverse Shell با بسیاری از Connectionهای معمول شبکه تفاوت مهمی دارد: در این حالت سیستم آلوده می‌تواند خودش Connection خروجی ایجاد کند و Shell را از طریق همان ارتباط در اختیار سیستم Remote قرار دهد.

به همین دلیل بررسی صرف پورت‌های Listening برای شناسایی آن کافی نیست.

یکی از بهترین نقاط شروع:

sudo ss -tnp state established

است.

اگر Connection مشکوکی مشاهده شد، باید Process، PID، User و Destination مربوط به آن مشخص شوند.

پس از آن:

ps -o pid,ppid,user,lstart,args -p PID

و:

pstree -asp PID

کمک می‌کنند مشخص شود Process از چه زنجیره‌ای ایجاد شده است.

در مرحله بعد باید /proc/PID/fd، Executable، Working Directory، Web Logها و Timeline بررسی شوند.

مهم‌ترین نکته این است که هیچ نشانه‌ای را به‌تنهایی مبنای تشخیص Reverse Shell قرار ندهیم.

یک Bash، یک IP خارجی یا یک Port غیرمعمول به‌تنهایی اثبات Incident نیست.

تشخیص معتبر زمانی شکل می‌گیرد که چند Evidence کنار یکدیگر قرار بگیرند:

Suspicious Connection
        +
Unexpected Process
        +
Suspicious Parent
        +
Socket-backed File Descriptors
        +
Matching Timeline
        +
Application or System Logs

اگر Compromise تأیید شد، فقط بستن Connection یا Kill کردن Process کافی نیست. Evidence باید حفظ شود، سیستم مهار شود، Persistence و Root Cause بررسی شوند و Credentialهای در معرض خطر نیز Rotate شوند.

در Incidentهای جدی، به‌خصوص زمانی که احتمال Root Compromise وجود دارد، بازسازی Server از یک Image سالم باید به‌عنوان یکی از گزینه‌های اصلی Recovery بررسی شود.

کیان پور