مقدمه

در سیستم‌عامل لینوکس بعضی برنامه‌ها برای انجام وظایف خاص باید برای مدت کوتاهی با سطح دسترسی بالاتری از کاربر اجراکننده فعالیت کنند.

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

SUID یا Set User ID

است.

برای مثال برنامه passwd باید بتواند اطلاعات مربوط به Password کاربران را در فایل‌هایی تغییر دهد که یک User معمولی اجازه نوشتن مستقیم در آنها را ندارد.

به همین دلیل بعضی فایل‌های اجرایی به‌صورت قانونی دارای SUID هستند.

اما همین قابلیت می‌تواند در صورت سوءاستفاده به یک مشکل امنیتی جدی تبدیل شود.

اگر یک فایل ناشناس یا تغییرکرده دارای SUID و Owner آن root باشد، اجرای آن می‌تواند باعث شود Process با Effective User ID متعلق به Root اجرا شود. در Linux، بیت Set-user-ID هنگام اجرای فایل می‌تواند Effective UID فرایند را به Owner فایل تغییر دهد.

به همین دلیل بررسی فایل‌های SUID یکی از مراحل مهم در:

• Linux Hardening
• Security Audit
• Incident Response
• Privilege Review
• File Integrity Monitoring

است.

در این مقاله یاد می‌گیریم چگونه فایل‌های SUID را پیدا کنیم، موارد طبیعی را از فایل‌های مشکوک جدا کنیم و در صورت مشاهده مورد غیرعادی چه بررسی‌هایی انجام دهیم.

SUID چیست؟

SUID مخفف:

Set User ID

است.

این Permission روی فایل‌های Executable قابل استفاده است.

در حالت عادی زمانی که یک User برنامه‌ای را اجرا می‌کند، Process با سطح دسترسی همان User اجرا می‌شود.

برای مثال:

User: kian

        |
        v

Application

        |
        v

Process runs as kian

اما اگر فایل دارای SUID باشد، Process می‌تواند با Effective User ID مربوط به Owner فایل اجرا شود.

اگر Owner فایل:

root

باشد:

User
  |
  v
SUID Executable
Owner: root
  |
  v
Effective UID: root

همین ویژگی باعث می‌شود فایل‌های SUID Root از نظر امنیتی اهمیت زیادی داشته باشند.

مثال معروف SUID در لینوکس

یکی از نمونه‌های رایج:

/usr/bin/passwd

است.

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

ls -l /usr/bin/passwd

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

-rwsr-xr-x 1 root root 68248 /usr/bin/passwd

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

rws

به‌جای:

rwx

حرف:

s

نشان می‌دهد بیت SUID فعال است.

مقدار عددی SUID چیست؟

Permissionهای معمول لینوکس را احتمالاً به شکل زیر دیده‌اید:

755
644
700

SUID یک Special Permission Bit است و مقدار Octal آن:

4000

است. مستندات Linux نیز S_ISUID را با مقدار 04000 تعریف می‌کنند.

برای مثال:

4755

یعنی:

4000 = SUID
0755 = rwxr-xr-x

آیا وجود SUID به معنی مشکل امنیتی است؟

خیر.

این یکی از مهم‌ترین نکات مقاله است.

وجود SUID روی Linux کاملاً طبیعی است.

برنامه‌های مختلف سیستم ممکن است برای عملکرد صحیح خود به این قابلیت نیاز داشته باشند.

بنابراین هدف ما این نیست که:

تمام فایل‌های SUID را حذف کنیم.

هدف این است که مشخص کنیم:

کدام فایل SUID انتظار می‌رود وجود داشته باشد و کدام مورد غیرمعمول است.

پیدا کردن تمام فایل‌های SUID

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

sudo find / -type f -perm -4000 2>/dev/null

این دستور کل Filesystem را بررسی می‌کند.

قسمت:

-type f

یعنی فقط Fileها بررسی شوند.

قسمت:

-perm -4000

فایل‌هایی را پیدا می‌کند که SUID Bit آنها Set شده است. در GNU find استفاده از -perm -MODE یعنی تمام Permission Bitهای مشخص‌شده در MODE روی فایل فعال باشند.

و:

2>/dev/null

پیغام‌های Error مانند Permission Denied را نمایش نمی‌دهد.

