آشنایی با mod_security

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

http://www.webapp.com/login.php?username=admin';DROP%20TABLE%20users--

در صورتی که نرم‌افزار شما در مقابل SQL Injection ضعف داشته باشد، فراخوانی آدرس بالا ممکن است به راحتی کلیه اطلاعات کاربرانتان را پاک کند. آیا از اطلاعات بانک اطلاعاتی خود بطور مرتب نسخه‌های پشتیبان تهیه می‌کنید؟

mod_security یک سیستم کشف و پیشگیری از مزاحمت مخصوص برنامه‌های کاربردی وب است. به زبان دیگر می‌توان آنرا دیوار آتش برنامه‌های کاربردی وب نیز نامید. این سیستم به صورت یک ماژول بر روی سرویس‌دهنده وب آپاچی نصب شده و همانند یک چتر حفاظتی بر روی برنامه‌های کاربردی وب عمل می‌نماید.

یک تصویر شماتیک از نحوه عمل ModSecurity

چرا باید از mod_security استفاده کنید؟
چند سال پیش که من (نگارنده) شروع به کار بر روی mod_security کردم، از snort برای مانیتور کردن ترافیک وب خود استفاده می‌کردم. من خیلی خوب کار کرده بودم. به Snort گفته بودم که چه کلمات کلیدی برای من جالب است و این برنامه هرگاه که به این کلمات کلیدی بر می‌خورد، به من اطلاع می‌داد. ولی من به چیز بیشتری نیاز داشتم. من مایل بودم بتوانم آزادی لازم برای تعریف قوانین پیچیده و توانایی اجرای عکس العمل‌های مرتبط با HTTP را داشته باشم. علاوه بر این، نصب و پیاده سازی یک سیستم کشف مزاحمت (IDS) هر جا که یک سرویس‌دهنده وب وجود داشته باشد کاری است بسیار وقت گیر و گران.

در همان زمان سعی کردم تا از ترکیب mod_rewrite و mod_setenvif استفاده کنم. با استفاده از mod_rewrite تشخیص کلماتی مانند drop و table بسیار آسان بود و می‌توانستم سرویس گیرنده ارسال کننده چنین کلماتی را به آدرس دیگری دور از نرم‌افزار وب هدایت کنم تا از حمله جلوگیری شود. البته این کار تنها جلوی نفوذگران کم تجربه را می‌گرفت. نفوذگران پرتجربه‌تر می‌توانستند با بکارگیری متد POST بجای GET همان URL مورد نظرشان را فراخوانی کنند. از آنجایی که متغییرهای ارسال شده توسط متد پست توسط بسیاری از ماژول‌های آپاچی در نظر گرفته نمی‌شوند، حمله می‌توانست انجام شود.

اکنون که نیاز به داشتن یک ابزار جدید برای پوشش دادن این نیاز حفاظتی ایجاد شده بود، من دو راه در مقابل خود داشتم: از جاوا استفاده کنم و یک سیستم Reverse proxy و Application Gateway برای نرم‌افزارهای تحت وب بنویسم، یا اینکه یک ماژول برای آپاچی بنویسم که در بالای کدهای موجود اجرا شود. راه نخست مستلزم صرف وقت بسیار بود و شاید از نتیجه کار نیز تعداد بسیار کمی استفاده می‌کردند (خودم هم از آن استفاده نمی‌کردم!) از آنجایی که مایل بودم ابزاری بنویسم که قابل انعطاف و سهل الاستفاده باشد، راه دوم را انتخاب کردم و هرگز پشت سر خود را نگاه نکردم.

به مثالی که در بالا زدیم باز می‌گردیم. برای جلوگیری mod_security از حمله‌ای که با drop table صورت می‌گیرد، کافی است خط زیر را به فایل پیکربندی سرویس‌دهنده آپاچی خود اضافه کنید:

SecFilter "drop[[:space:]]table"

تنها پارامتر SecFilter یک Regular Expression است که به درخواست‌های وارد شده به سرویس‌دهنده اعمال می‌گردد. این شبیه کاری است که mod_rewrite انجام می‌دهد با این تفاوت که mod_security هم بر روی GET و هم بر روی POST عمل می‌کند. اینجا لازم است بگویم که پیاده سازی قابلیت مانیتور کردن POST بر روی آپاچی 1.3 کار بسیار دشوار بود.