پیاده سازی Web Application Firewall با ModSecurity

بصورت کلی وقتی می گوییم application firewall یعنی فعالیت در لایه 7 از OSI و در سطح و محیط و ترافیک اپلیکیشن و سرویس ، به عناوین application-level gateway یا proxy firewall هم ممکن است در مستندات نام برده شده باشند. برای فایروال وب اپلیکیشن ها که عملکرد IDS/IPS هم دارد از عبارت web application firewall (WAF) استفاده می شود و همچنین باید درنظر داشت بسیاری از محصولات حرفه ای و سازمانی یکپارچه این لایه های مختلف فایروال را همزمان و هماهنگ ارایه می دهند و این دسته بندی ها و تعاریف هم مرز مشخص و دقیقی ندارند.

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

ماژول ModSecurity اورجینالی بعنوان یک ماژول برای آپاچه معرفی شد اما اکنون روی nginx و IIS هم نصب می شود. کار کردن با آن برای استفاده های متداول نسبتاً ساده و سرراست است و قدرت و بازدهی خوبی هم ارایه می دهد. البته می توان خیلی در آن دقیق شده و از امکانات و قابلیت های بسیار آن برای پیاده سازی سناریوهای پیچیده استفاده کرد. حتی بصورت appliance و as a service هم موجود است و می توان با ترکیب با بقیه راه حل های وب سرور مثل "توزیع، هدایت و FailOver ترافیک با پروکسی Apache" یک application gateway قابل اطمینان و امن و قابل نظارت برای یک زیرساخت پیاده سازی نمود.

توانایی شناسایی انواع حملات روی وب اپلیکیشن ها را دارد و البته configی که پیاده سازی می کنید بسیار مهم است. تعدادی rule set و config آماده مثل OWASP ModSecurity Core Rule Set نیز برای mod security موجود است که کار را خیلی راحت تر می کنند.

در این مقاله معرفی کوتاه و نگاهی به ModSecurity خواهیم داشت که برای آشنایی اولیه و پایه ای برای جستجوهای تکمیلی مناسب است.

محیط من در اینجا یک دبیان 10 با apache2 است (TurnKey LAMP Stack)، اصول کلی در سایر لینوکس ها و nginx و IIS هم همین خواهد بود و فقط در فرآیند نصب و فعال کردن ممکن است تفاوت هایی وجود داشته باشد که البته راهنمای نصب روی محیط های مختلف در راهنمای رسمی خودش بخوبی بیان شده.

ابتدا برای چک کردن ماژول های فعال روی apache2 :

برای نصب روی دبیان، اوبونتو و CentOS :

Debian 7-8-9 : apt install libapache2-modsecurity
Ubuntu/Debian 10 : apt install libapache2-mod-security2
CentOS : yum install mod_security

و سپس سرویس apache را ریستارت کنید.

مسیر پیش فرض تنظیمات etc/modsecurity/ است و در هنگام نصب یک فایل config بعنوان نمونه با نام modsecurity.conf-recommended خودش در این مسیر قرار می دهد. این فایل را به modsecurity.conf تغییر نام می دهیم. (فایل های conf. این مسیر در اجرا اعمال می شوند.)

با بازکردن این فایل اولین مورد مربوط به تنظیم SecRuleEngine است که 2 حالت دارد : DetectionOnly که فقط لاگ می کند و حالت IDS دارد و On که بصورت اکتیو در نقش IPS حملات را بلاک می کند، یک Off هم هست که mod_security را غیرفعال می کند.

مسیر پیش فرض لاگ var/log/apache2/modsec_audit.log/ است، مثل خیلی از سرویس های دیگر سطح لاگ کردن قابل تنظیم است و ابزارهای متعدد بعنوان ModSecurity log parser وجود دارند. فرمت لاگ پیش فرض شامل سکشن های مختلف است که از A تا Z مشخص می شوند و هر کدام شامل بخشی از دیتای مرتبط با مورد لاگ شده هستند که جدول آن را در زیر مشاهده می فرمایید.

در فایل کانفیگ هم در بخش SecAuditLogParts و بخش های دیگر مربوط به Log می توانید تعیین کنید کدام بخش ها فعال باشند و در کجا چه چیزی ذخیره شود.

برای استفاده از OWASP ModSecurity Core Rule Set ابتدا آن را دریافت کنید :

#git clone https://github.com/SpiderLabs/owasp-modsecurity-crs.git
#cd owasp-modsecurity-crs/
#cp crs-setup.conf.example /etc/modsecurity/crs-setup.conf
#cp -r rules/ /etc/modsecurity

#nano /etc/apache2/mods-enabled/security2.conf

محتوی security2.conf در mods-enabled آپاچه برای این مثال ما باید بشرح ذیل باشد.

