مقدمه

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

پس از نفوذ ممکن است فایل‌های مختلفی روی سیستم تغییر کنند؛ برای مثال:

Web Shell
Malicious Script
Modified Configuration
systemd Service
Cron Job
SSH Key
Executable
Shared Library
Startup Script

بنابراین یکی از مهم‌ترین مراحل Incident Response این است که مشخص کنیم:

در بازه زمانی مشکوک چه فایل‌هایی روی سرور ایجاد یا تغییر کرده‌اند؟

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

find
stat
file
sha256sum
rpm
dpkg
lsof
ausearch

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

در این مقاله روش پیدا کردن فایل‌های تغییرکرده، بررسی Metadata، Hash، Owner، Permission، Package Integrity، فایل‌های حذف‌شده ولی همچنان باز و ساخت Timeline اولیه را بررسی می‌کنیم.

چرا فایل‌های تغییرکرده مهم هستند؟

فرض کنید روی سرور در ساعت 03:20 یک Login غیرمجاز مشاهده شده است.

اگر بتوانیم فایل‌های تغییرکرده بین:

03:15
تا
03:45

را استخراج کنیم، ممکن است مواردی مانند:

/etc/systemd/system/update.service
/tmp/.cache
/root/.ssh/authorized_keys
/var/www/html/index.php
/usr/local/bin/helper

پیدا شوند.

این اطلاعات می‌توانند Timeline حمله را بسیار محدودتر کنند.

اما:

هر فایل تغییرکرده‌ای الزاماً مخرب نیست.

Update سیستم، Deploy وب‌سایت، Backup، Log Rotation و فعالیت‌های مدیریتی نیز فایل‌ها را تغییر می‌دهند.

Timestampهای فایل در لینوکس

برای بررسی صحیح فایل‌ها ابتدا باید تفاوت Timestampهای مختلف را بدانیم.

معمولاً سه Timestamp اصلی وجود دارد:

atime
mtime
ctime

و بعضی File Systemها ممکن است Birth Time یا Creation Time نیز ارائه کنند. GNU Coreutils، mtime را زمان آخرین تغییر محتوای فایل و ctime را زمان آخرین تغییر وضعیت یا Metadata فایل تعریف می‌کند؛ تغییر Permission یا Rename می‌تواند ctime را تغییر دهد بدون اینکه الزاماً محتوای فایل تغییر کند.

mtime چیست؟

mtime یا:

Modification Time

آخرین زمانی است که محتوای فایل تغییر کرده است.

برای مثال:

echo "test" >> example.txt

محتوای فایل را تغییر می‌دهد و در نتیجه mtime تغییر می‌کند.

ctime چیست؟

ctime به معنی Creation Time نیست.

ctime در سیستم‌های Unix-like معمولاً:

Change Time

است.

یعنی زمانی که وضعیت inode یا Metadata تغییر کرده است.

برای مثال تغییر:

Permission
Owner
Group
Link

می‌تواند ctime را تغییر دهد.

بنابراین اگر مهاجم Permission فایل را تغییر دهد ولی Content را دست نزند، ممکن است mtime ثابت بماند اما ctime تغییر کند.

atime چیست؟

atime نشان می‌دهد فایل آخرین بار چه زمانی Access شده است.

مثلاً خواندن فایل می‌تواند atime را تغییر دهد.

اما در بسیاری از سیستم‌ها Mount Optionهایی مانند:

relatime
noatime

باعث می‌شوند atime برای Forensics به اندازه mtime و ctime قابل اتکا نباشد.

Birth Time چیست؟

برخی File Systemها Creation Time یا:

Birth Time

را نگهداری می‌کنند، اما پشتیبانی از آن وابسته به File System و سیستم است؛ حتی در سیستم‌های پشتیبانی‌کننده ممکن است برای بعضی فایل‌ها مقدار Birth Time موجود نباشد.

بنابراین نباید فرض کنیم تمام Linux Serverها Creation Time قابل اعتماد دارند.

مشاهده تمام Timestampهای یک فایل

برای بررسی دقیق یک فایل:

stat /path/to/file

مثلاً:

stat /etc/ssh/sshd_config

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

Size
Blocks
Access
Uid
Gid
Access Time
Modify Time
Change Time
Birth Time

است.

مرحله اول: فایل‌های تغییرکرده در چند روز اخیر

