در این دوره یاد می‌گیری چطور سطح حمله یک سرور را شناسایی کنی، سرویس‌های فعال را بررسی کنی، آسیب‌پذیری‌های وب‌سایت را پیدا کنی، تنظیمات اشتباه سرور را تحلیل کنی و در نهایت یک گزارش تست نفوذ حرفه‌ای تهیه کنی.

هدف دوره: یادگیری عملی تست نفوذ قانونی، همراه با دستورات واقعی، تفسیر خروجی‌ها و تمرین در محیط آزمایشگاهی. تمرین‌ها برای سیستم‌های شخصی، ماشین‌های مجازی و اهدافی طراحی شده‌اند که مجوز بررسی آن‌ها را داری؛ نه برای ورود غیرمجاز به سرورهای دیگران.

نقشه راه دوره

فصل اول: آماده‌سازی آزمایشگاه و شناخت سرور

۱. پیش‌نیازها

• Kali Linux یا یک توزیع لینوکس مناسب برای ابزارهای امنیتی

• آشنایی مقدماتی با خط فرمان

• شناخت IP، پورت، DNS و پروتکل HTTP

• یک ماشین مجازی هدف که خودت مدیریت می‌کنی

• تهیه Snapshot از ماشین مجازی پیش از تمرین

برای برنامه وب آسیب‌پذیر آموزشی می‌توانی از OWASP Juice Shop استفاده کنی. این برنامه برای یادگیری امنیت وب طراحی شده است.

پیشنهاد آزمایشگاه: ماشین تست‌کننده و ماشین هدف را در شبکه مجازی جداگانه قرار بده و برنامه آسیب‌پذیر را روی اینترنت عمومی منتشر نکن.

۲. شناخت مشخصات سیستم

در ترمینال Kali یا لینوکس آزمایشگاهی اجرا کن:

whoami
id
hostname
uname -a
cat /etc/os-release
ip addr
ip route

توضیح دستورات:

تمرین ۱: خروجی این دستورات را ثبت کن و مشخص کن کدام رابط شبکه برای ارتباط با ماشین مجازی هدف استفاده می‌شود.

۳. بررسی سرویس‌های فعال

ss -tulpn

این دستور پورت‌هایی را که سیستم روی آن‌ها در حال گوش‌دادن است نشان می‌دهد. ممکن است برای دیدن نام پردازش‌ها به دسترسی مدیریتی نیاز داشته باشی.

نمونه خروجی فرضی:

tcp LISTEN 0 128 0.0.0.0:22
tcp LISTEN 0 511 0.0.0.0:80
tcp LISTEN 0 511 127.0.0.1:3306

تفسیر:

• پورت 22: معمولاً SSH برای مدیریت راه دور.

• پورت 80: معمولاً وب‌سرور HTTP.

• پورت 3306: معمولاً MySQL؛ در این مثال فقط روی رابط Loopback گوش می‌دهد.

این پورت‌ها صرفاً نمونه‌اند. بازبودن پورت به‌تنهایی آسیب‌پذیری را اثبات نمی‌کند؛ باید سرویس، نیاز عملیاتی و محدودیت‌های دسترسی را نیز بررسی کنی.

فصل دوم: شناسایی پورت‌ها و سرویس‌های سرور

۴. نصب و آشنایی با Nmap

Nmap ابزار شناسایی شبکه است که برای پیدا کردن میزبان‌های در دسترس، پورت‌های باز و اطلاعات سرویس‌ها استفاده می‌شود.

در Kali Linux معمولاً نصب است. بررسی کن:

nmap --version

اگر نصب نیست:

sudo apt update
sudo apt install nmap

تمرین ۲: اسکن ماشین آزمایشگاهی

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

ip -br addr

فرض کنیم IP ماشین هدف 192.168.56.20 است. این آدرس صرفاً نمونه است؛ آن را با IP واقعی آزمایشگاه خودت جایگزین کن.

ابتدا ارتباط شبکه را بررسی کن:

ping -c 4 192.168.56.20

پاسخ‌ندادن به Ping لزوماً به معنی خاموش‌بودن سیستم نیست؛ ممکن است ICMP مسدود شده باشد.

سپس اسکن پورت‌های متداول را اجرا کن:

nmap -sT --top-ports 100 192.168.56.20

معنی گزینه‌ها:

• -sT: برقراری اتصال TCP برای بررسی پورت‌ها.

• --top-ports 100: بررسی ۱۰۰ پورت متداول.

• آدرس انتهایی: ماشین هدف مجاز برای تست.

برای ذخیره نتایج:

nmap -sT --top-ports 100 \
  -oN scan-results.txt 192.168.56.20

چطور خروجی را تحلیل کنیم؟

تمرین عملی: سه پورت احتمالی را از خروجی انتخاب کن، نام سرویس‌های متداول آن‌ها را مشخص کن و توضیح بده هر سرویس چه کاربردی دارد و چرا باید دسترسی آن محدود شود.

۵. شناسایی نسخه سرویس‌ها

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

nmap -sV -sT -p 22,80,443 192.168.56.20

این دستور تلاش می‌کند نسخه سرویس‌های پاسخ‌دهنده روی پورت‌های مشخص‌شده را شناسایی کند.

نکته حرفه‌ای: شماره نسخه همیشه قابل اعتماد نیست؛ بعضی توزیع‌ها اصلاحات امنیتی را بدون تغییر نسخه اصلی منتشر می‌کنند. برای تشخیص آسیب‌پذیری، اطلاعات سازنده، نسخه بسته نصب‌شده، اصلاحات امنیتی و شرایط بهره‌برداری را کنار هم بررسی کن.

۶. بررسی آسیب‌پذیری‌های شناخته‌شده

پس از شناسایی یک سرویس، روند درست بررسی چنین است:

1. نسخه و سازنده واقعی سرویس را مشخص کن.
2. اطلاعیه امنیتی رسمی سازنده و شناسه CVE احتمالی را پیدا کن.
3. نسخه آسیب‌پذیر، پیش‌شرط‌های حمله و تأثیر واقعی را بررسی کن.
4. وجود اصلاحیه و راهکار کاهش ریسک را مشخص کن.
5. یافته را در گزارش ثبت کن و پس از اصلاح دوباره آزمایش کن.

منابع مناسب برای این مرحله:

• NVD — پایگاه اطلاعات آسیب‌پذیری‌ها.

• CVE — شناسه‌گذاری آسیب‌پذیری‌های شناخته‌شده.

• OWASP — راهنماهای امنیت برنامه‌های وب.

فصل سوم: ارزیابی امنیت خود وب‌سایت

۷. بررسی پاسخ HTTP و هدرهای امنیتی

ابزار curl امکان بررسی پاسخ وب‌سرور را فراهم می‌کند.

برای وب‌سایت آزمایشگاهی خودت:

curl -sS -D - -o /dev/null http://127.0.0.1:3000/

در این مثال فرض شده برنامه آزمایشگاهی روی پورت 3000 اجرا می‌شود. آدرس را متناسب با محیط خودت تغییر بده.

این دستور هدرهای پاسخ را نمایش می‌دهد، بدون اینکه محتوای صفحه را در ترمینال چاپ کند.

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

• کد وضعیت HTTP مانند 200، 301، 403 یا 500

• هدر Content-Type

• هدر Strict-Transport-Security در سرویس HTTPS

• هدر Content-Security-Policy

• هدر X-Content-Type-Options

• ویژگی‌های امنیتی کوکی‌ها مانند Secure، HttpOnly و SameSite

وجود یا نبود یک هدر را باید با معماری برنامه و نوع خطر مقایسه کرد. برای نمونه، HSTS زمانی معنا دارد که سایت به‌درستی از HTTPS استفاده کند.

۸. بررسی TLS و گواهی HTTPS

برای مشاهده اطلاعات اولیه گواهی TLS در محیط خودت:

openssl s_client \
  -connect localhost:443 \
  -servername localhost </dev/null

این دستور به سرویس TLS روی پورت ۴۴۳ متصل می‌شود. اگر سرویس روی این پورت فعال نباشد، اتصال موفق نخواهد شد.

موارد مهم:

• تاریخ اعتبار گواهی

• نام دامنه‌های درج‌شده در گواهی

