سامانهی تشخیص نفوذ (IDS) و سامانهی پیشگیری از نفوذ (IPS) بخشی جاافتاده از هر معماری دفاعی هستند و کار مشخصی را خوب انجام می‌دهند: دیدن الگوهای شناخته‌شده‌ی حمله در ترافیک شبکه و در رخدادهای میزبان. اما یک محدودیت ساختاری دارند که باید بی‌ابهام گفته شود: سوءاستفاده از منطق برنامه‌ی وب را نمیبینند. درخواستی که در آن مهاجم یک شناسه را تغییر داده، از دید هر IDS شبکه‌ای یک درخواست HTTPS کاملاً معمولی است. این مقاله توضیح میدهد این ابزارها چه می‌کنند، کجا کم می‌آورند، و لایهی تشخیصی که باید جایش را پر کند کجاست.
در یک نگاه
- IDS تشخیص میدهد و هشدار میدهد؛ IPS در مسیر ترافیک قرار میگیرد و مسدود میکند — با ریسک قطع ترافیک سالم.
- تشخیص مبتنی بر امضا فقط چیزهای شناخته‌شده را میبیند؛ تشخیص ناهنجاری موارد ناشناخته را هدف میگیرد اما نوفه‌ی زیادی تولید میکند.
- OWASP در نسخه‌ی ۲۰۲۵ نام دسته‌ی
A09را از «پایش» به «هشداردهی» تغییر داد — گذار از جمع‌آوری منفعل به تشخیص قابل اقدام. - لایه‌ای که واقعاً سوءاستفاده‌ی منطقی را میبیند، لاگ خود برنامه است، نه حسگر شبکه.
IDS و IPS: تفاوت و جایگاه
هر دو یک کار مشترک انجام می‌دهند — تحلیل ترافیک یا رخداد برای یافتن نشانه‌ی فعالیت مخرب — و در نقطه‌ی تصمیم از هم جدا میشوند:
- IDS بیرون از مسیر ترافیک قرار میگیرد (روی نسخه‌ای آینه‌ای از ترافیک) و فقط هشدار میدهد. خطر آن نوفه است، نه اختلال سرویس.
- IPS در مسیر ترافیک قرار میگیرد و میتواند بسته را مسدود کند. قدرتش همان چیزی است که خطرش را می‌سازد: یک قاعده‌ی بدتنظیم، ترافیک سالم مشتریان را قطع میکند.
سه نکته‌ی معماری که در پیاده‌سازی تعیین‌کننده‌اند:
- محل استقرار. حسگری که فقط مرز شبکه را میبیند، حرکت جانبی داخلی را نمی‌بیند؛ پوشش داخلی نیازمند حسگر در نقاط جداسازی است — موضوع امنیت شبکه.
- رفتار در شکست. اگر IPS از کار بیفتد، ترافیک باید عبور کند یا قطع شود؟ این تصمیم باید از پیش گرفته شود، نه در میانه‌ی یک حادثه.
- هزینه‌ی تنظیم. سامانهای که هزار هشدار روزانه تولید میکند، در عمل خاموش است.
امضا در برابر ناهنجاری
| معیار | مبتنی بر امضا | مبتنی بر ناهنجاری |
|---|---|---|
| روش | تطبیق با الگوی شناخته‌شده‌ی حمله | مقایسه با خط‌مبنای رفتار عادی |
| حملات شناخته‌شده | خوب | متوسط |
| حملات ناشناخته | نمی‌بیند | احتمال تشخیص دارد |
| مثبت کاذب | کم تا متوسط | بالا |
| نیاز به نگهداری | به‌روزرسانی مداوم مجموعهی قواعد | بازآموزی خط‌مبنا با هر تغییر برنامه |
| قابل توضیح بودن هشدار | روشن — کدام قاعده فعال شد | مبهم — «غیرعادی بود» |
در عمل، پیاده‌سازی‌های واقعی ترکیبی‌اند. اما نکته‌ی مهمی که فروشندگان کمتر می‌گویند: تشخیص ناهنجاری در محیطی که هر دو هفته یک‌بار نسخه‌ی جدید برنامه منتشر می‌شود، مرتب خط‌مبنایش را از دست میدهد و به منبع نوفه تبدیل می‌شود.
ابزارهای متن‌باز شناخته‌شده‌ی این حوزه: Snort و Suricata به‌عنوان موتور تشخیص شبکه‌محور مبتنی بر قاعده، و Zeek که رویکرد متفاوتی دارد — به‌جای هشدار، ترافیک را به لاگ‌های ساختاریافته و غنی تبدیل میکند که خودتان روی آن سناریوی تشخیص می‌نویسید. در سمت میزبان، OSSEC و Wazuh رایج‌اند.
شبکه‌محور در برابر میزبان‌محور
شبکه‌محور (NIDS) ترافیک عبوری را تحلیل میکند. مزیتش این است که یک حسگر، دید گسترده‌ای میدهد و روی سرورها چیزی نصب نمیشود. محدودیت اصلی‌اش امروز رمزنگاری است: وقتی ترافیک روی TLS است، محتوای درخواست برای حسگر قابل خواندن نیست. یعنی برای دیدن محتوای HTTP باید تحلیل را به نقطهای منتقل کنید که TLS در آن پایان می‌یابد — پروکسی معکوس، دروازهی API یا خود برنامه.
میزبان‌محور (HIDS) روی هر سرور نصب می‌شود و رخدادهای همان میزبان را میبیند: تغییر فایل، ایجاد فرایند، تلاش ورود، و تغییر پیکربندی. مزیت مهمش این است که رمزنگاری مانعش نیست، چون بعد از رمزگشایی نگاه میکند. برای وب‌سرورها، پایش یکپارچگی فایل یکی از مؤثرترین کنترل‌های تشخیصی است — چون آپلود پوسته‌ی وب یا تغییر فایل‌های سایت را فوراً نشان میدهد. نشانه‌های همین وضعیت در نشانه‌های هک شدن سایت فهرست شده است.
و برای تحلیل عمیق یک بسته یا اشکال‌یابی دست‌دادن TLS، ابزار مناسب Wireshark است، نه IDS.
محدودیت‌های واقعی
«IPS داریم، پس حملات وب متوقف میشوند.» سامانهی تشخیص نفوذ به‌دنبال الگو است، اما پرخطرترین حملات برنامه‌های وب هیچ الگوی مخربی ندارند. در یک سوءاستفاده‌ی IDOR، مهاجم فقط شناسهی 1042 را به 1043 تغییر میدهد؛ درخواست از هر نظر معتبر است. در یک شرایط مسابقه، همه‌ی درخواست‌ها به‌تنهایی مجازند و مسئله فقط هم‌زمانی آن‌هاست. اینها را نه IDS میبیند و نه WAF، چون تشخیصشان نیازمند دانستن قواعد کسبوکار است.
فهرست محدودیت‌هایی که باید در ارزیابی این ابزارها در نظر گرفته شود:
- ترافیک رمزنگاری‌شده: بدون پایان‌دادن TLS، محتوای HTTP دیده نمیشود.
- سوءاستفاده‌ی منطقی: هیچ امضایی برای «کاربر مجاز کار غیرمجاز کرد» وجود ندارد.
- گریز: کدگذاری چندلایه، تقطیع، و تغییر نوع محتوا می‌توانند تطبیق امضا را دور بزنند.
- هزینه‌ی نوفه: هشدار زیاد به بی‌توجهی تیم منجر می‌شود.
- آسیب‌پذیری خود ابزار: تجهیزات امنیتی هم سابقه‌ی CVE دارند و باید در چرخه‌ی مدیریت آسیب‌پذیری باشند.
رابطه با A09:2025 در OWASP
در OWASP Top 10:2025، نام دسته‌ی A09 از «Security Logging and Monitoring Failures» به «Security Logging and Alerting Failures» تغییر کرده. این تغییر یک کلمه، یک تغییر رویکرد است: جمع‌آوری منفعل لاگ کافی نیست؛ اگر هشداری تولید نشود که کسی به آن پاسخ دهد، لاگ فقط فضای ذخیره‌سازی مصرف کرده است. خود OWASP می‌نویسد: «بدون ثبت و پایش، حملات و رخنه‌ها قابل تشخیص نیستند؛ و بدون هشداردهی، پاسخ سریع و مؤثر در جریان یک رخداد بسیار دشوار است.»
نمونه‌هایی که OWASP ذکر میکند اندازه‌ی مسئله را نشان می‌دهند: رخنه‌ای در یک ارائه‌دهنده‌ی طرح سلامت کودکان که ۳٫۵ میلیون کودک را متأثر کرد و از ۲۰۱۳ کشف‌نشده مانده بود؛ و یک شرکت هواپیمایی اروپایی با بیش از ۴۰۰٬۰۰۰ رکورد پرداخت افشاشده و جریمه‌ی ۲۰ میلیون پوند.
راهکارهایی که OWASP برای این دسته فهرست میکند و مستقیماً به بحث ما مربوط‌اند:
- ثبت همه‌ی رخدادهای مرتبط با امنیت، با زمینه‌ی کافی برای شناسایی حساب مشکوک.
- کدگذاری خروجی لاگ برای جلوگیری از تزریق به لاگ (CWE-117) — نکته‌ای که تقریباً همیشه فراموش می‌شود.
- مسیر ممیزی فقط‌افزودنی با حفاظت یکپارچگی، تا مهاجم نتواند آثار خود را پاک کند.
- تعریف سناریوهای پایش به‌همراه کتابچه‌ی پاسخ متناظر؛ هشدار بدون رویه‌ی پاسخ بی‌اثر است.
- استقرار Honeytoken — اعتبارنامه یا رکورد تله‌ای که هر استفاده از آن قطعاً نشانه‌ی دسترسی غیرمجاز است.
دو CWE مهم دیگر این دسته: CWE-532 (درج اطلاعات حساس در فایل لاگ — یعنی خود لاگ میتواند به نشت داده تبدیل شود) و CWE-778 (ثبت ناکافی).
لایه‌ای که واقعاً حمله‌ی برنامه را میبیند
اگر IDS شبکه‌ای سوءاستفاده‌ی منطقی را نمی‌بیند، چه چیزی میبیند؟ پاسخ: خود برنامه. برنامه تنها جایی است که هم هویت و نقش کاربر را می‌داند و هم اینکه این درخواست باید مجاز باشد یا نه.
چهار رخدادی که هر برنامه‌ی وب باید ثبت کند و روی آن هشدار بدهد:
- شکست کنترل دسترسی — تلاش برای دسترسی به منبعی که کاربر مجاز نیست. OWASP در دسته‌ی
A01صریحاً ثبت و هشدار روی این رخداد و محدودسازی نرخ آن را توصیه میکند. - شکست احراز هویت — ورودهای ناموفق پیاپی، و مهمتر از آن، ورود موفق پس از مجموعه‌ای از تلاش‌های ناموفق.
- تغییر سطح دسترسی و عملیات حساس — تغییر نقش، تغییر ایمیل، ساخت کلید API، خروجی انبوه داده.
- الگوی غیرعادی مصرف — حسابی که در دو دقیقه دو هزار رکورد می‌خواند.
شکل عملی یک قاعده‌ی هشدار در لایهی برنامه:
event: authorization_failure
threshold: 5 per user per 60s
action: alert + rate-limit + record actor, path, roleهمین قاعده، آن الگویی را میگیرد که هیچ حسگر شبکه‌ای نمی‌بیند: دو پاسخ 403 روی مسیر مدیریتی و سپس یک 200 روی نسخه‌ی API همان قابلیت — نشانه‌ی اینکه کنترل دسترسی روی یک مسیر اعمال شده و روی مسیر دیگر جا افتاده است.
و نکته‌ی پایانی: تشخیص، جانشین اصلاح نیست. هشدار می‌گوید کسی در حال سوءاستفاده است؛ حذف خودِ نقص کار لایهی برنامه است. برای یافتن این نقص‌ها پیش از مهاجم، تست نفوذ برنامه‌ی وب و برای چارچوب کلی امنیت برنامه‌های وب نقطه‌ی درست‌اند؛ و اگر حادثه‌ای رخ داده، بازیابی سایت هک‌شده.
پرسش‌های متداول
تفاوت IDS و IPS چیست؟
IDS بیرون از مسیر ترافیک است و فقط هشدار میدهد؛ IPS در مسیر قرار میگیرد و میتواند ترافیک را مسدود کند. IPS اثر بازدارندهی بیشتری دارد اما ریسک قطع ترافیک سالم را هم اضافه میکند، پس نیازمند تنظیم دقیقتر و تصمیم روشن دربارهی رفتار در حالت شکست است.
آیا IDS جای WAF را میگیرد؟
خیر، و هیچکدام جای دیگری را نمیگیرد. IDS بر ترافیک شبکه و رخدادهای میزبان تمرکز دارد؛ WAF روی محتوای درخواست HTTP کار میکند. مهمتر اینکه هیچکدام نقص کنترل دسترسی، منطق کسبوکار و شرایط مسابقه را نمیبینند — اینها فقط با اصلاح کد رفع میشوند.
آیا IDS ترافیک HTTPS را میبیند؟
محتوای آن را نه، مگر آنکه TLS در نقطهای پایان یابد و تحلیل بعد از آن انجام شود. بدون این کار، حسگر فقط فرادادهی اتصال را میبیند. به همین دلیل تشخیص حملات لایهی برنامه عملاً به پروکسی معکوس، دروازهی API و لاگ خود برنامه منتقل شده است.
چرا سامانهی تشخیص ما اینقدر هشدار کاذب تولید میکند؟
معمولاً به سه دلیل: استفاده از مجموعهی قواعد پیشفرض بدون تنظیم برای محیط شما، فعالبودن تشخیص ناهنجاری در محیطی که مرتب تغییر میکند، و نبود فرایند بازخورد برای غیرفعالکردن قواعد بیارزش. سامانهای که هشدارهایش خوانده نمیشود، عملاً خاموش است.
حداقل چه چیزی را باید در برنامه لاگ کنیم؟
شکستهای کنترل دسترسی، شکست و موفقیت احراز هویت، تغییر نقش و اطلاعات حساب، عملیات حساس مالی، و خروجی انبوه داده — همه با شناسهی کاربر، زمان و مسیر. و بههمان اندازه مهم: دادهی حساس را در لاگ ننویسید و خروجی لاگ را کدگذاری کنید تا تزریق به لاگ ممکن نباشد.
منابع
امیر پیامنی
شکارچی ضعف‌های زیرساخت؛ از نقشه‌برداری سطح حمله تا بهره‌برداری از سرویس‌های شبکه و حرکت جانبی داخل دامنه.