ابزارهای تیم آبی در برابر ۵ سناریوی حمله واقعی: Wazuh، Zeek، Suricata و Osquery در عمل
مقایسه عملی Wazuh، Zeek، Suricata و Osquery در برابر ۵ سناریوی حمله واقعی: پیکربندی، خروجی هر ابزار، نگاشت به MITRE ATT&CK و معیارهای بهره‌برداری در SOC.
# ابزارهای تیم آبی در برابر ۵ سناریوی حمله واقعی: Wazuh، Zeek، Suricata و Osquery در عمل
## مقدمه
در راهنمای [ابزارهای تیم آبی](https://aidenweb.ir/blog/blue-team-tools-comprehensive-guide-ecc5697d) نصب و پیکربندی چهار ابزار کلیدی را پوشش دادیم. این بار زاویه را عوض می‌کنیم و ابزارها را در مقابل **سناریوهای حمله واقعی** می‌سنجیم: پنج سناریویی که در یک SOC واقعی هر هفته رخ میدهند و اینکه هر ابزار دقیقاً کدام قطعه از پازل را تحویل میدهد. هدف، پاسخ به پرسش عملی تیم‌های دفاعی است: «برای این نوع تهدید، کدام ابزار را باید روشن کنم و خروجی آن چه شکلی است؟»
هر سناریو شامل الگوی رخداد، نمونه پیکربندی یا کوئری، و خروجی عملیاتی است. اگر تازه‌وارد هستید، پیشنهاد می‌کنیم ابتدا [آزمایشگاه تشخیص](https://aidenweb.ir/blog/detection-home-lab-setup-complete-exam7wa) خود را راهاندازی کنید تا بتوانید مثال‌ها را همزمان اجرا کنید.
## مقایسه سریع چهار ابزار
| ابزار | لایه دفاعی | نوع داده اصلی | زمان تولید رخداد | مصرف منبع (VM 4 vCPU) |
|---|---|---|---|---|
| Wazuh | هاست + SIEM | لاگ، فایل، تله‌متری | ثانیه تا دقیقه | 2 تا 3 GB RAM |
| Zeek | شبکه (عمقی) | جریان اتصال، DNS، TLS | ثانیه | 1 تا 2 GB RAM |
| Suricata | شبکه (امضا) | پکت + جریان | میلیثانیه | 1 تا 2 GB RAM + inline |
| Osquery | هاست (سؤال‌پرسش) | جدول‌های SQL سیستم‌عامل | پولینگ چندثانیه‌ای | 100 تا 300 MB RAM |
قاعده کلی: **Suricata اولین خط است** (سریع، ارزان، امضای آماده)، **Zeek برای تحقیق** (بافت رفتار)، **Osquery برای بازجویی هاست** و **Wazuh برای همبستگی و ماندگاری** داده. این تقسیم‌بندی همان چیزی است که در [مسیر شغلی Blue Team](https://aidenweb.ir/blog/blue-team-career-path-complete-guide-lmaoumv) بهعنوان مهارت‌های هسته‌ای SOC معرفی می‌شود.
## سناریوی ۱: بک‌دور وب‌سرور — با Wazuh
**حمله:** مهاجم از طریق آپلود فایل یک وب‌شل در مسیر `/var/www/html/uploads/` قرار میدهد و هر ۱۰ دقیقه یک‌بار فایلی به‌نام `cron.php` را تغییر میدهد تا از تشخیص مبتنی بر هش اولیه فرار کند.
**چرا Wazuh؟** چون به دو منبع نیاز دارید که فقط لایه هاست آن‌ها را دارد: مانیتورینگ فایل (FIM) و رویدادهای وب‌سرور.
پیکربندی agent در `ossec.conf` برای پوشش مسیر حساس:
```xml
<syscheck>
<directories check_all="yes" report_changes="yes">/var/www/html</directories>
<frequency>300</frequency>
</syscheck>
```
رخداد تولیدشده در Wazuh:
```json
{
"rule": {"id": "554", "level": 12, "description": "File added to system"},
"location": "syscheck",
"data": {"path": "/var/www/html/uploads/cron.php",
"md5_after": "9f86d081884c7d659a2feaa0c55ad015"}
}
```
سطح هشدار ۱۲ یعنی بلافاصله وارد صف بررسی تحلیلگر SOC می‌شود. برای تبدیل این رخداد به یک قانون تشخیصی تمیز، [آموزش Sigma Rules](https://aidenweb.ir/blog/sigma-rules-tutorial-blue-team-detection-engine) را ببینید تا همان منطق را به‌صورت پورتیبل بنویسید.
**ATT&CK:** T1190 (Exploit Public-Facing Application) و T1036 (Masquerading).
## سناریوی ۲: ارتباط C2 — با Zeek
**حمله:** بدافزار روی یک ایستگاه کاری پس از فرار از آنتی‌ویروس، هر ۳۰ دقیقه به `cdn-update-check[.]net` درخواست DNS می‌زند و سپس از طریق HTTPS خالی (بدون SNI معتبر) با سرور فرماندهی ارتباط می‌گیرد.
**چرا Zeek؟** چون Suricata با امضای قدیمی این دامنه را نمیشناسد، اما Zeek رفتار را میبیند: تکرار منظم، عدم تطابق JA3، و دامنه‌ای با عمر کم.
نمونه خروجی `dns.log`:
```
1696118401.123456 C1k2x9 10.20.4.15 53 a 0 30 cdn-update-check.net 1 NOERROR 1 - -
1696118431.234567 C1k2x9 10.20.4.15 53 a 0 30 cdn-update-check.net 1 NOERROR 1 - -
```
کوئری ساده با `zeek-cut` برای استخراج دامنه‌های پرتکرار:
```bash
cat dns.log | zeek-cut id.orig_h query | sort | uniq -c | sort -rn | head -20
```
خروجی‌ای که دامنه C2 را با ۶۰ فرستنده در دقیقه بالای جدول می‌نشاند، همان سیگنالی است که به دنبالش هستید. سیگنال را با داشبورد [نقشه‌برداری MITRE ATT&CK](https://aidenweb.ir/blog/mitre-attck-mapping-blue-team-9ak50i1) به T1071.004 (Application Layer Protocol: DNS) گره بزنید.
## سناریوی ۳: اسکن و بهره‌برداری وب — با Suricata
**حمله:** یک اسکنر خارجی ابتدا `/wp-login.php` و سپس مسیرهای ابزارهای آسیب‌پذیر مانند `/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php` را تست میکند.
**چرا Suricata؟** چون به تصمیم در **چند میلیثانیه** نیاز دارید، قبل از اینکه درخواست به اپلیکیشن برسد. حالت inline در کنار nginx به شما اجازه میدهد ترافیک را همان لحظه قطع کنید.
یک قانون سفارشی در `local.rules`:
```
alert http any any -> $HOME_NET any (msg:"LOCAL WEB SHELL UPLOAD ATTEMPT"; \
flow:to_server,established; http.uri; content:"/uploads/"; \
pcre:"/\.(php|phtml|phar)$/i"; \
classtype:web-application-attack; sid:1000001; rev:1;)
```
اجرا و تست قانون:
```bash
suricata -c /etc/suricata/suricata.yaml -S local.rules -k none
suricata-update list-sources --enable-source et/ruleset-suricata
```
رخداد در `fast.log` و `eve.json` ثبت می‌شود و بلافاصله توسط Wazuh از طریق فوروارد لاگ خوانده می‌شود. این ترکیب، همان الگویی است که در [راهنمای کامل Wazuh SIEM](https://aidenweb.ir/blog/wazuh-siem-blue-team-complete-9ak50i1) بهعنوان معماری استاندارد توصیه شده است.
**ATT&CK:** T1190 و T1046 (Network Service Discovery).
## سناریوی ۴: Persistence ویندوز — با Osquery
**حمله:** مهاجم کلید رجیستری زیر را برای اجرای خودکار در هر ورود کاربر اضافه میکند:
```
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\SecurityHealth
= "C:\ProgramData\svhost.exe" -silent
```
**چرا Osquery؟** چون در لحظه نیاز دارید بپرسید: «روی **کدام** سیستم‌ها، **الان**، چنین چیزی هست؟» — پرسشی که پاسخ آن در SIEM ممکن است چند دقیقه تأخیر داشته باشد.
کوئری SQL برای شناسایی سراسری:
```sql
SELECT key, name, path, data, datetime(last_update_time, 'unixepoch')
FROM registry
WHERE path LIKE 'HKLM\Software\Microsoft\Windows\CurrentVersion\Run%'
AND data LIKE '%ProgramData%';
```
اجرای گروهی با Fleet:
```bash
fleetctl query --query "SELECT * FROM startup_items WHERE source = 'launchctl';" --hosts all
```
نتیجه: فهرست دقیق میزبان‌ها در کمتر از ۱۰ ثانیه، قابل اتصال به تیم واکنش برای [کتاب واکنش به حادثه](https://aidenweb.ir/blog/incident-response-playbook-blue-team-2ua3n1g).
**ATT&CK:** T1547.001 (Boot or Logon Autostart: Registry Run Keys).
## سناریوی ۵: همبستگی سه‌منبعی — Wazuh بهعنوان Brain
در دنیای واقعی هیچ ابزاری به‌تنهایی کافی نیست. حمله‌ای را تصور کنید که ابتدا Suricata آن را با sid:1000001 دیده، سپس Zeek ارتباط DNS مشکوک را ثبت کرده و در نهایت Osquery فایل اجرایی جدید را پیدا کرده است.
پیکرربندی همبستگی در `ossec.conf`:
```xml
<rule>
<if_matched_sid>1000001</if_matched_sid>
<frequency>3</frequency>
<timeframe>300</timeframe>
<level>14</level>
<description>Suricata + Zeek + Osquery correlation: likely compromise</description>
</rule>
```
با سه رخداد مشکوک در بازه ۵ دقیقه، هشدار سطح ۱۴ تولید می‌شود — یعنی نه فقط «رویداد»، بلکه یک **حادثه قابل شروع (Incident)**. این لایه همبستگی دقیقاً همان چیزی است که چارچوب [NIST CSF](https://aidenweb.ir/blog/nist-csf-framework-complete-guide-7gfnqrw) در مرحله Detect تعریف میکند.
## معیارهای عملکرد هر ابزار در بهره‌برداری
نصب موفق فقط شروع ماجراست؛ آنچه کیفیت دفاع را می‌سنجد، معیارهای عملیاتی است. جدول زیر حداقل شاخص‌هایی است که هر هفته باید در داشبورد SOC بررسی شوند:
| شاخص | هدف عملیاتی | ابزار مرجع | هشدار خرابی |
|---|---|---|---|
| تأخیر دریافت لاگ (ingest lag) | کمتر از ۳۰ ثانیه | Wazuh | بیش از ۵ دقیقه |
| نرخ false positive قوانین | کمتر از ۲۰٪ | Suricata / Sigma | بیش از ۵۰٪ |
| پوشش تکنیک‌های ATT&CK | بالای ۳۰٪ برای تیم کوچک | نقشه ATT&CK | زیر ۱۵٪ |
| زمان پاسخ اولیه (MTTD) | زیر ۱۰ دقیقه برای هشدار سطح بالا | Wazuh + SOAR | بیش از ۳۰ دقیقه |
| پوشش endpoint | بالای ۹۵٪ سیستم‌های متصل | Osquery / Wazuh agent | زیر ۸۵٪ |
نکته مهم: قوانین Suricata و Sigma را **هر ماه** بازبینی کنید. ابزاری که قوانینش به‌روز نمی‌شود، در عمل فقط نویز تولید میکند و اعتماد تحلیلگر را از بین می‌برد؛ همین موضوع یکی از دلایل اصلی خستگی هشدار (alert fatigue) در تیم‌های کوچک است.
## اشتباهات رایج در بهره‌برداری از این چهار ابزار
تجربه استقرارهای مختلف نشان میدهد اکثر تیم‌ها چهار اشتباه تکراری دارند:
1. **روشن کردن همه چیز همزمان.** در هفته اول فقط Suricata + Osquery را فعال کنید، قوانین را کالیبره کنید و سپس Zeek و Wazuh را اضافه کنید. دریافت ۵۰۰۰ هشدار در روز اول، یعنی پیکربندی خراب است، نه اینکه «حمله شده».
2. **نگهداری نکردن از لاگ‌ها.** اگر لاگ بیش از ۳۰ روز نگه ندارید، تحقیقات جلوتر از یک ماه را از دست می‌دهید. حداقل نگهداری ۹۰ روزه برای لاگ‌های امنیتی، حداقل توصیه‌شده در چارچوب‌های استاندارد است.
3. **نبود پوشش دوره‌ای.** هر ابزار باید لاگ‌های خودش (rule.errors، packet loss، osquery status) را مانیتور کند؛ یک Zeek که ۶ ساعت است خاموش است، بدتر از نبود Zeek است چون تصویر جعلی سلامت ایجاد میکند.
4. **جدی نگرفتن زمان‌بندی پولینگ Osquery.** پولینگ یک‌ثانیه‌ای روی هزاران هاست، سرور را فلج میکند؛ پولینگ پیش‌فرض ۶۰ ثانیه برای اکثر سوال‌ها کافی است و فقط برای تحقیق فعال از آن کمتر کنید.
## جدول پوشش ATT&CK
| سناریو | ابزار اصلی | تکنیک ATT&CK | سطح هشدار |
|---|---|---|---|
| بک‌دور وب | Wazuh FIM | T1190, T1036 | 12 |
| ارتباط C2 | Zeek | T1071.004 | 10 |
| آپلود شل | Suricata | T1190, T1046 | 12 |
| Persistence رجیستری | Osquery | T1547.001 | 11 |
| همبستگی سه‌منبعی | Wazuh | کل زنجیره | 14 |
## کدام ابزار را انتخاب کنم؟
- **منابع محدود (4GB RAM)؟** Suricata به‌صورت inline + Osquery. هر دو سبک‌اند و پوشش شبکه و هاست را همزمان میدهند.
- **لاگ ویندوز زیاد دارید؟** Wazuh با Sysmon اولویت اول است.
- **به دنبال تحقیق پس از هشدار هستید؟** Zeek را روی SPAN پورت فعال کنید تا داده تاریخی برای بررسی داشته باشید.
- **هدف شما گواهی و شغل است؟** تسلط بر همین چهار ابزار، هسته اصلی موقعیت‌های شغلی SOC L1/L2 است (بخش [مسیر شغلی Blue Team](https://aidenweb.ir/blog/blue-team-career-path-complete-guide-lmaoumv)).
## نتیجه‌گیری
ابزارها را نباید «نصب کنید و فراموش کنید»؛ باید آن‌ها را در برابر سناریوهای واقعی محک زد. در این پنج سناریو دیدیم که Suricata برنده سرعت، Zeek برنده دید رفتاری، Osquery برنده سؤال‌پرسشی و Wazuh برنده همبستگی است. تیم دفاعی موفق کسی است که این چهار صدا را در یک کنسول واحد به یک روایت واحد تبدیل کند. اگر مسیر یادگیری را تازه شروع کرده‌اید، [راهنمای جامع Defensive Cybersecurity](https://aidenweb.ir/blog/what-is-defensive-cybersecurity-complete-mswxz3zo) نقطه شروع مناسبی است و سپس به سراغ [آزمایشگاه تشخیص](https://aidenweb.ir/blog/detection-home-lab-setup-complete-exam7wa) خودتان بروید تا هر پنج سناریو را شخصاً بازتولید کنید.