ما در اینجا بصورت کلی در تنظیمات ماژول آپاچه این دستورات را اعمال کرده ایم، می توان در سطح virtualhost و .htaccess هم با IfModule تنظیماتی اختصاصی اعمال کرد.

حال که ModSecurity را نصب کردیم، ruleها و تنظیمات OWASP را هم اضافه کردیم و سرویس آپاچه را هم ریستارت کردیم اگر من سعی کنم مثلاً آدرس http://192.168.5.11/?exec=/bin/bash را باز کنم :

یا سعی کنم مثلاً xss یا sql injection انجام دهم :

لاگ موارد بالا هم در var/log/apache2/error.log/ و هم در var/log/apache2/modsec_audit.log/ با جزییات بیشتر دردسترس است.

بجای نمایش Forbidden و دادن 403 و ...می توانید با اکشن status یا سایر اکشن های همگروه آن پیام دلخواه را نمایش دهید.

برای نصب و تنظیم و تشریح دستورات مختلف ریفرنس خوبی دارد که در اینجا قابل دسترس است.

ممکن است برای اپلیکیشن خود نیاز به استثناهایی داشته باشید که با مرور نمونه های EXCLUSION در پوشه rules می توانید یک فایل conf جدید بسازید و تعریف کنید.

راهنما و نمونه های ruleهایی که می توانید برای mod security بنویسید بسیار زیاد است و تعداد زیادی هم ruleهای بروز آماده براش هست.

یک نمونه هم rule مثلاً برای تشخیص و ممانعت لغت "mybadword" یا "yourbadword" بسازیم:

#nano /etc/modsecurity/my_rules.conf
با این محتوی
SecRule FULL_REQUEST &quot@rx (?i:(mybadword|yourbadword))&quot &quotid:'500001',deny,log,msg:'Bad Word Detected!'&quot

ابتدا در مسیر /etc/modsecurity/ یک فایل conf ساخته ام و درون آن خط به خط می توان rule تعریف کنم.

در rule بالا ما تعریف کرده ایم که اگر هر بخش از ریکوئست (FULL_REQUEST) براساس regex (@rx) بدون درنظر گرفتن بزرگی و کوچکی حروف (i?) حاوی عبارت اول یا (|) دوم بود؛ مسدود و لاگ شود.

حالا بعد از systemctl restart apache2 :

و در لاگ ها براساس تنظیماتی که انجام داده اید این موارد ثبت می شوند که می توانید مثلاً برای ذخیره و پردازش دقیق تر به الاستیک سرچ یا اسپلانک بفرستید.

خیلی آپشن و تنظیمات در اختیار شما هست که برای استفاده دقیق و کامل باید زمان مناسبی برای مرور مستنداتش اختصاص دهید. اما درخصوص نوشتن rule برای ModSecurity هم توضیح کوتاهی بدهم.

در ساده ترین حالت مثل چیزی که ما بالا استفاده کردیم دایرکتیو SecRule قرار دارد که یک rule برای پردازش می سازد. انواع Configuration Directivesهایی که در اختیار دارید را اینجا ببینید.

در سینتکس

SecRule VARIABLES &quotOPERATOR&quot &quotTRANSFORMATIONS,ACTIONS&quot

انواع VARIABLEها را اینجا ، انواعOPERATORها را اینجا و انواع ACTIONSها را اینجا و انواع Transformation functionsها را اینجا ببینید.

بصورت کلی بنقل از مستندات OWASP ModSecurity Core Rule Set :

There are ~105 variables in 6 different categories, some examples include:

• Request Variables - ARGS, REQUEST_HEADERS, REQUEST_COOKIES
• Response Variables - RESPONSE_HEADERS, RESPONSE_BODY
• Server Variables - REMOTE_ADDR, AUTH_TYPE
• Time Variables - TIME, TIME_EPOCH, TIME_HOUR
• Collection Variables - TX, IP, SESSION, GEO
• Miscellaneous Variables - HIGHEST_SEVERITY, MATCHED_VAR

There are ~36 operators in 4 different categories, some examples include:

• String Operators - rx, pm, beginsWith, contains, endsWith, streq, within
• Numerical Operators - eq, ge, gt, le, lt
• Validation Operators - validateByteRange, validateUrlEncoding, validateSchema
• Miscellaneous Operators - rbl, geoLookup, inspectFile, verifyCC

There are ~35 transformation functions in 6 different categories, some examples include:

• Anti-Evasion Functions - lowercase, normalisePath, removeNulls, replaceComments, compressWhitespace
• Decoding Functions - base64Decode, hexDecode, jsDecode, urlDecodeUni
• Encoding Functions - base64Encode, hexEncode
• Hashing Functions - sha1, md5