• زنجیره گواهی و اعتبارسنجی آن

• پیکربندی نسخه‌های TLS و مجموعه رمزنگاری‌ها

تمرین ۳: خروجی هدرهای وب‌سرور و اطلاعات گواهی آزمایشگاه را ذخیره کن. برای هر موردی که نیاز به اصلاح دارد، یک راهکار مشخص بنویس.

۹. بررسی کنترل دسترسی و احراز هویت

در تست نفوذ وب، تنها صفحه ورود مهم نیست؛ باید بررسی شود که برنامه مجوز دسترسی به هر منبع را در سمت سرور کنترل می‌کند یا نه.

در آزمایشگاه، دو حساب آزمایشی با نقش‌های متفاوت ایجاد کن؛ مثلاً کاربر عادی و مدیر.

بررسی کن:

• آیا کاربر عادی می‌تواند عملیات مدیریتی انجام دهد؟

• آیا هر کاربر فقط به اطلاعات متعلق به خودش دسترسی دارد؟

• آیا پس از خروج، نشست قبلی طبق سیاست برنامه بی‌اعتبار می‌شود؟

• آیا خطاهای ورود، جزئیات حساس سیستم را افشا می‌کنند؟

• آیا محدودیت منطقی برای تلاش‌های ناموفق ورود وجود دارد؟

این بررسی‌ها را با حساب‌های آزمایشی و داده‌های ساختگی انجام بده. برای اثبات ضعف کنترل دسترسی، لازم نیست اطلاعات واقعی کاربران دیگر را مشاهده یا استخراج کنی.

۱۰. بررسی آپلود فایل

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

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

1. آیا پسوند فایل محدود شده است؟

2. آیا نوع واقعی محتوا در سمت سرور بررسی می‌شود؟

3. آیا فایل‌های آپلودشده در مسیری غیرقابل‌اجرا نگهداری می‌شوند؟

4. آیا نام فایل سمت سرور به‌صورت امن تولید می‌شود؟

5. آیا محدودیت حجم و سطح دسترسی فایل وجود دارد؟

6. آیا فایل خصوصی بدون احراز هویت قابل دریافت است؟

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

printf 'LAB-UPLOAD-TEST\n' > lab-test.txt
file lab-test.txt
sha256sum lab-test.txt

فایل را از طریق فرم آپلود برنامه آزمایشگاهی ارسال کن. سپس بررسی کن آیا سرور فایل را در محل مورد انتظار نگهداری کرده، آیا دسترسی به آن کنترل می‌شود و آیا محتوای فایل تغییر کرده است.

برای اصلاح، فایل‌ها را خارج از مسیر اجرای وب نگهداری کن، نام امن تولید کن، اعتبارسنجی سمت سرور داشته باش و اجازه اجرای فایل‌های آپلودشده را نده.

فصل چهارم: ارزیابی امنیت سیستم‌عامل سرور

۱۱. بررسی کاربران و مجوزها

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

مشاهده کاربران و گروه‌های مدیریتی

who
getent passwd
getent group sudo

این دستورات کاربران واردشده، حساب‌های تعریف‌شده و اعضای گروه sudo را نشان می‌دهند. وجود یک حساب به‌تنهایی به معنی خطر نیست؛ حساب‌های سرویس و سیستمی نیز در این فهرست قرار دارند.

بررسی مجوزهای فایل و پوشه

ls -ld /var/www
find /var/www -maxdepth 2 -type d -ls

اگر مسیر سایت در /var/www قرار دارد، این دستورات می‌توانند مجوزهای پوشه‌ها را نمایش دهند. مسیر نصب ممکن است در سرورهای مختلف متفاوت باشد.

به دنبال این مشکلات بگرد:

• فایل‌های حساس با مجوز نوشتن برای همه کاربران

• فایل‌های پیکربندی دارای رمز یا کلید محرمانه که در معرض دسترسی غیرضروری هستند

• فایل‌های آپلودشده با امکان اجرا

• مالکیت نامناسب پوشه‌های سایت

• دسترسی بیش‌ازحد کاربر اجرای وب‌سرور

