نوشته شده توسط: علی آخی و بردیا اکبری
خب NGINX WAF همانطور که از اسمش پیداست یک Web Application Firewall است که بر پایه ModSecurity 3.0 می باشد، و مانند دیگر WAF ها کار جلوگیری و متوقف کردن حملات لایه هفتم مدل OSI را انجام می دهد.
اما کمی بیشتر درباره ModSecurity بیاموزیم، یک WAF که اولین بار در سال 2002 به عنوان ماژولی برای Apache ایجاد شد، به همین دلیل ModSecurity، برای استفاده از آن، به Dependency های Apache نیز، نیاز داشت. اما در سال 2010 که ModSecurity توسط شرکت Trustwave خریداری شد و تحت مجوز Apache License 2.0 قرار گرفت، این امر باعث شد تا سال 2012، ماژول هایی برای NGINX و IIS ایجاد شده و بسیاری از شرکت ها در محصولات خود از ModSecurity استفاده کنند.
علاوه بر دیگر وابسته نبودن ModSecurity 3.0 به Apache (چه در Compilation و چه در Runtime)، رفع کردن مشکل تعداد زیاد False-Positive ها در گذشته، و پشتیبانی از ماژول های Dynamic در ModSecurity 3.0 از دیگر ویژگی های آن بود.
پشتیبانی از ماژول های Dynamic به این معناست که شما می توانید خود ماژول هایی را ایجاد کنید که به گونه ای Compile شوند، که بدون نیاز به Recompile شدن خود NGINX بتوانند با آن کار کنند.
گفتیم که WAF ها از مجموعه قوانین و یا Rule Set هایی برای بررسی درخواست ها استفاده می کنند، اما این قوانین دقیقا در چه قسمتی از درخواست استفاده می شوند؟
این قوانین در سربرگ درخواست (Request Header)، بدنه درخواست (Request Body) و سربرگ پاسخ (Response Header) استفاده می شوند، بدنه پاسخ (Response Body) دیگر در WAF NGINX بررسی نشده و این عمل توسط ماژول Sub Filter در NGINX انجام می شود.
و اما Syntax این قوانین، هر قانون با فرمت زیر و توسط SecRule تعریف می شود:
سه قسمت اصلی این فرمت را با هم مرور می کنیم:
اول Variables :
در این قسمت مشخص می‌شود که دقیقاً چه قسمتی از دخواست و پاسخ HTTP بررسی می‌شود که خود شامل انواع متفاوتی است که در ادامه به تعدادی از آنها اشاره می‌کنیم:
متغیرهای Request:ARGREQUEST_HEADERS، REQUEST_COOKIES
متغیر های Response : RESPONSE_HEADERS، RESPONSE_BODY
متغیر های Server : REMOTE_ADDR، AUTH_TYPE
متغیر های Time : TIME، TIME_EPOCH، TIME_HOUR
متغیر های Collection : TX، IP، SESSION، GEO
دیگر متغیر ها : HIGHEST_SEVERITY، MATCHED_VAR
موارد بیشتر در این لینک !
دوم OPERATOR :
کلیدواژه را که قرار است در متغیر ها مورد بررسی قرار گیرد را مشخص می کنیم،به عنوان مثال :
مثلا : Rx، pm، beginsWith، contains، endsWith، streq،within، geoLookup، inspectFile
برای مطالعه بیشتر درباره هر یک از عملگر ها می توانید به این آدرس مراجعه کنید
سوم و به عنوان آخری ACTIONS و TRANSFORMATIONS:
در این قسمت عمل هایی تعریف می شوند که در صورت پیدا شدن الگوی تعریف شده (OPERATOR) در بخش مورد بررسی (VARIABLES)، می بایست انجام شوند.
عمل های Disruptive : block، drop، deny، proxy
عمل های Flow : chain، skip، skipAfter
عمل های Metadata : phase، id، msg، severity، tag
عمل های Variable : capture، setvar، initcol
عمل های Logging : log، auditlog، nolog، sanitiseArg
دیگر عمل ها : ctl، multiMatch، exec، pause، append/prepend
حال قبل از بررسی چند مثال از قانون یا SecRule ها، چند نکته که باید در نوشتن بک قانون رعایت شوند را ذکر می کنیم:
1- هر SecRule باید یک VARIABLE یا متغیر داشته باشد.
2- هر SecRule باید یک OPERATOR یا عملگر داشته باشد، در غیر اینصورت @rx به عنوان پیشفرض ست خواهد شد.
3- هر SecRule باید یک ACTION یا عمل داشته باشد و تنها عمل الزامی id می باشد.
4- هر SecRule باید یک عمل phase داشته باشد، این عمل مشخص کرده که چه زمانی و در چه فازی، قانون باید بررسی شود.
5- هر SecRule باید یک باید یک عمل از نوع disruptive داشته باشد، این نوع عمل مشخص می کند که با درخواست یا پاسخ باید چه کاری انجام داد، آن را متوقف کرد و یا صرفاً هشدار داده و به آن اجازه عبور داد.
6) استفاده از TRANSFORMATIONS اختیاری بوده اما برای جلوگیری از Bypass شدن قانون پیشنهاد می شود.
در مثال اول قانونی ساده نوشته شده که برای جلوگیری از حملات XSS می‌باشد
در این SecRule از متغیرهایARGS که تمام پارامتر ها و REQUEST_HEADERS که تمام سربرگ های درخواست ها را مورد بررسی قرار می دهند، استفاده شده است.
در قسمت OPERATOR، عملگر rx یک جستجوی کلی در بخش های ذکر شده انجام داده و در صورت یافتن عبارت عمل های نوشته شده را انجام می دهد.
در بخش عمل ها ابتدا idیا شناسه قانون ذکر شده است، سپس ‘XSS Attack’ به عنوان پیامی که قانون در صورت رخ دادن بر می گرداند آورده شده، Severity نیز شدت و درجه حمله را مشخص می کند که پارامتر های آن عبارت است از :
EMERGENCY (0)، ALERT (1)، CRITICAL (2)، ERROR (3)، WARNING (4)، NOTICE (5)، INFO (6) و (7) DEBUG
در آخر مهمترین عمل ها یعنی deny و status آورده شده که به ترتیب درخواست را رد کرده و به آن اجازه گذر نمی دهد و پاسخی با کد 404 بر می گرداند.
یکی از عمل های پرکاربرد در NGINX WAF عمل chain می باشد، با استفاده از این عمل شما می توانید زنجیره ای از قوانین بسازید که اگر درخواستی تمامی قوانین را فعال کرد، عمل disruptive تعریف شده در قانون اول اعمال شود، حتی اگر درخواستی تنها یکی از آن قوانین را فعال نکند، عمل disruptive اعمال نخواهد شد. در واقع شما یک AND منطقی میان قانون های خود پیاده سازی می کنید.
مثال زیر توسط NGINX برای نمایش نحوه کارکرد این عمل ارائه شده است.
در قانون اول آدرس درخواست ها بررسی شده و اگر درخواستی به /secret دریافت شد، WAF آنرا متوقف خواهد کرد. عمل deny به عنوان عمل disruptive برای کل زنجیره استفاده خواهد شد. در آخر نیز با استفاده از عمل chain این قانون و قانون بعد را به عنوان یک زنجیره قوانین تعریف می کنیم.
لازم به ذکر است که id در قانون مربوط به زنجیره قوانین است، در نتیجه نیازی به تعریف آن در قوانین دیگر زنجیره نمی باشد.
در قانون بعدی با قراردادن & در ابتدای متغیر، تعداد آن را برای سنجیده شدن توسط عملگر مشخص می کنیم، سپس اگر تعداد آن برابر با صفر بود، یعنی هیچ کوکی به اسم user_id ست نشده بود، این قانون فعال می شود. عمل chain نیز برای ادامه زنجیره، وارد شده است.
در ادامه قانونی تعریف شده است که سربرگ User-Agent را بررسی می کند و اگر اسم این User-Agent برای مثال attacker باشد و دستگاهی باشد که چنین User-Agent دارد،قانون فعال می شود. عمل chain نیز برای ادامه زنجیره، وارد شده است.
در آخر نیز سربرگ X-Forwarded-For چک شده و همانند قانون دوم اگر تعداد آن صفر باشد و ست نشده باشد، قانون فعال شود.
نهایتاً اگر تمامی قوانین زنجیره فعال شوند، عمل deny برا درخواست اعمال می شود و در غیر اینصورت اعمال نخواهد شد.
در مثال آخر نمونه ای از استفاده از لیست ها در قوانین را آورده‌ایم:
در این قانون همانند قبل، متغیر ما سربرگ User-Agent می باشد، اما این بار از لیستی شامل User-Agent هایی که نمی خواهیم به آنها اجازه دسترسی دهیم، استفاده می کنیم. قانون در صورت وجود داشتن User-Agent درخواست در این لیست، عمل deny را با پیام Blacklisted برای این درخواست اعمال خواهد کرد.
درباره ی OWASP Top 10 و OWASP
قبل از صحبت درباره بخش بعدی نیاز به شناخت OWASP داریم، OWASP یک سازمان بین المللی غیر انتفاعی است که تماماً به امنیت برنامه های وب می پردازد. تمامی محصولات این سازمان بصورت رایگان بر روی وبسایت آن قرار گرفته است که شامل فیلم ها، اسناد و استاندارد ها، و فروم ها می شود. معروف ترین محصول آنها یعنی پروژه OWASP Top 10، لیستی از ده مشکل امنیتی برتر برنامه های وب می باشد که همواره در حال بروزرسانی است. شرکت ها و ارگان های فرآوانی در دنیا از این استاندارد برای کمک در ساخت مدل امنیتی خود استفاده می کنند.
این ده مشکل امنیتی شامل موارد زیر می شوند:
Injection
Broken Authentication
Sensitive Data Exposure
XML External Entities (XXE)
Broken Access Control
Security Misconfiguration
Cross-Site Scripting (XSS)
Insecure Deserialization
Using Components with Known Vulnerabilities
Insufficient Logging & Monitoring
خب OWASP CRS مجموعه ای از قوانین کلی تشخیص حملات برای ModSecurity و دیگر WAF ها می‌باشد.
هدف این مجموعه محافظت از برنامه های وب در مقابل طیف وسیعی از حملات است که ممکن است برنامه وب ما را تهدید کنند. در این مجموعه تمرکز بر مقابله با حملات لیست OWASP Top 10 می باشد.
این Rule Set حفاظت در برابر انواع مختلف حملات را فراهم میکند، که از جمله آنها می توان به موارد زیر اشاره کرد:
SQL Injection (SQLi)
Cross Site Scripting (XSS)
Local File Inclusion (LFI)
Remote File Inclusion (RFI)
Remote Code Execution (RCE)
PHP Code Injection
HTTP Protocol Violations
HTTPoxy
Shellshock
Session Fixation
Scanner Detection
Metadata/Error Leakages
Project Honey Pot Blacklist
GeoIP Country Blocking
این CRS رایگان بوده و تحت مجوز Apache License 2.0 می باشد.
استفاده از CRS بجای قوانینی که خود قصد نوشتن آنها را داریم، پیشنهاد می شود. زیرا ممکن است قوانین ما مقدار زیادی از حملات را پوشش ندهد، درحالی که OWASP CRS با هدف حفاظت و پوشش حداکثری حملات پدید آمده است و تعداد قوانین بسیار زیادی را در خود جای داده است. همچنین، همزمان با کشف آسیب پذیری ها و حملات جدید، قوانین CRS نیز بروزرسانی می شود.
لازم به ذکر است اگرچه به طور کلی، بدون قوانین و پوشش وسیع آن لایه حفاظت را محکم تر خواهد کرد، اما به این معنی نیز می باشد که امکان متوقف کردن درخواستی مشروع، به اشتباه، بالا می رود.
جهت اطلاع بیشتر لطفا به صفحه github پروژه OWASP CRS به این آدرس، مراجعه فرمایید.
همچنین برای مشاهده قوانین تعریف شده در مجموعه OWASP CRS به این آدرس مراجعه فرمایید.
در هسته ModSecurity نیز یک Rule Set وجود دارد، که علاوه بر مقابله با حملات مرسوم و معروف همچون SQL Injection،Java و PHP Exploits، و XSS، قوانینی سازگار با دو CMS معروف، WordPress و Drupal نیز دارد، و یک Rule Set کامل به حساب می آید.
در نتیجه تصمیم استفاده از OWASP CRS یا دیگر Rule Set ها، و یا استفاده از Rule Set Core ModSecurity (CRS) و یا حتی تعریف قوانین از پایه توسط فرد، کاملا بر عهده شماست و حتی می توانید ترکیبی از این گزینه ها را انتخاب کنید.
در پایان به مقایسه نکات مثبت و منفی NGINX WAF می پردازیم:
از نکات مثبت آن می توان به :
مقابله و متوقف کردن حملات مرسوم و پوشش گسترده ی آسیب پذیری ها
پشتیبانی از Virtual Patching
فراهم کردن امکان شخصی سازی بالا ,... اشاره کرد، در مقابل آن:
استفاده زیاد از منابع
نگه داری و مدیریت Rule Set ها از نکات منفی آن به حساب می آید.
و این مطلب ادامه دارد ...
با تشکر فراوان!
