فایروال وب چیست و چطور از سایت در برابر حمله DDoS محافظت کنیم؟

هر سایتی که روی اینترنت عمومی باز باشد از همان ساعت اول ترافیک مخرب می‌گیرد؛ اندازه و شهرتش هم مهم نیست. اسکنرهای خودکار کل فضای آدرس‌ها را می‌گردند و به محض گرفتن یک پاسخ HTTP 200، مسیرهای معروف و پیلودهای آماده را امتحان می‌کنند. پرسش درست این نیست که «آیا سایت من هدف حمله قرار می‌گیرد؟»، بلکه این است که این ترافیک کجا و با چه ابزاری متوقف می‌شود.

فایروال وب کجای مسیر می‌ایستد؟

فایروال وب یا WAF فیلتری در لایه اپلیکیشن است که پیش از رسیدن درخواست به سرور اصلی، خودِ درخواست HTTP را می‌خواند — متد، مسیر، پارامترهای query، هدرها، کوکی‌ها و بدنه — و تصمیم می‌گیرد که عبور کند، بلاک شود یا چالش بگیرد. فایروال شبکه چنین دیدی ندارد؛ iptables فقط IP و پورت را می‌بیند و از دید آن، یک درخواست عادی و یک تلاش SQL Injection هیچ فرقی ندارند، چون هر دو TCP روی پورت 443 هستند.

برای دیدن این محتوا، WAF باید به HTTP رمزگشایی‌شده دسترسی داشته باشد؛ یعنی باید جایی بنشیند که TLS در آن پایان می‌یابد. وقتی گواهی SSL رایگان روی لبه سرو می‌شود، همان نقطه طبیعی‌ترین جای اجرای قانون‌های WAF هم هست.

چه چیزی را واقعاً مهار می‌کند

دسته‌هایی از OWASP Top 10 که WAF روی آن‌ها مؤثر است

• SQL Injection — الگوهایی مثل ' OR 1=1 -- یا UNION SELECT در query یا بدنه فرم.
• XSS — تزریق <script> یا هندلرهایی مثل onerror= در پارامترهای ورودی.
• Path traversal و LFI — تلاش برای خواندن ../../etc/passwd یا همان الگو به شکل encode شده مثل %2e%2e%2f.
• اسکن مسیرهای حساس — درخواست پشت‌سرهم به /.env، /.git/config یا /phpmyadmin که هیچ کاربر واقعی نمی‌زند.
• پیلودهای عمومی اجرای کد — نمونه‌هایی که ساعاتی بعد از انتشار هر CVE مهم روی کل اینترنت پخش می‌شوند.

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

آنچه هیچ فایروال وبی حل نمی‌کند

• نقص منطق کسب‌وکار — اگر صفحه پرداخت قیمت را از سمت کلاینت بگیرد، درخواست دستکاری‌شده کاملاً معتبر است و WAF چیزی برای بلاک کردن نمی‌بیند.
• رمز ضعیف یا لو رفته — لاگین موفق با رمز درست از هر قانونی عبور می‌کند.
• کنترل دسترسی شکسته (IDOR) — درخواست GET /api/orders/1042 از کاربری که فقط حق دیدن سفارش 1041 را دارد، ساختاری بی‌عیب دارد.
• کلید و توکن افشاشده در کد فرانت‌اند یا مخزن گیت.

WAF سطح حمله را کوچک می‌کند، اما جای بازبینی کد، به‌روزرسانی افزونه‌ها و احراز هویت دومرحله‌ای را نمی‌گیرد.

لایه 3/4 در برابر لایه 7

«حمله DDoS» دو خانواده کاملاً متفاوت است و دفاعشان یکی نیست.

حمله‌های حجمی (لایه 3 و 4) مثل SYN flood و UDP amplification کاری با اپلیکیشن ندارند؛ هدفشان پر کردن پهنای باند لینک یا اشباع جدول اتصال‌های سرور است. روی خود سرور هم قابل حل نیستند: وقتی لینک ورودی پر شده، هر تصمیم سرور دیر است. تنها دفاع، جذب ترافیک در بالادست است — برای مبدأهای ایرانی با پهنای باند محدود، حیاتی‌تر هم هست.

