WAF ابر آروان چیست و چگونه عمل می‌کند؟

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

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

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

راه‌کار دیگر، استفاده از WAF ترکیبی (Hybrid) است. به این شکل که حملات کلی با استفاده از WAF ابری و حملات پیچیده‌تر و خاص‌تر با استفاده از WAF سخت‌افزاری تشخیص داده شوند.

انتظارات نابه‌جا از WAF

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

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

همان‌طور که گفته شد، WAF برای جلوگیری از حمله‌های لایه‌ی کاربرد طراحی‌شده و در زمینه‌های دیگر، مانند امنیت شبکه و… هیچ کاربردی ندارد و نباید آن را با دیواره‌های آتش نسل بعدی (Next Generation Firewall) اشتباه گرفت. از طرفی WAF یک راه‌حل کامل نیست. به این معنا که ممکن است وابسته به مجموعه قواعد WAF، برخی حملات را نتوان تشخیص داد یا برخی از درخواست‌های درست، حمله تشخیص داده شوند. از طرفی بسیاری از آسیب‌پذیری‌های منطقی دارای الگوی مناسب برای کشف و جلوگیری نیستند.

شیوه‌ی عمکلرد WAF ابر آروان

هنگامی‌که در ابر آروان تصمیم گرفته شد تا سرویس WAF ارایه شود، ابتدا فازی تحقیقاتی برای پیدا کردن بهترین گزینه‌ی Open Source تعریف شد. ما در نخستین جست‌وجوها، ModSecurity را پیدا کردیم. ماژولی که در ابتدا برای Apache طراحی‌شده، سپس روی Nginx هم پشتیبانی شده بود. از آن‌جایی‌که تعداد مقالات و شرکت‌های استفاده‌کننده از ModSecurity بالا بودند (از جمله Nginx Plus) مطمین شدیم بهترین گزینه برای دیواره آتش وب Open Source را در اختیار داریم. سپس تصمیم گرفتیم که آن را روی سرورهای خود پیاده‌سازی کنیم. کار پیاده‌سازی بسیار راحت بود و فقط کافی بود پس از نصب ModSecurity، ماژول Connector آن را در Nginx لود کنیم. پس از راه‌اندازی ماژول متصل‌کننده، زمان آن فرا رسیده بود که تست‌های مورد نظر را روی سرویس WAF اجرا کنیم تا از صحت عملکرد آن پیش از انتشار مطمین شویم. همه‌ی تست‌ها به‌خوبی پشت سر گذاشته شدند و در گام آخر باید Benchmark می‌گرفتیم. با توجه به تعداد درخواست‌های بالا روی سرورهای ابر آروان، ما به سرویس WAF نیاز داشتیم که تاخیری (Latency) کم‌تر از یک میلی‌ثانیه داشته باشد. متاسفانه نتیجه‌ی تست‌های Benchmark روی ModSecurity بسیار ناامیدکننده بود و نمی‌توانست نیاز ما را برآورده سازد.

پس از کنار گذاشتن ModSecurity به‌دنبال گزینه‌های دیگری گشتیم که بتوانیم آن‌ها را به‌وسیله‌ی OpenResty اجرا کنیم. بنابراین تمرکز خود را روی سرویس‌های WAF پیاده‌سازی‌شده به زبان Lua گذاشتیم. زبان Lua این امکان را برای ما فراهم می‌کرد که به‌راحتی بتوانیم بدون نیاز به کامپایل دوباره، سورس کد WAF را تغییر داده و تغییرات انجام‌شده را بررسی کنیم. گزینه‌ی مورد نظر ما Lua-resty-waf بود که به ادعای سازنده‌ی آن، Latency کم‌تر از یک میلی‌ثانیه داشت. هرچند پیاده‌سازی Lua-resty-waf نیازمند زمان بیش‌تری نسبت به ModSecurity بود، پس از راه‌اندازی و انجام تست‌های مورد نظر روی آن، نتیجه‌ی تست Benchmark به‌شکل شگفت‌انگیزی بهتر از ModSecurity شد. در نتیجه توانسته بودیم سرویس WAFای را پیدا کنیم که پاسخ‌گوی نیاز ما باشد اما پرسشی مهم مطرح شد: آیا سرویسی که به‌شکل یک پروژه‌ی دانشگاهی انجام شده بود، برای اجرا در Production آماده است؟