برای پیدا کردن تمام فایل‌هایی که در ۷ روز اخیر تغییر محتوایی داشته‌اند:

find / -type f -mtime -7 2>/dev/null

اما جستجوی کل / ممکن است روی Server بزرگ زمان‌بر باشد.

بهتر است ابتدا Directoryهای مهم را محدود کنیم.

مثلاً:

find /etc /usr/local /var/www /root /home \
-type f \
-mtime -7 \
2>/dev/null

مفهوم -mtime را درست درک کنیم

در GNU find، گزینه‌های زمانی مانند:

-mtime
-ctime
-atime

براساس دوره‌های ۲۴ ساعته محاسبه می‌شوند و مقدار آنها Round Down می‌شود؛ گزینه‌های -mmin، -cmin و -amin برای بررسی دقیق‌تر در سطح دقیقه مناسب‌تر هستند.

بنابراین:

find /etc -type f -mtime -1

به معنای دقیق «از نیمه‌شب امروز» نیست.

فایل‌های تغییرکرده در چند ساعت اخیر

برای Incidentهای جدید بهتر است از دقیقه استفاده کنیم.

مثلاً فایل‌های تغییرکرده طی ۲ ساعت اخیر:

find /etc /var/www /root /home \
-type f \
-mmin -120 \
2>/dev/null

۳۰ دقیقه اخیر:

find /etc /var/www \
-type f \
-mmin -30 \
2>/dev/null

بررسی ctime

فایل‌هایی که Metadata آنها طی ۲ ساعت اخیر تغییر کرده:

find /etc /var/www /root /home \
-type f \
-cmin -120 \
2>/dev/null

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

Permission
Owner
Group

آنها اخیراً تغییر کرده است.

بررسی mtime و ctime با هم

برای Triage سریع:

echo "=== MTIME ==="

find /etc /var/www /root /home \
-type f \
-mmin -120 \
-ls 2>/dev/null

echo
echo "=== CTIME ==="

find /etc /var/www /root /home \
-type f \
-cmin -120 \
-ls 2>/dev/null

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

در Incident Response معمولاً Timeline مشخصی داریم.

مثلاً:

شروع Incident:
2026-09-26 02:10

پایان فعالیت مشکوک:
2026-09-26 03:00

در GNU find می‌توان از -newermt استفاده کرد.

فایل‌هایی که بعد از ساعت 02:10 تغییر کرده‌اند:

find /etc /var/www /root /home \
-type f \
-newermt "2026-09-26 02:10:00" \
2>/dev/null

تعیین ابتدا و انتهای Timeline

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

find /etc /var/www /root /home \
-type f \
-newermt "2026-09-26 02:10:00" \
! -newermt "2026-09-26 03:00:00" \
2>/dev/null

این روش برای Investigation بسیار کاربردی‌تر از:

-mtime -1

است.

استفاده از Reference File

روش دیگر ساخت دو Reference File است.

touch -d "2026-09-26 02:10:00" /tmp/start_time
touch -d "2026-09-26 03:00:00" /tmp/end_time

سپس:

find /etc /var/www /root /home \
-type f \
-newer /tmp/start_time \
! -newer /tmp/end_time \
2>/dev/null

خروجی را همراه Timestamp نمایش دهیم

برای Investigation بهتر است فقط Filename نمایش داده نشود.

مثلاً:

find /etc /var/www /root /home \
-type f \
-mtime -7 \
-printf '%TY-%Tm-%Td %TH:%TM:%TS %u %g %m %s %p\n' \
2>/dev/null |
sort

خروجی شامل:

Date
Time
Owner
Group
Permission
Size
Path

خواهد بود.

GNU find از Format Directiveهای زمان برای -printf پشتیبانی می‌کند.

مرتب کردن فایل‌ها براساس Timeline

برای مثال:

find /etc /var/www /root /home \
-type f \
-printf '%T@ %TY-%Tm-%Td %TH:%TM:%TS %p\n' \
2>/dev/null |
sort -n

این خروجی می‌تواند یک Timeline اولیه از Modificationها ایجاد کند.

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

در Security Investigation بعضی Directoryها اهمیت بیشتری دارند.

از جمله:

/etc
/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin
/var/www
/root
/home
/tmp
/var/tmp
/dev/shm
/opt

فایل‌های اخیر در /etc

find /etc \
-type f \
-mtime -7 \
-ls 2>/dev/null

تغییر فایل‌هایی مانند:

/etc/passwd
/etc/shadow
/etc/group
/etc/sudoers
/etc/ssh/sshd_config

اهمیت ویژه‌ای دارد.

فایل‌های اخیر systemd

find /etc/systemd/system \
-type f \
-mtime -7 \
-ls 2>/dev/null

در کنار آن:

find /etc/systemd/system \
-type l \
-ctime -7 \
-ls 2>/dev/null

Symlink جدید می‌تواند نشان‌دهنده Enable شدن Service باشد.

فایل‌های Cron

find /etc/cron.d \
/etc/cron.daily \
/etc/cron.hourly \
/etc/cron.weekly \
-type f \
-mtime -7 \
-ls 2>/dev/null

همچنین Crontab کاربران:

find /var/spool/cron \
/var/spool/cron/crontabs \
-type f \
-mtime -7 \
-ls 2>/dev/null

ممکن است برخی مسیرها روی Distribution شما وجود نداشته باشند.

فایل‌های SSH

find /root /home \
-path '*/.ssh/*' \
-type f \
-mtime -7 \
-ls 2>/dev/null

به‌خصوص:

authorized_keys
config
known_hosts

را با Baseline مقایسه کنید.

فایل‌های وب

اگر Server وب است:

find /var/www \
-type f \
-mtime -7 \
-ls 2>/dev/null

برای PHP:

find /var/www \
-type f \
-name "*.php" \
-mtime -7 \
-ls 2>/dev/null

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

مهاجم یا Application ممکن است فایل‌های موقت در مسیرهایی مانند:

/tmp
/var/tmp
/dev/shm

ایجاد کند.

برای مشاهده فایل‌های اخیر:

find /tmp /var/tmp /dev/shm \
-type f \
-mtime -7 \
-ls 2>/dev/null

Executableهای موجود در مسیرهای موقت

برای بررسی فایل‌هایی که Execute Bit دارند:

find /tmp /var/tmp /dev/shm \
-type f \
-perm /111 \
-ls 2>/dev/null

وجود Executable در این مسیرها به‌تنهایی اثبات حمله نیست، اما باید بررسی شود.

فایل‌های مخفی

برای فایل‌های مخفی:

find /tmp /var/tmp /dev/shm /root /home \
-type f \
-name ".*" \
-ls 2>/dev/null

و فایل‌های مخفی تغییرکرده اخیر:

find /tmp /var/tmp /dev/shm /root /home \
-type f \
-name ".*" \
-mtime -7 \
-ls 2>/dev/null

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

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

/tmp/.update

مشکوک است.

ابتدا:

stat /tmp/.update

سپس:

ls -lah /tmp/.update

و:

file /tmp/.update

این مراحل مشخص می‌کنند:

Owner
Group
Permission
Size
File Type
Timestamps

چیست.

نوع واقعی فایل را بررسی کنیم

به Filename اعتماد نکنید.

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

image.jpg

در واقع Executable یا Script باشد.

بررسی:

file image.jpg

برای بررسی چند فایل:

file /path/to/files/*

مرحله چهارم: Hash فایل را ثبت کنید

برای ثبت Fingerprint فایل:

sha256sum /tmp/.update

sha256sum یک SHA-256 Digest از محتوای فایل محاسبه می‌کند و می‌تواند برای مقایسه فایل با Baseline استفاده شود.

مثلاً:

f82c...  /tmp/.update

Hash را در Incident Record ذخیره کنید.

چرا SHA256؟

برای Integrity Checking بهتر است از Algorithmهای SHA-2 مانند:

SHA-256
SHA-512

به جای SHA-1 یا MD5 برای کاربردهای امنیتی جدید استفاده شود؛ GNU نیز SHA-1 و MD5 را برای مقابله با دستکاری مخرب توصیه نمی‌کند و SHA-2 یا Algorithmهای جدیدتر را ترجیح می‌دهد.

Hash چند فایل را همزمان بگیریم

مثلاً:

find /etc/systemd/system \
-type f \
-mtime -7 \
-exec sha256sum {} \;

یا Web Root:

find /var/www \
-type f \
-name "*.php" \
-mtime -7 \
-exec sha256sum {} \;

مرحله پنجم: Owner و Permission را بررسی کنیم

برای پیدا کردن فایل‌های World-Writable:

find /etc /usr /var/www \
-type f \
-perm -0002 \
-ls 2>/dev/null

برای Executableهای World-Writable:

find /usr /opt /var/www \
-type f \
-perm -0002 \
-perm /111 \
-ls 2>/dev/null

چنین فایل‌هایی باید دلیل مشخصی داشته باشند.

فایل‌هایی که Owner ندارند

گاهی User حذف شده ولی فایل‌ها باقی مانده‌اند.

برای پیدا کردن:

find / \
-type f \
-nouser \
-ls 2>/dev/null

Group نامعتبر:

find / \
-type f \
-nogroup \
-ls 2>/dev/null

این موارد به‌تنهایی مخرب نیستند، اما در Audit ارزش بررسی دارند.

فایل‌های متعلق به User خاص

فرض کنید Incident به User:

www-data

مرتبط است.

find /var/www /tmp /var/tmp \
-type f \
-user www-data \
-ls 2>/dev/null

یا برای فایل‌های اخیر:

find /var/www /tmp /var/tmp \
-type f \
-user www-data \
-mtime -7 \
-ls 2>/dev/null

مرحله ششم: فایل‌های SUID و SGID تغییرکرده

فایل‌های SUID:

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

اگر می‌خواهیم فقط موارد اخیر را ببینیم:

find / \
-type f \
-perm -4000 \
-ctime -7 \
-ls 2>/dev/null

برای SGID:

find / \
-type f \
-perm -2000 \
-ctime -7 \
-ls 2>/dev/null

تغییر Permission معمولاً ctime را تغییر می‌دهد، بنابراین در این مورد ctime اهمیت زیادی دارد.

File Capabilityها را بررسی کنیم

در سیستم‌هایی که getcap موجود است:

getcap -r / 2>/dev/null

اگر فایلی اخیراً Capability غیرمنتظره گرفته باشد، باید با Baseline مقایسه شود.

مرحله هفتم: فایل متعلق به کدام Package است؟

یکی از بهترین روش‌های بررسی فایل سیستمی، مقایسه آن با Package Manager است.

Debian و Ubuntu

برای پیدا کردن Package مالک فایل:

dpkg -S /usr/bin/example

سپس:

dpkg -V package-name

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

بررسی همه Packageها با dpkg

dpkg -V

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

Debian Handbook نیز هشدار می‌دهد که Database محلی dpkg روی همان Disk قرار دارد و مهاجم با دسترسی کافی می‌تواند آن را نیز دستکاری کند؛ بنابراین این روش باید یکی از چند منبع Evidence باشد، نه تنها معیار اعتماد.

AlmaLinux، Rocky و RHEL

برای پیدا کردن Package مالک فایل:

rpm -qf /usr/bin/example

سپس:

rpm -V package-name

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

Verify تمام Packageهای RPM

rpm -Va

روی Server بزرگ خروجی ممکن است بسیار زیاد باشد.

برای ذخیره:

rpm -Va > /root/rpm-verify.txt

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

مثال ساده RPM Verify

اگر Binary سیستمی تغییر کرده باشد، rpm -V می‌تواند اختلاف بین نسخه فعلی و Metadata Package را گزارش کند.

اما تغییر همیشه مخرب نیست.

برای مثال Configurationهای:

/etc/...

ممکن است عمداً توسط Administrator تغییر کرده باشند.

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

اگر:

rpm -qf /path/to/file

نتیجه دهد فایل متعلق به Package نیست، این موضوع الزاماً مشکوک نیست.

فایل‌های موجود در:

/usr/local/
/opt/
/var/www/
/home/

اغلب دستی یا توسط Application نصب می‌شوند.

اما Executable ناشناخته در:

/usr/bin
/usr/sbin
/lib

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

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

بهترین Detection زمانی انجام می‌شود که وضعیت سالم قبلی Server را داشته باشیم.

Baseline می‌تواند شامل:

File Path
Hash
Permission
Owner
Group
Size
mtime

باشد.

برای مثال:

find /etc /usr/local/bin \
-type f \
-exec sha256sum {} \; \
> baseline.sha256

بعداً:

sha256sum -c baseline.sha256

می‌تواند تغییر محتوا را مشخص کند.

محدودیت Baseline

اگر Baseline بعد از Compromise ساخته شده باشد، ارزش امنیتی محدودی دارد.

همچنین Database یا Hash List بهتر است روی سیستم مستقلی نگهداری شود، زیرا مهاجم دارای Root Access ممکن است Baseline محلی را نیز تغییر دهد.

استفاده از AIDE

AIDE یا:

Advanced Intrusion Detection Environment

ابزاری برای File Integrity Checking است.

AIDE می‌تواند Database‌ای از File Attributeها بسازد؛ از جمله:

Permission
Owner
Group
Size
mtime
ctime
inode
Hash

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

AIDE چه مزیتی دارد؟

به‌جای اجرای دستی تعداد زیادی Command می‌توان Baseline فایل‌های مهم را از قبل ثبت کرد.

سپس در Auditهای بعدی تغییرات:

Added
Removed
Changed

قابل شناسایی خواهند بود.

AIDE بیشترین ارزش را زمانی دارد که قبل از Incident پیکربندی شده باشد.

مرحله نهم: فایل‌های حذف‌شده ولی همچنان باز

در Linux ممکن است Process یک فایل را باز کرده باشد و سپس همان فایل از File System حذف شود.

Process می‌تواند تا زمانی که File Descriptor باز است همچنان به محتوای فایل دسترسی داشته باشد.

برای بررسی:

lsof +L1

lsof با +L1 فایل‌های باز با Link Count کمتر از ۱ را انتخاب می‌کند؛ این روش برای پیدا کردن فایل‌های Unlinked ولی همچنان Open کاربرد دارد.

روش ساده‌تر

lsof | grep '(deleted)'

ممکن است خروجی مانند:

process  PID user ... /tmp/example (deleted)

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

این وضعیت می‌تواند کاملاً طبیعی باشد، مثلاً بعد از Update یک Service.

اما Process ناشناس با Executable حذف‌شده باید بررسی شود.

Executable حذف‌شده Process

برای PID مشکوک:

ls -l /proc/PID/exe

ممکن است مشاهده کنید:

/path/to/file (deleted)

Command Line:

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

Parent:

grep PPid /proc/PID/status

و Connection:

ss -plant

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

مرحله دهم: Processهای مرتبط با فایل را پیدا کنیم

اگر فایل:

/opt/app/example

مشکوک است:

lsof /opt/app/example

lsof برای نمایش Fileهایی که توسط Processها باز هستند طراحی شده و می‌تواند براساس Path یک فایل مشخص Query شود.

پردازش‌های فعلی

ps auxf

یا:

pstree -ap

برای PID مشخص:

ps -fp PID

سپس:

readlink -f /proc/PID/exe

مرحله یازدهم: Network Connection را بررسی کنیم

اگر Executable ناشناس در حال اجراست:

ss -plant

Connection خارجی آن را پیدا کنید.

Correlation زیر ارزش زیادی دارد:

Recently Modified File
        +
Running Process
        +
External Connection

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

Timeline File System را باید با Logهای Server تطبیق دهید.

برای مثال:

journalctl --since "2026-09-26 02:00:00" \
             --until "2026-09-26 04:00:00"

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

SSH Login
sudo
systemd
Cron
Package Update
Web Request

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

Package Updateها را بررسی کنیم

قبل از مشکوک دانستن فایل سیستمی، بررسی کنید Package Update انجام نشده باشد.

Ubuntu/Debian:

grep -i "upgrade\|install" \
/var/log/dpkg.log

و فایل‌های Rotate شده را نیز در صورت نیاز بررسی کنید.

RHEL / AlmaLinux / Rocky

می‌توان DNF History را بررسی کرد:

dnf history

سپس Transaction مربوط به بازه Incident را با تغییر فایل‌ها مقایسه کنید.

مرحله سیزدهم: استفاده از auditd

اگر Linux Audit از قبل فعال و Rule مناسب تعریف شده باشد، ممکن است مشخص شود چه Process یا Userی فایل را تغییر داده است.

ausearch برای جستجو در Audit Log استفاده می‌شود و امکان Filter براساس Event Type، User و Time را دارد.

برای مثال:

ausearch -ts today -i

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

ausearch \
-ts 09/26/2026 02:00:00 \
-te 09/26/2026 04:00:00 \
-i

Format تاریخ ممکن است براساس نسخه و Locale متفاوت باشد.

اگر Audit Watch از قبل وجود داشته باشد

اگر Directory یا File با Audit Rule مانیتور شده باشد، می‌توان Eventهای مرتبط را دقیق‌تر جستجو کرد.

نکته مهم:

فعال کردن auditd بعد از Incident، اطلاعاتی درباره تغییراتی که قبل از فعال شدن Logging رخ داده‌اند ایجاد نمی‌کند.

بنابراین File Auditing باید پیشگیرانه Config شده باشد.

مسیرهای مهم برای File Integrity Monitoring

روی Serverهای حساس، مسیرهای زیر معمولاً ارزش Monitoring دارند:

/etc/
/boot/
/usr/bin/
/usr/sbin/
/usr/local/bin/
/usr/local/sbin/
/etc/systemd/system/
/etc/cron.d/
/etc/sudoers.d/
/root/.ssh/

در Web Serverها:

/var/www/

نیز اهمیت زیادی دارد.

یک Workflow عملی برای بررسی فایل‌های مشکوک

فرض کنیم Incident بین ساعت:

02:10
تا
03:00

رخ داده است.

مرحله اول: فایل‌های تغییرکرده

find /etc /usr/local /var/www /root /home /tmp /var/tmp /dev/shm \
-type f \
-newermt "2026-09-26 02:10:00" \
! -newermt "2026-09-26 03:00:00" \
-printf '%TY-%Tm-%Td %TH:%TM:%TS %u %g %m %s %p\n' \
2>/dev/null |
sort

مرحله دوم: تغییر Metadata

find /etc /usr/local /var/www /root /home \
-type f \
-cmin -120 \
-ls 2>/dev/null

مرحله سوم: فایل‌های Executable اخیر

find /tmp /var/tmp /dev/shm /usr/local/bin \
-type f \
-perm /111 \
-mtime -7 \
-ls 2>/dev/null

مرحله چهارم: بررسی فایل Candidate

stat /path/to/file

file /path/to/file

sha256sum /path/to/file

مرحله پنجم: Package Ownership

Ubuntu/Debian:

dpkg -S /path/to/file

RHEL-based:

rpm -qf /path/to/file

مرحله ششم: Integrity

Ubuntu/Debian:

dpkg -V package-name

RHEL-based:

rpm -V package-name

مرحله هفتم: Process

lsof /path/to/file

و:

ps auxf

مرحله هشتم: فایل‌های Deleted

lsof +L1

مرحله نهم: Network

ss -plant

مرحله دهم: Logها

journalctl \
--since "2026-09-26 02:10:00" \
--until "2026-09-26 03:00:00"

اکنون می‌توان File Timeline را با User، Process و Network Activity مقایسه کرد.

یک Audit سریع

echo "=== RECENT /etc FILES ==="

find /etc \
-type f \
-mtime -7 \
-ls 2>/dev/null


echo
echo "=== RECENT SYSTEMD FILES ==="

find /etc/systemd/system \
-type f \
-mtime -7 \
-ls 2>/dev/null


echo
echo "=== RECENT CRON FILES ==="

find /etc/cron.d \
-type f \
-mtime -7 \
-ls 2>/dev/null


echo
echo "=== RECENT WEB FILES ==="

find /var/www \
-type f \
-mtime -7 \
-ls 2>/dev/null


echo
echo "=== RECENT TEMP EXECUTABLES ==="

find /tmp /var/tmp /dev/shm \
-type f \
-perm /111 \
-mtime -7 \
-ls 2>/dev/null


echo
echo "=== DELETED OPEN FILES ==="

lsof +L1 2>/dev/null

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

چه ترکیبی مشکوک‌تر است؟

برای مثال:

New Executable
+
/tmp
+
root Owner
+
External Connection

یا:

Modified systemd Service
+
Recent ctime
+
Unknown Executable
+
Enabled at Boot

یا:

Modified PHP File
+
Web Server Owner
+
Recent HTTP Request

یا:

authorized_keys Changed
+
Unknown SSH Key
+
Recent External Login

چنین Correlationهایی از یک Timestamp منفرد ارزش بسیار بیشتری دارند.

Timestamp به‌تنهایی Evidence قطعی نیست

Timestampها می‌توانند تحت تأثیر موارد قانونی قرار بگیرند:

Package Update
Restore
File Copy
Deployment
Backup
Administrator Activity

همچنین مهاجم دارای Privilege کافی ممکن است تلاش کند Timeline را مخدوش کند.

بنابراین نتیجه Investigation باید از چند Source پشتیبانی شود:

File Metadata
Hash
Package Verification
Logs
Process
Network
Audit
Baseline

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

بلافاصله:

rm

نزنید.

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

مثلاً:

stat /path/to/file

file /path/to/file

sha256sum /path/to/file

و در صورت نیاز:

cp --preserve=all \
/path/to/file \
/root/IR/

در Incident رسمی بهتر است Evidence روی Storage مستقل و با فرایند Chain of Custody مناسب نگهداری شود.

آیا فایل در حال اجراست؟

lsof /path/to/file

یا:

pgrep -af "filename"

اگر Process پیدا شد:

ps -fp PID

readlink -f /proc/PID/exe

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

قبل از Stop کردن Process، اطلاعات Volatile را ثبت کنید.

Root Cause را پیدا کنید

پیدا کردن یک فایل تغییرکرده فقط یک سرنخ است.

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

چه کسی فایل را تغییر داده؟
چه زمانی؟
کدام Process؟
از چه Sessionی؟
فایل چگونه وارد Server شده؟
آیا Credential لو رفته؟
آیا Persistence ایجاد شده؟

برای مثال یک فایل مشکوک در /var/www ممکن است نتیجه:

Web Vulnerability
Compromised CMS
Stolen FTP Credential
Compromised SSH Account

باشد.

بعد از تأیید Compromise

بسته به Scope ممکن است نیاز باشد:

• Host ایزوله شود.
• Process مخرب متوقف شود.
• Persistence حذف شود.
• Package آسیب‌دیده Reinstall شود.
• Application از نسخه سالم Restore شود.
• Credentialها Rotate شوند.
• SSH Keyها بررسی شوند.
• Root Cause Patch شود.
• Logها حفظ شوند.
• سایر Serverها برای همان IOC بررسی شوند.

اگر Integrity سیستم دیگر قابل اعتماد نباشد، Rebuild از Image سالم ممکن است از پاک‌سازی دستی مطمئن‌تر باشد.

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

برای شناسایی سریع‌تر تغییرات فایل در آینده:

• File Integrity Monitoring فعال کنید.
• Baseline سالم داشته باشید.
• Hashهای Baseline را خارج از Server نگهداری کنید.
• /etc را مانیتور کنید.
• systemd Unitها را مانیتور کنید.
• Cron Fileها را مانیتور کنید.
• SSH Keyها را مانیتور کنید.
• Web Root را مانیتور کنید.
• auditd را از قبل Config کنید.
• Logها را به SIEM ارسال کنید.
• Deploymentهای Production را ثبت کنید.
• Package Updateها را مستند کنید.
• Least Privilege را رعایت کنید.

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

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

• بررسی فقط mtime
• تصور اینکه ctime یعنی Creation Time
• استفاده از -mtime -1 برای Timeline دقیق
• جستجوی کل / بدون محدود کردن Scope
• نادیده گرفتن /tmp و /dev/shm
• اعتماد به Filename و Extension
• بررسی نکردن Owner و Permission
• نگرفتن Hash
• بررسی نکردن Package Integrity
• اعتماد کامل به Database محلی Package Manager
• نادیده گرفتن فایل‌های Deleted ولی Open
• حذف فایل قبل از حفظ Evidence
• بررسی نکردن Process مربوط به فایل
• بررسی نکردن Network Connection
• مقایسه نکردن Timeline با Logها
• نداشتن Baseline سالم

چک‌لیست

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

• بازه زمانی Incident مشخص شده است.
• mtime بررسی شده است.
• ctime بررسی شده است.
• در صورت نیاز atime بررسی شده است.
• تفاوت ctime و Creation Time در نظر گرفته شده است.
• -mmin برای Timeline کوتاه استفاده شده است.
• -newermt برای بازه دقیق استفاده شده است.
• /etc بررسی شده است.
• /etc/systemd/system بررسی شده است.
• Cron Directoryها بررسی شده‌اند.
• SSH Keyها بررسی شده‌اند.
• Web Root بررسی شده است.
• /tmp بررسی شده است.
• /var/tmp بررسی شده است.
• /dev/shm بررسی شده است.
• Executableهای اخیر بررسی شده‌اند.
• فایل‌های مخفی بررسی شده‌اند.
• World-Writable Fileها بررسی شده‌اند.
• SUID/SGIDهای اخیر بررسی شده‌اند.
• File Capabilityها بررسی شده‌اند.
• Metadata با stat ثبت شده است.
• File Type بررسی شده است.
• SHA256 ثبت شده است.
• Package Owner مشخص شده است.
• dpkg -V یا rpm -V در صورت امکان اجرا شده است.
• Baseline بررسی شده است.
• فایل‌های Deleted ولی Open بررسی شده‌اند.
• Processهای مرتبط بررسی شده‌اند.
• Network Connectionها بررسی شده‌اند.
• Journal و Logها با Timeline مقایسه شده‌اند.
• Audit Log در صورت موجود بودن بررسی شده است.
• Evidence قبل از حذف حفظ شده است.
• Root Cause بررسی شده است.

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

GNU Findutils
مستندات رسمی find، جستجو براساس mtime، ctime، mmin و فرمت‌های زمانی.
GNU Findutils Manual

GNU Coreutils – File Timestamps
توضیح رسمی تفاوت atime، mtime، ctime و Birth Time.
GNU Coreutils – File timestamps

GNU Coreutils – SHA-2 Utilities
مرجع رسمی sha256sum و سایر SHA-2 Utilityها.
GNU Coreutils – SHA-2 utilities

Debian – dpkg
مستندات dpkg --verify برای بررسی Integrity فایل‌های متعلق به Packageها.
Debian Manpages – dpkg

RPM – Verify
مستندات رسمی rpm -V برای مقایسه فایل‌های نصب‌شده با Metadata Package.
RPM Manual – Verify

lsof
مرجع lsof و بررسی فایل‌های Open و Unlinked با +L1.
Linux Manual – lsof

AIDE
مستندات ابزار File Integrity Monitoring و ایجاد Baseline از Metadata و Hash فایل‌ها.
AIDE Manual

Red Hat – Linux Audit
راهنمای Audit Framework و استفاده از ausearch برای بررسی Eventهای ثبت‌شده.
Red Hat – Security Hardening

جمع‌بندی

بررسی فایل‌های تغییرکرده یکی از مهم‌ترین مراحل Investigation روی Linux Server است.

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

find /etc /var/www /root /home \
-type f \
-mtime -7

استفاده کرد.

اما برای Incident با Timeline کوتاه بهتر است از:

-mmin

یا بازه دقیق با:

-newermt

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

همچنین نباید فقط mtime را بررسی کرد.

ctime می‌تواند تغییراتی مانند Permission یا Owner را آشکار کند:

find /etc \
-type f \
-cmin -120

بعد از پیدا کردن فایل Candidate باید:

stat /path/to/file

file /path/to/file

و:

sha256sum /path/to/file

اجرا شود.

اگر فایل متعلق به Package سیستم باشد، روی Debian/Ubuntu می‌توان از:

dpkg -V

و روی AlmaLinux/Rocky/RHEL از:

rpm -V

برای مقایسه با Metadata Package استفاده کرد. RPM قادر است Attributeهایی مانند Digest، Size، Permission، Owner و Group را بررسی کند، در حالی که dpkg -V در وضعیت فعلی عمدتاً محتوا را با MD5 ذخیره‌شده مقایسه می‌کند.

فایل‌های حذف‌شده ولی همچنان در حال استفاده نیز نباید فراموش شوند:

lsof +L1

و اگر Process مشکوکی پیدا شد باید:

Executable
Command Line
Parent Process
Open Files
Network Connections

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

در نهایت یک Timestamp یا Hash به‌تنهایی Compromise را اثبات نمی‌کند. نتیجه قابل اعتماد زمانی به دست می‌آید که:

File Timeline
+
Metadata
+
Hash
+
Package Verification
+
Process
+
Network
+
Logs
+
Baseline

در کنار یکدیگر تحلیل شوند.

برای Serverهای حساس نیز بهتر است ابزارهایی مانند AIDE، auditd، Wazuh یا سایر File Integrity Monitoringها قبل از Incident فعال باشند تا تغییرات فایل‌ها از همان زمان وقوع ثبت و قابل مقایسه باشند. AIDE می‌تواند Attributeهایی مانند Permission، Owner، Size، mtime، ctime و Hash فایل‌ها را در Database خود نگهداری کند.

کیان پور