حمله‌های لایه 7 ظاهر عادی دارند: درخواست HTTP معتبر، اما با نرخ بالا و روی گران‌ترین مسیرها. یک flood روی مسیر جستجو با کلیدواژه‌های تصادفی، با پهنای باند ناچیز دیتابیس را زمین می‌زند، چون هر درخواست یک کوئری تازه است و کش هم آن را نمی‌گیرد. Slowloris هم بدون جابه‌جایی حجم، با نگه داشتن اتصال‌های نیمه‌کاره ظرفیت وب‌سرور را تمام می‌کند.

نوع حمله	لایه	هدف واقعی	دفاع مؤثر
SYN flood	3/4	جدول اتصال‌های سرور	جذب و فیلتر در لبه
UDP / DNS amplification	3/4	پهنای باند لینک مبدأ	فیلتر بالادست، پنهان ماندن IP مبدأ
HTTP flood روی صفحه اصلی	7	CPU مبدأ	کش لبه به‌علاوه rate limit
flood روی جستجو یا API	7	دیتابیس	rate limit مسیرمحور
Slowloris	7	اتصال‌های باز وب‌سرور	پروکسی معکوس با timeout مناسب
SQLi و XSS و traversal	7	داده و کد اپلیکیشن	قانون‌های WAF
Credential stuffing	7	حساب کاربران	rate limit روی مسیر ورود
اسکرپر مهاجم	7	محتوا و پهنای باند	rate limit مسیرمحور به‌علاوه قانون WAF بر پایه الگوی رفتاری

کش خودش یک ابزار دفاعی لایه 7 است: صفحه‌ای که از کش لبه سرو می‌شود برای مبدأ هزینه‌ای ندارد و بخش بزرگی از یک HTTP flood را بی‌اثر می‌کند. مهاجم جدی‌تر به همین دلیل سراغ cache busting می‌رود و به هر URL پارامتری تصادفی می‌چسباند؛ پاسخ شما حذف این پارامترها از کلید کش است.

چرا یک rate limit سراسری همیشه اشتباه است

بارگذاری یک صفحه وردپرسی به‌راحتی چند ده درخواست HTTP دارد، پس مجبورید سقف واحد را بالا ببرید تا کاربر واقعی بلاک نشود — و همان سقف بالا جلوی brute force روی صفحه ورود را نمی‌گیرد، چون مهاجم با نرخی بسیار پایین‌تر هم به هدفش می‌رسد. سقف پایین هم اولین کاربری را که گالری تصویر باز می‌کند می‌بندد. راه‌حل، بودجه جداگانه برای هر مسیر است: صفحه‌های محتوایی و استاتیک‌ها خارج از شمارش؛ ورود و ثبت‌نام چند درخواست در دقیقه به ازای هر IP؛ ارسال کد یکبارمصرف سخت‌گیرانه‌ترین سقف؛ جستجو و APIهای سنگین هم سقف مستقل خودشان.

در nsin این کار با قانون‌های مسیر (path rules) انجام می‌شود: برای هر الگوی مسیر، سیاست کش و محدودیت نرخ جداگانه. جزئیات در مستندات آمده است.

یک هشدار محلی هم لازم است: روی شبکه‌های موبایل ایران کاربران زیادی پشت یک IP مشترک (CGNAT) قرار می‌گیرند و سقف سخت‌گیرانه بر مبنای IP، گروهی از کاربران واقعی را با هم بلاک می‌کند. سخت‌گیری را به مسیرهای حساس محدود کنید.

ربات‌ها؛ همه‌شان دشمن نیستند

Googlebot باید عبور کند. بلاک کردن ناخواسته آن گران‌ترین اشتباه ممکن با WAF است، چون نتیجه‌اش چند هفته بعد به شکل افت رتبه و خروج صفحه‌ها از ایندکس ظاهر می‌شود و علتش هم آشکار نیست. پس هرگز ربات را با رشته User-Agent تأیید نکنید؛ آن رشته جعل‌پذیر است و راه درست، reverse DNS روی IP و بررسی forward همان نام است. چرا دسترسی Googlebot به مبدأهای ایرانی خودش یک مسئله مستقل است را در مطلبی جدا توضیح داده‌ایم.