There are ~47 actions in 6 different categories, some examples include:

• Disruptive Actions - block, drop, deny, proxy
• Flow Actions - chain, skip, skipAfter
• Metadata Actions - phase, id, msg, severity, tag
• Variable Actions - capture, setvar, initcol
• Logging Actions - log, auditlog, nolog, sanitiseArg
• Miscellaneous Actions - ctl, multiMatch, exec, pause, append/prepend

همچنین بیاد داشته باشید

1. Every SecRule must have a VARIABLE
2. Every SecRule must have an OPERATOR, if none is listed @rx is implied.
3. Every SecRule must have an ACTION. The only required action is id, however, several actions are implied by SecDefaultAction (default phase:2,log,auditlog,pass)
4. Every SecRule must have an phase ACTION, this tells the rule when to fire. If no phase is included the default is phase:2.
5. Every SecRule must have a disruptive ACTION. This is an action that describes what to do with the transaction if triggered. If no disruptive action is included the default is pass
6. Transformations are optional but should be used to prevent your rule from being bypassed

در انتهای مطلب تعدادی مثال ساده درج کرده ام که بهتر است اول این تعاریف را برای فهم بهتر آن ها مطالعه بفرمایید.

اپراتورها که با @ شروع می شوند می توانند regular expression, pattern یا keywordی باشند که در variableها چک بشوند. مثل contains یا eq یا ...

متغییرها یا variableها چیزی هستند که محتوی آن ها مقایسه می شود و می توانید از | (پایپ/یا) هم برای تعریف چند variable استفاده کنید یا از ! در ابتدا برای نقض و از & در ابتدا برای مشخص کردن تعداد Variable استفاده کنید.

در مورد اخیر (&) مثلاً برای چک کردن HTTP responses هایی که Content-Type header ندارند چنین ruleی می نویسیم. یعنی تعداد این متغییر eq=0

SecRule &RESPONSE_HEADERS:Content-Type &quot@eq 0&quot &quotlog,auditlog,msg:'alert message'&quot

پرکاربردترین variableها بشرح ذیل هستند :

• ARGS is a collection so it means all arguments including the POST Payload.
• ARGS_GET contains only query string parameters.
• ARGS_POST contains arguments from the POST body.
• FILES Contains a collection of original file names. Available only on inspected multipart/form-data requests.
• FULL_REQUEST Contains the complete request: Request line, Request headers and Request body.
• QUERY_STRING Contains the query string part of a request URI. The value in QUERY_STRING is always provided raw, without URL decoding taking place.
• REQUEST_BODY Holds the raw request body. This variable is available only if the URLENCODED request body processor was used, which will occur by default when the application/x-www-form-urlencoded content type is detected, or if the use of the URLENCODED request body parser was forced.
• REQUEST_HEADERS This variable can be used as either a collection of all of the request headers or can be used to inspect selected headers.
• REQUEST_METHOD This variable holds the request method used in the transaction.
• REQUEST_URI This variable holds the full request URL including the query string data (e.g., /index.php?p=X).

برای اعمال تغییرات روی text قبل از چک شدن از Transformation functions استفاده می شود که در کنار اکشن ها با t:[Transformationfunctions] مشخص می شوند. مثلا t:lowercase یعنی همه text در variable بصورت حروف کوچک مقایسه شود.

اکشن ها کاری هستند که باید درصورت match شدن operator با variableها انجام شود و برای تعریف چند action آن ها را با , جدا می کنیم. پنج Action Group وجود دارد که دستورات مختلف ذیل آن ها دسته بندی می شوند.

اولین اکشنی که باید درج کنید id است.

همچنین با اکشن chain می توانید چند rule متوالی را به هم وصل کنید و and انجام دهید.

همچنین منظور از phase پنج فاز request cycle هستند. یعنی در کدام یک از فازها این rule اعمال شود.

1.Request headers → REQUEST_HEADERS

2.Request body → REQUEST_BODY

3.Response headers → RESPONSE_HEADERS

4.Response body → RESPONSE_BODY

5.Logging → LOGGING

همانطور که قبلاً عرض کردم خیلی گزینه و امکانات در اختیار دارید و از جمله مباحثی است که بهتر است یک ebook خوب و ترجیحاً جدیدتر درباره اش پیدا کنید و درکنار مستنداتش یکبار مطالعه بفرمایید تا روی مبحث تسلط پیدا کنید. یکی از بهترین کتابها ModSecurity Handbook است که هر چند در مورد نسخه 2 و کمی قدیمی است اما در کنار مستندات بسیار مفید خواهد بود.

در پایان تعدادی مثال ساده و توضیح آن ها را بنقل از SANS در تصویر ببینیم: