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

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

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

انواع رویکردهای WAF

انواع رویکرد های waf یا دیوار آتش وب را در ادامه شرح میدهیم:

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

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

رویکرد مبتنی بر رفتار

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

رویکرد مبتنی بر امتیاز

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

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

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

عملکرد دیواره آتش وب

Web Application Firewall یا WAF با مانیتور و فیلتر متدهای GET و POST تبادل میان اپلیکشین وب و اینترنت، از اپلیکیشن وب در برابر ترافیک مخرب حفاظت می‌کند. برای مشهورترین آسیب‎پذیری‎هایی که سبب تهدید یک اپلیکیشن وب می‎شوند، دسته‎بندی‎های مختلفی وجود دارد که owsap top 10 یکی از آن‌ها است.

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

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

مدل‌های پیکربندی WAF چیست؟

پیکربندی WAF عمومن بر پایه‌ی سه مدل امنیتی زیر است:

مدل وایت‌لیست (whitelist)

در این مدل فهرستی از URLهای مجاز مشخص می‌شود و تنها ترافیک همین URLهای مشخص اجازه‌ی عبور دارند. هر ترافیکی از URL غیر از URLهای فهرست مشخص‌شده، بلاک می‌شوند.

مدل بلک‌لیست (blacklist)

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

این مدل WAF برای اپلیکیشن‌های عمومی در دنیای اینترنت که هر نوع کاربری می‌تواند به آن‌ها‌ دسترسی داشته باشد، مفید است. اما این مدل در برابر حملات zero-day، روش موثری به‌شمار نمی‌آید. در حالت کلی این مدل به سه روش زیر انجام می‌شود:

مبتنی بر الگو (Pattern based)

در این حالت الگوهای عمومی از پیش تعیین‌شده (که معمولن زیر ۱۰۰ الگو هستند) در WAF قرار داده و درخواست‌های ارسالی با این الگوها مطابقت داده می‌شوند. چنان‌چه درخواستی با یکی از این الگوها مطابقت پیدا کند، به‌وسیله‌ی WAF بلاک می‌شود.

مبتنی بر رفتار (Behavior based)

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

مبتنی بر امتیاز (Score based)

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

مدل ترکیبی (Hybrid)

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

انواع WAF چیست؟

WAF می‌تواند به سه شکل زیر پیاده‌سازی شود که هر یک از این روش‌ها مزایا و معایب ویژه‌ی خود را دارند:

Network-based

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

Host-based

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

Cloud-based

ساده‌ترین و ارزان‌ترین روش پیاده‌سازی WAF این روش است. در این روش تنها کافی است DNS تغییر کند تا ترافیک به 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

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

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