در طرف مقابل، اسکرپرهای محتوا و قیمت و اسکنرهای آسیب‌پذیری قرار دارند. این‌ها را از رفتارشان می‌شناسید نه از هویتشان: فقط HTML می‌گیرند و فایل جانبی بار نمی‌کنند، شناسه‌ها را پشت‌سرهم بالا می‌روند (/product/1، /product/2) و نرخشان ماشینی است.

False positive؛ خطری که بیشتر از حمله ضرر می‌زند

در عمل بیشتر خسارت WAF از حمله نمی‌آید، از قانون‌های بیش از حد سخت‌گیرانه می‌آید:

• نویسنده‌ای در پیشخوان وردپرس متنی درباره SQL می‌نویسد و ذخیره پست با خطای 403 برمی‌گردد.
• وب‌هوک درگاه پرداخت با ساختاری غیرمعمول می‌رسد و بلاک می‌شود؛ نتیجه، تراکنش‌های پرداخت‌شده اما تأییدنشده.

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

روش امن راه‌اندازی

• اول فقط تماشا کنید. تا ندانید ترافیک عادی سایتتان چه شکلی است، هیچ قانونی را سفت نکنید.
• ترافیک مشروع خودتان را فهرست کنید: مسیر مدیریت، آپلود، وب‌هوک پرداخت و پیامک، cronهای بیرونی و اپلیکیشن موبایل.
• قانون‌ها را یکی‌یکی فعال کنید؛ اگر چیزی خراب شد باید بدانید کدام قانون مقصر است.
• استثنا را مسیرمحور بنویسید؛ یک استثنا روی /wp-admin/ بهتر از خاموش کردن کل یک دسته قانون است.
• سقف نرخ را شل شروع کنید و با نگاه به لاگ، پله‌پله سفت کنید.

اگر تازه می‌خواهید دامنه را پشت لبه ببرید، ترتیب کار مهم است؛ مراحلش را در راه‌اندازی CDN بدون قطعی آورده‌ایم. در nsin فایروال وب مدیریت‌شده و مقابله با DDoS روی دامنه فعال است و لاگ زنده دقیقاً برای همین مرحله وجود دارد: می‌بینید چه درخواستی، با چه قانونی و از کجا بلاک شده. اگر مبدأ در میانه حمله از دسترس خارج شود، نسخه کش‌شده صفحه‌ها سرو می‌شود تا کاربر و خزنده گوگل صفحه سفید نبینند.

پرسش‌های متداول

آیا فایروال وب جلوی حمله DDoS را می‌گیرد؟

بخشی از آن را. WAF روی حمله‌های لایه 7 مؤثر است، یعنی جایی که ترافیک به شکل درخواست HTTP معتبر می‌آید. حمله‌های حجمی لایه 3 و 4 باید در بالادست جذب شوند و اصلاً به قانون‌های WAF نمی‌رسند؛ برای همین این دو کنار هم ارائه می‌شوند.

فایروال وب برای سایت وردپرسی هم لازم است؟

بله، احتمالاً بیشتر از بقیه؛ وردپرس بیشترین حجم اسکن خودکار را می‌گیرد چون ساختارش برای همه شناخته‌شده است. حداقل کار، محدودیت نرخ روی /wp-login.php و /xmlrpc.php است.

از کجا بفهمم سایتم زیر حمله DDoS است؟

جهش ناگهانی درخواست روی یک مسیر خاص، بالا رفتن CPU مبدأ بدون رشد واقعی بازدید، افزایش خطاهای 5xx و تمرکز ترافیک روی چند ASN یا یک کشور غیرمنتظره. سریع‌ترین راه تشخیص، لاگ زنده و نمودار ترافیک پنل است.

اگر تا امروز هیچ لایه‌ای بین اینترنت و مبدأ شما نبوده، قدم بعدی روشن کردن همه قانون‌ها نیست؛ اول ببینید چه ترافیکی به سایتتان می‌خورد. دامنه را در پنل nsin اضافه کنید، چند روز لاگ را تماشا کنید و بعد قانون‌ها را یکی‌یکی سفت کنید. هر دامنه جدید یک دوره آزمایشی ۷ روزه کامل Enterprise دارد؛ همین برای یک راه‌اندازی بدون false positive کافی است.