برای پاسخ به این پرسش از پروژه‌ی اصلی Fork گرفتیم و تست‌های بیش‌تری برای آزمایش عملکرد سرویس WAF نوشتیم. با انجام تست‌ها تعدادی باگ اساسی شناسایی شد، برای نمونه این سرویس بدنه‌ی درخواست‌های Post را بررسی نمی‌کرد. پس از اعمال bugfixها همه‌ی تست‌ها PASS شدند، اما با اضافه‌شدن آن‌ها مقدار Latency از مقدار مورد نظر ما (یک میلی‌ثانیه) بیش‌تر شده بود. در گام بعدی تصمیم گرفتیم که سرویس WAF را Optimize کنیم.

سرویس Lua-resty-waf را چه‌طور Optimize کردیم؟

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

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

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

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

ما برای Optimize کردن Lua-resty-waf از SystemTap استفاده کردیم. برای کار با این ابزار باید کرنل لینوکس را با پکیج‌های مربوط به debug دوباره Build می‌کردیم. پس از Build دوباره کرنل لینوکس و نصب SystemTap، حالا می‌توانستیم از سرویس WAF پروفایل بگیریم. خروجی SystemTap از پروفایل سرویس WAF را به‌کمک ابزار FlameGraph به یک نمودار میله‌ای تبدیل کردیم تا راحت‌تر قابل بررسی باشد. برای نمونه شکل زیر یکی از این نمودارها است که برای بررسی سرویس WAF از آن استفاده کردیم:

هر چه‌قدر که عرض هر نوار بیش‌تر باشد نشان‌دهنده‌ی صرف زمان پردازش بیش‌تر CPU برای آن تابع است.

این کار را بارها و بارها تکرار کردیم و هر بار کد را تغییر دادیم و اثر آن را سنجیدیم، تا جایی‌که توانستیم Performance سرویس WAF را تا ۴۰ درصد افزایش دهیم. به این ترتیب Latency سرویس WAF به حد پذیرفتنی برای ما رسیده بود. دوباره تست‌های مورد نظر را روی سرویس WAF اجرا کردیم تا مطمین شویم تغییرات ما اثر مخربی روی عملکرد سرویس WAF نداشته است. سپس سرویس WAF را روی سرورهای Production خود لانچ کردیم تا بتوانیم از کاربران خود در مقابل حملات اینترنتی حفاظت کنیم. با وجود طولانی بودن فرآیند بهینه‌سازی سرویس WAF، نتیجه‌ی کار بسیار رضایت‌بخش بود: دستیابی به یک سرویس مطمین که Latency کم‌تر از یک میلی‌ثانیه دارد. درنهایت نتیجه‌ی کار خود روی Lua-resty-waf را در Github منتشر کردیم.

یک نمونه از شیوه‌ی عملکرد WAF ابر آروان

فرض کنید سایت dvwa.com از محصول WAF امنیت ابری ابر آروان استفاده می‌کند. به‌ این‌ ترتیب تمامی درخواست‎ها به این سایت، به WAF ابر آروان می‎رسد. در این محصول ما از رویکرد مبتنی‌بر امتیاز استفاده می‎کنیم. به این‌شکل که فرض کنید حمله‎ی SQLI در درخواست زیر برای این سایت ارسال شده است:

http://dvwa.com/vulnerabilities/sqli/?id=’and”=’&Submit=Submit

در دیواره آتش وب ابر آروان قواعد زیر برای این درخواست تطابق داده می‌شود:

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