هشدار: مجوز 777 راه‌حل عمومی برای خطاهای دسترسی نیست. تغییر کورکورانه مجوزها ممکن است سایت را مختل کند یا اطلاعات را در معرض خطر قرار دهد.

۱۲. بررسی وضعیت SSH

برای مشاهده تنظیمات مؤثر SSH، در سرور لینوکسی دارای OpenSSH اجرا کن:

sudo sshd -T

به این تنظیمات توجه کن:

• permitrootlogin

• passwordauthentication

• pubkeyauthentication

• maxauthtries

سیاست مناسب به نوع سرور و روش مدیریت آن بستگی دارد. برای نمونه، غیرفعال‌کردن ورود با رمز قبل از آزمایش ورود با کلید SSH می‌تواند باعث قطع دسترسی مدیریتی شود. پیش از تغییر تنظیمات، مسیر بازیابی و دسترسی کنسول را بررسی کن.

۱۳. بررسی لاگ‌های امنیتی

در سیستم‌های مبتنی بر systemd:

sudo journalctl -p warning --since "24 hours ago"

برای بررسی رخدادهای سرویس SSH، در صورت ثبت لاگ در journald:

sudo journalctl -u ssh --since "24 hours ago"

در بعضی توزیع‌ها نام سرویس sshd است یا لاگ‌ها در فایل‌های دیگری ذخیره می‌شوند.

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

• تلاش‌های ورود ناموفق تکرارشونده

• خطاهای مکرر وب‌سرور

• راه‌اندازی مجدد غیرمنتظره سرویس‌ها

• تغییرات غیرمنتظره در فایل‌های حساس

• افزایش ناگهانی مصرف منابع

یک رویداد منفرد الزاماً نشانه نفوذ نیست؛ زمان رخدادها، آدرس مبدأ، حساب کاربری و رویدادهای مرتبط را کنار هم بررسی کن.

فصل پنجم: سخت‌سازی سرور و رفع آسیب‌پذیری

پس از ارزیابی، نوبت به اصلاح یافته‌ها می‌رسد.

برای سرور Ubuntu یا Debian، بررسی به‌روزرسانی‌های موجود را می‌توان با این دستور آغاز کرد:

sudo apt update
apt list --upgradable

این دستورات فهرست بسته‌های قابل ارتقا را بررسی می‌کنند؛ ارتقا را پس از تهیه نسخه پشتیبان و بررسی تأثیر آن بر سرویس‌ها انجام بده.

تمرین ۴: یک اصلاح واقعی در آزمایشگاه

یک مورد از یافته‌های آزمایشگاه را انتخاب کن؛ مثلاً سرویسی که نباید روی رابط شبکه عمومی گوش دهد.

1. وضعیت اولیه سرویس و پورت را ثبت کن.

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

3. در محیط آزمایشگاهی، سرویس یا محدودیت شبکه را به شکل مناسب اصلاح کن.

4. دوباره دستور ss -tulpn را اجرا کن.

5. با اسکن مجاز Nmap، وضعیت پورت را از ماشین تست‌کننده بررسی کن.

6. تأیید کن که تغییر امنیتی باعث اختلال در سرویس‌های ضروری نشده است.

معیار موفقیت، صرفاً بسته‌شدن پورت نیست؛ باید نشان دهی سطح دسترسی غیرضروری کاهش یافته و عملکرد موردنیاز سیستم حفظ شده است.

پروژه پایانی: تست نفوذ مستند یک وب‌سرور آزمایشگاهی

قالب گزارش حرفه‌ای تست نفوذ

برای هر یافته این اطلاعات را ثبت کن:

• عنوان: نام دقیق ضعف امنیتی

• دارایی: سرور، دامنه یا برنامه آزمایش‌شده

• شرح: شرایط و علت ایجاد ضعف

• شواهد: خروجی دستور، لاگ یا تصویر از محیط مجاز

• شدت: بحرانی، بالا، متوسط یا پایین؛ بر اساس اثر و احتمال سوءاستفاده

• تأثیر: پیامد احتمالی بر محرمانگی، یکپارچگی یا دسترس‌پذیری

• راهکار: اقدام فنی مشخص برای رفع مشکل

• بازآزمایی: نتیجه بررسی پس از اصلاح