نمونه خروجی

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

/usr/bin/passwd
/usr/bin/su
/usr/bin/chsh
/usr/bin/chfn
/usr/bin/newgrp
/usr/bin/mount
/usr/bin/umount
/usr/bin/pkexec

بسته به Distribution، Version و Packageهای نصب‌شده، این لیست متفاوت خواهد بود.

بنابراین یک لیست ثابت و جهانی از SUIDهای «مجاز» وجود ندارد.

نمایش Permission و Owner هم‌زمان

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

sudo find / -type f -perm -4000 -exec ls -lh {} \; 2>/dev/null

نمونه:

-rwsr-xr-x 1 root root 68K /usr/bin/passwd

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

• Owner
• Group
• Permission
• Size
• Path

نمایش خروجی مرتب‌تر

می‌توانیم از find با -printf استفاده کنیم:

sudo find / -type f -perm -4000 \
-printf '%M %u %g %s %TY-%Tm-%Td %TH:%TM %p\n' 2>/dev/null

این خروجی اطلاعات مهمی مانند:

Permission
Owner
Group
Size
Modification Date
Path

را کنار یکدیگر نمایش می‌دهد.

این روش برای Audit مناسب‌تر است.

ذخیره لیست SUIDها

در بررسی امنیتی بهتر است نتیجه را ذخیره کنید:

sudo find / -type f -perm -4000 2>/dev/null > /root/suid-files.txt

سپس:

cat /root/suid-files.txt

را اجرا کنید.

این فایل را می‌توان بعداً با Scanهای قبلی مقایسه کرد.

پیدا کردن فایل‌های SGID

علاوه بر SUID، مکانیزم دیگری به نام:

SGID یا Set Group ID

نیز وجود دارد.

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

sudo find / -type f -perm -2000 2>/dev/null

مقدار Special Bit مربوط به SGID:

2000

است.

پیدا کردن SUID و SGID با یک دستور

برای پیدا کردن هر فایلی که یکی از این دو Special Bit را داشته باشد:

sudo find / -type f \( -perm -4000 -o -perm -2000 \) 2>/dev/null

این Command برای Security Audit کامل‌تر مفید است.

چگونه یک فایل SUID مشکوک را تشخیص دهیم؟

صرف وجود SUID کافی نیست.

باید چند ویژگی را بررسی کنیم.

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

محل قرارگیری فایل

است.

برای مثال وجود SUID روی فایل‌هایی داخل:

/usr/bin
/usr/sbin
/usr/lib

ممکن است مربوط به Package رسمی سیستم باشد.

اما فایل SUID در مسیرهایی مانند:

/tmp
/var/tmp
/dev/shm
/home
/opt
/srv

نیازمند بررسی بیشتری است.

این به معنی مخرب بودن قطعی فایل نیست؛ اما معمولاً SUID Executable غیرمنتظره در یک Directory موقت یا Home User باید جدی بررسی شود.

جستجوی SUID در /tmp

برای بررسی:

sudo find /tmp -type f -perm -4000 -ls 2>/dev/null

برای /var/tmp:

sudo find /var/tmp -type f -perm -4000 -ls 2>/dev/null

و:

sudo find /dev/shm -type f -perm -4000 -ls 2>/dev/null

در بسیاری از Serverها انتظار نداریم Executable SUID سفارشی در این Directoryها وجود داشته باشد.

بررسی Home Directoryها

برای پیدا کردن فایل SUID در /home:

sudo find /home -type f -perm -4000 -ls 2>/dev/null

اگر نتیجه‌ای مشاهده شد، بررسی کنید:

• فایل متعلق به چه Userی است؟
• چه زمانی ایجاد شده؟
• چرا SUID دارد؟
• از چه Package یا Applicationی آمده است؟

بررسی Owner فایل

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

ls -l /path/to/file

یا:

stat /path/to/file

مثلاً:

Access: (4755/-rwsr-xr-x)
Uid: (0/root)
Gid: (0/root)

اگر:

Uid: 0

باشد، Owner فایل Root است.

SUID Root طبیعتاً حساس‌تر از فایلی است که متعلق به User کم‌اختیار دیگری است.

مشاهده اطلاعات کامل فایل با stat

برای مثال:

stat /usr/bin/passwd

اطلاعاتی مانند:

• Size
• Owner
• Group
• Permission
• Inode
• Access Time
• Modification Time
• Change Time

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

برای فایل مشکوک این Timestampها می‌توانند در Timeline Incident مفید باشند.

بررسی نوع فایل

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

file /path/to/suspicious-file

مثلاً:

ELF 64-bit LSB pie executable

ممکن است نمایش داده شود.

اگر File Type با چیزی که انتظار دارید مطابقت ندارد، موضوع نیازمند بررسی بیشتر است.

بررسی زمان تغییر فایل

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

stat /path/to/file

یا برای پیدا کردن فایل‌های SUID تغییرکرده در هفت روز اخیر:

sudo find / -type f -perm -4000 -mtime -7 -ls 2>/dev/null

این روش مخصوصاً در Incident Response کاربرد دارد.

اگر Server اخیراً دچار مشکل شده و یک SUID ناشناس نیز در همان بازه زمانی ایجاد یا تغییر کرده باشد، این یک سرنخ مهم است.

پیدا کردن فایل‌های SUID جدید

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

مثلاً امروز:

sudo find / -type f -perm -4000 2>/dev/null | sort > /root/suid-current.txt

و قبلاً:

/root/suid-baseline.txt

داشته‌اید.

مقایسه:

diff /root/suid-baseline.txt /root/suid-current.txt

اگر فایلی جدید اضافه شده باشد، سریع مشخص می‌شود.

چرا Baseline اهمیت دارد؟

فرض کنید سیستم امروز 18 فایل SUID دارد.

یک ماه بعد:

19

مورد مشاهده شود.

این یک فایل جدید باید بررسی شود.

ممکن است کاملاً قانونی باشد و یک Package جدید آن را نصب کرده باشد.

اما ممکن است نتیجه:

• تغییر Configuration
• نصب Software ناشناخته
• Incident امنیتی

نیز باشد.

بنابراین Baseline بسیار مفیدتر از یک Scan منفرد است.

بررسی اینکه فایل متعلق به چه Packageای است

یکی از بهترین روش‌ها برای تشخیص فایل قانونی بررسی Package Manager است.

اگر فایل توسط Package رسمی سیستم نصب شده باشد، Package Manager معمولاً می‌تواند آن را شناسایی کند.

بررسی Package در Ubuntu و Debian

فرض کنیم فایل:

/usr/bin/passwd

است.

اجرا کنید:

dpkg -S /usr/bin/passwd

خروجی می‌تواند Package مربوط به فایل را مشخص کند.

اگر فایل ناشناخته‌ای توسط هیچ Package مدیریت نشود، موضوع ارزش بررسی بیشتری دارد.

البته Applicationهای Manual Install نیز ممکن است کاملاً قانونی باشند.

بررسی Integrity در Debian و Ubuntu

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

dpkg --verify PACKAGE_NAME

استفاده کرد.

برای مثال پس از مشخص شدن Package فایل، محتویات نصب‌شده را می‌توان با Metadata موجود در dpkg Database مقایسه کرد.

مستندات Debian توضیح می‌دهند که dpkg --verify Integrity فایل‌های Package را با Metadata ذخیره‌شده مقایسه می‌کند؛ در وضعیت فعلی این بررسی عمدتاً بر MD5 محتوا متکی است و خود Debian نیز تأکید می‌کند که این کار یک Integrity Check است، نه Security Verification کامل.

استفاده از debsums

در Debian و Ubuntu ابزار:

debsums

نیز مفید است.

نصب:

sudo apt install debsums

بررسی فایل‌های Package:

sudo debsums -s

گزینه:

-s

فقط فایل‌هایی را نمایش می‌دهد که Checksum آنها با مقدار مورد انتظار تطابق ندارد.

Debian، debsums را ابزاری برای مقایسه فایل‌های Package نصب‌شده با MD5 checksumهای ثبت‌شده معرفی می‌کند.

بررسی Package در AlmaLinux و Rocky Linux

در سیستم‌های RPM-based ابتدا مشخص کنید فایل متعلق به چه Package است:

rpm -qf /usr/bin/passwd

سپس Package را Verify کنید:

rpm -V PACKAGE_NAME

برای مثال:

rpm -V passwd

RPM هنگام Verify می‌تواند اطلاعات فایل نصب‌شده را با Metadata موجود در RPM Database مقایسه کند؛ از جمله مواردی مانند Size، Digest، Permission، Type، Owner و Group.

بررسی تمام Packageها با RPM

برای Audit گسترده‌تر:

sudo rpm -Va

این Command تمام Packageهای نصب‌شده را Verify می‌کند.

اما خروجی آن ممکن است زیاد باشد و هر اختلافی الزاماً امنیتی نیست.

Configuration Fileهایی که عمداً تغییر داده شده‌اند نیز ممکن است در خروجی دیده شوند.

بررسی Hash فایل مشکوک

قبل از حذف یا تغییر فایل مشکوک، Hash آن را ثبت کنید.

برای SHA-256:

sha256sum /path/to/suspicious-file

برای مثال:

c7f... /tmp/suspicious

Hash برای:

• مستندسازی Incident
• مقایسه فایل
• بررسی Threat Intelligence
• مقایسه با Serverهای دیگر

کاربرد دارد.

بررسی Strings فایل

برای بررسی ابتدایی Binary می‌توانید از:

strings /path/to/file | less

استفاده کنید.

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

• Path
• Domain
• IP
• Error Message
• Library Name

را نمایش دهد.

اما خروجی strings به‌تنهایی مبنای تشخیص Malware نیست.

بررسی Libraryهای فایل

برای Binaryهای Dynamic:

ldd /path/to/file

می‌تواند Shared Libraryهای مورد استفاده را نمایش دهد.

در Incident Response باید با فایل ناشناس احتیاط کرد و از اجرای مستقیم Binary برای «دیدن اینکه چه می‌کند» خودداری کرد.

فایل مشکوک را اجرا نکنید

اگر یک فایل SUID ناشناس پیدا کردید:

DO NOT RUN IT

نباید صرفاً برای تست آن را اجرا کنید.

به‌خصوص اگر Owner:

root

باشد.

اجرای فایل ناشناس می‌تواند:

• Payload اجرا کند.
• فایل‌ها را تغییر دهد.
• Network Connection ایجاد کند.
• Evidence را تخریب کند.

برای بررسی عمیق‌تر بهتر است از روش‌های Static Analysis یا محیط جداشده استفاده شود.

بررسی Permission فایل

اجرا کنید:

stat -c '%A %a %U %G %n' /path/to/file

نمونه:

-rwsr-xr-x 4755 root root /usr/bin/passwd

اگر فایل علاوه بر SUID دارای Permissionهای نامناسبی مانند Writable بودن برای Group یا Other باشد، وضعیت حساس‌تر می‌شود.

پیدا کردن SUIDهایی که World-Writable هستند

برای بررسی فایل‌هایی که هم SUID دارند و هم توسط Other قابل نوشتن هستند:

sudo find / -type f -perm -4000 -perm -0002 -ls 2>/dev/null

این وضعیت بسیار غیرمعمول است و باید فوراً بررسی شود.

پیدا کردن SUIDهایی که Group-Writable هستند

برای Group Writable:

sudo find / -type f -perm -4000 -perm -0020 -ls 2>/dev/null

باز هم باید بررسی شود که آیا این Permission عمداً تنظیم شده است یا خیر.

بررسی Directory والد

فقط Permission خود فایل اهمیت ندارد.

Directoryهای والد نیز باید بررسی شوند.

برای مثال:

namei -l /path/to/suspicious-file

این Command Permission تمام اجزای Path را نمایش می‌دهد.

اگر یک فایل SUID Root داخل Directoryای قرار داشته باشد که User عادی بتواند محتوای آن را جایگزین کند، موضوع بسیار حساس است.

بررسی File Capabilities

SUID تنها مکانیزم اعطای Privilege به Executableها نیست.

Linux از:

File Capabilities

نیز پشتیبانی می‌کند.

File Capability می‌تواند بخشی از Privilegeهای Root را به یک برنامه بدهد، بدون اینکه برنامه تمام قدرت Root را داشته باشد. Linux از نسخه‌های جدیدتر Kernel امکان ذخیره Capability روی Executable را از طریق Extended Attribute مربوط به security.capability فراهم می‌کند.

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

getcap -r / 2>/dev/null

دستور getcap برای مشاهده File Capabilityها طراحی شده و گزینه -r جستجوی Recursive را فعال می‌کند.

چرا File Capabilities را هم بررسی کنیم؟

ممکن است یک فایل:

SUID

نداشته باشد، اما Capability حساسی داشته باشد.

برای مثال Capabilityهایی که اجازه عملیات سطح بالاتری می‌دهند باید بررسی شوند.

بنابراین در Security Audit بهتر است هر دو را بررسی کنیم:

SUID / SGID

و:

File Capabilities

بررسی Capability یک فایل

برای یک فایل مشخص:

getcap /path/to/file

برای کل سیستم:

sudo getcap -r / 2>/dev/null

نتایج غیرمنتظره باید مانند SUIDها با Baseline و Package Manager مقایسه شوند.

فایل SUID مشکوک پیدا کردیم؛ چه کنیم؟

اگر فایلی واقعاً مشکوک است، اولین اقدام نباید حذف فوری آن باشد.

ابتدا Evidence را ثبت کنید.

مثلاً:

stat /path/to/file

sha256sum /path/to/file

file /path/to/file

ls -lah /path/to/file

و Package Ownership را نیز بررسی کنید.

آیا SUID را فوراً حذف کنیم؟

اگر Incident در حال بررسی است، حذف فوری فایل ممکن است Evidence را از بین ببرد.

اگر لازم است خطر فوری کاهش پیدا کند و فرآیند Incident Response سازمان اجازه می‌دهد، می‌توان بعد از ثبت Evidence بیت SUID را برداشت.

Command مربوط به حذف SUID:

chmod u-s /path/to/file

مستندات GNU نیز u+s و u-s را برای تنظیم و حذف Set-user-ID Bit تعریف می‌کنند.

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

ممکن است Application یا سیستم‌عامل را دچار مشکل کنید.

قبل از تغییر Permission چه چیزی را بررسی کنیم؟

قبل از اجرای:

chmod u-s FILE

مشخص کنید:

• فایل مربوط به چه Package است؟
• SUID آن بخشی از نصب رسمی Package است؟
• Service وابسته به آن چیست؟
• آیا Server در Incident فعال قرار دارد؟
• آیا Evidence لازم ذخیره شده است؟
• آیا نسخه سالم فایل در Package Repository وجود دارد؟

اگر فایل Package رسمی تغییر کرده باشد چه کنیم؟

فرض کنید:

/usr/bin/example

متعلق به Package رسمی است اما Integrity Verification نشان می‌دهد فایل تغییر کرده است.

این وضعیت باید جدی بررسی شود.

در Incident تأییدشده معمولاً صرفاً Reinstall کردن یک فایل کافی نیست.

باید Scope حادثه بررسی شود:

چه Userی فایل را تغییر داده؟
چه زمانی؟
چگونه Privilege گرفته شده؟
چه فایل‌های دیگری تغییر کرده‌اند؟
Persistence وجود دارد؟
Credentialها افشا شده‌اند؟

بررسی Timeline

برای فایل مشکوک:

stat /path/to/file

Timestampهای فایل را با موارد زیر مقایسه کنید:

• Authentication Logs
• sudo Logs
• Web Server Logs
• Package Manager Logs
• systemd Journal
• Deployment History

برای مثال در Debian/Ubuntu:

less /var/log/apt/history.log

می‌تواند مشخص کند آیا Package مربوطه در همان زمان نصب یا Upgrade شده است.

بررسی فایل‌های SUID تغییرکرده در زمان Incident

اگر زمان تقریبی Incident را می‌دانید:

sudo find / -type f -perm -4000 -newermt "2026-09-10 00:00" -ls 2>/dev/null

این روش فایل‌هایی را پیدا می‌کند که بعد از زمان مشخص‌شده تغییر کرده‌اند.

برای Investigation Timeline بسیار مفید است.

مانیتور کردن تغییرات Permission

برای محیط‌های حساس بهتر است تغییر Permissionها مانیتور شوند.

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

auditd
AIDE
Wazuh
EDR
File Integrity Monitoring

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

هدف این است که ایجاد SUID جدید فقط در Audit دوره‌ای ماه بعد دیده نشود، بلکه در صورت امکان همان زمان Alert ایجاد شود.

یک Workflow عملی برای بررسی SUID

فرض کنید می‌خواهیم Server را Audit کنیم.

مرحله اول: استخراج تمام SUIDها

sudo find / -type f -perm -4000 2>/dev/null | sort > /root/suid-current.txt

مرحله دوم: مشاهده جزئیات

sudo find / -type f -perm -4000 \
-printf '%M %u %g %s %TY-%Tm-%Td %TH:%TM %p\n' 2>/dev/null

مرحله سوم: بررسی مسیرهای غیرمعمول

sudo find /tmp /var/tmp /dev/shm /home /opt /srv \
-type f -perm -4000 -ls 2>/dev/null

مرحله چهارم: بررسی فایل مشکوک

stat /path/to/file

file /path/to/file

sha256sum /path/to/file

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

در Debian/Ubuntu:

dpkg -S /path/to/file

در AlmaLinux/Rocky:

rpm -qf /path/to/file

مرحله ششم: Verify Package

Debian/Ubuntu:

dpkg --verify PACKAGE

یا:

debsums PACKAGE

RPM-based:

rpm -V PACKAGE

مرحله هفتم: بررسی Capabilities

sudo getcap -r / 2>/dev/null

مرحله هشتم: مقایسه با Baseline

diff /root/suid-baseline.txt /root/suid-current.txt

آیا هر SUID غیرسیستمی مخرب است؟

خیر.

ممکن است Application اختصاصی سازمان عمداً یک SUID Binary داشته باشد.

در چنین شرایطی باید مشخص باشد:

• Developer آن چه کسی است؟
• چرا SUID لازم است؟
• Source Code آن Review شده؟
• Owner و Permission صحیح هستند؟
• آیا جایگزین امن‌تری وجود دارد؟
• فایل در Configuration Management ثبت شده است؟

مشکل اصلی فایل:

Custom SUID

نیست.

مشکل:

Unknown Custom SUID

است.

اصل Least Privilege و SUID

SUID باید فقط زمانی استفاده شود که واقعاً لازم باشد.

هر برنامه SUID Root سطح Attack Surface را افزایش می‌دهد.

بنابراین اگر Application بدون SUID نیز کار می‌کند، نگه داشتن آن توجیهی ندارد.

در طراحی‌های جدیدتر، File Capabilities یا جداسازی وظایف گاهی می‌توانند دسترسی محدودتری نسبت به SUID Root ایجاد کنند.

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

برخی اشتباهات رایج در بررسی فایل‌های SUID عبارت‌اند از:

• تصور اینکه تمام SUIDها Malware هستند.
• حذف SUID فایل‌های سیستمی بدون بررسی.
• بررسی نکردن Package Owner فایل.
• توجه نکردن به مسیر فایل.
• بررسی نکردن Owner و Group.
• نادیده گرفتن Timestamp فایل.
• اجرا کردن Binary ناشناس برای آزمایش.
• حذف فایل قبل از حفظ Evidence.
• بررسی نکردن File Capabilities.
• نداشتن Baseline از SUIDهای سیستم.
• توجه نکردن به World-Writable یا Group-Writable بودن فایل.
• بررسی نکردن Directoryهای والد.

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

برای مدیریت امن SUIDها:

• فهرست SUIDهای سیستم را تهیه کنید.
• یک Baseline ایجاد کنید.
• تغییرات را به‌صورت دوره‌ای مقایسه کنید.
• مسیرهای غیرمعمول را جداگانه بررسی کنید.
• Owner و Permission فایل‌ها را کنترل کنید.
• Package Ownership را مشخص کنید.
• Integrity فایل‌های Package را Verify کنید.
• Hash فایل مشکوک را ثبت کنید.
• فایل ناشناس را اجرا نکنید.
• File Capabilities را نیز بررسی کنید.
• SUIDهای غیرضروری را پس از بررسی حذف کنید.
• تغییر Permissionهای حساس را مانیتور کنید.
• از Least Privilege استفاده کنید.

چک‌لیست

هنگام بررسی SUID روی Linux Server موارد زیر را کنترل کنید:

• تمام فایل‌های SUID استخراج شده‌اند.
• فایل‌های SGID نیز بررسی شده‌اند.
• مسیرهای /tmp و /var/tmp بررسی شده‌اند.
• /dev/shm بررسی شده است.
• Home Directoryها بررسی شده‌اند.
• Owner تمام موارد غیرمعمول مشخص شده است.
• Permission فایل‌های مشکوک بررسی شده است.
• Timestampها بررسی شده‌اند.
• Hash فایل‌های مشکوک ثبت شده است.
• Package مربوط به فایل مشخص شده است.
• Integrity Package بررسی شده است.
• World-Writable SUIDها بررسی شده‌اند.
• Group-Writable SUIDها بررسی شده‌اند.
• Directoryهای والد بررسی شده‌اند.
• File Capabilities بررسی شده‌اند.
• نتایج با Baseline مقایسه شده‌اند.
• فایل ناشناس قبل از بررسی اجرا نشده است.
• Evidence قبل از حذف یا تغییر فایل ذخیره شده است.

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

برای مطالعه بیشتر درباره SUID، Permissionهای خاص لینوکس، find و File Capabilities می‌توانید منابع زیر را بررسی کنید:

• Linux chmod – Set-user-ID و Set-group-ID
  توضیح رسمی File Mode Bitها و نحوه عملکرد SUID و SGID.
  Linux chmod manual
• GNU Coreutils – File Mode Bits
  توضیح Set-user-ID، Set-group-ID و سایر Permission Bitهای ویژه.
  GNU Coreutils Mode Structure
• GNU Findutils – Mode Bits
  مرجع رسمی نحوه استفاده از -perm در دستور find برای جستجوی Permissionهای خاص.
  GNU Findutils Mode Bits
• Linux Capabilities
  توضیح رسمی Capabilityها و File Capability در Linux.
  Linux capabilities manual
• getcap
  مستندات دستور getcap برای مشاهده File Capabilityها.
  getcap manual
• Debian Package Verification
  راهنمای Debian برای بررسی Integrity فایل‌های نصب‌شده توسط Package Manager.
  Debian Package Management Reference
• RPM Package Verification
  مستندات رسمی RPM برای Verify کردن فایل‌های Package و بررسی Permission، Owner، Digest و سایر Metadataها.
  RPM Manual

جمع‌بندی

SUID یکی از قابلیت‌های مهم Permission Management در Linux است که اجازه می‌دهد یک Executable هنگام اجرا با Effective User ID متعلق به Owner فایل فعالیت کند.

این قابلیت برای بعضی ابزارهای سیستم ضروری است و وجود SUID به‌خودی‌خود نشانه آلودگی نیست.

برای پیدا کردن فایل‌های SUID می‌توان از:

sudo find / -type f -perm -4000 2>/dev/null

استفاده کرد.

اما مرحله مهم‌تر بعد از پیدا کردن فایل‌ها آغاز می‌شود.

برای هر مورد غیرمنتظره باید مواردی مانند:

Path
Owner
Permission
Timestamp
Package
Hash
Integrity

بررسی شوند.

به‌خصوص وجود SUID Root در مسیرهایی مانند:

/tmp
/var/tmp
/dev/shm
/home

یا روی فایل‌های ناشناخته باید بررسی شود.

Package Manager نیز ابزار مهمی برای تشخیص فایل قانونی از فایل غیرمنتظره است.

در Debian و Ubuntu:

dpkg -S /path/to/file

و در سیستم‌های RPM-based:

rpm -qf /path/to/file

می‌تواند مشخص کند فایل متعلق به کدام Package است.

همچنین Security Audit نباید فقط به SUID محدود باشد. File Capabilityها نیز می‌توانند Privilegeهای مهمی به Executableها بدهند و با:

sudo getcap -r / 2>/dev/null

قابل بررسی هستند.

در نهایت، مؤثرترین روش برای شناسایی فایل SUID مشکوک داشتن Baseline است. اگر فهرست SUIDهای سالم Server از قبل ثبت شده باشد، اضافه شدن یک فایل جدید خیلی سریع قابل تشخیص خواهد بود.

هدف این نیست که تمام SUIDها حذف شوند؛ هدف این است که روی سرور هیچ SUID ناشناخته، غیرضروری یا تغییرکرده‌ای بدون بررسی باقی نماند.

کیان پور