آموزش یک آنتی شلر قدرتمند ارائه شده از گروه امنیتی MLD
«شل» یک فایل اسکریپت مخرب — معمولاً PHP — است که مهاجم روی وبسرور شما آپلود میکند تا از طریق مرورگر دستور اجرا کند، فایل بخواند و بنویسد و به پایگاه داده دسترسی بگیرد. محافظت در برابر شل با نصب یک اسکریپت «آنتیشل» انجام نمیشود؛ آنچه واقعاً جواب میدهد ترکیب چند لایه است: بستن مسیر ورود، جلوگیری از اجرای کد در مسیرهای نوشتنی، کمکردن اختیارات PHP، اسکن مداوم و کمترین سطح دسترسی.
شل چیست و چرا فایروال جلوی آن را نمیگیرد؟
شل (Web Shell) یک فایل اجراییِ سمت سرور است که رابط سادهای برای اجرای فرمان در اختیار مهاجم میگذارد. چون درخواستها روی همان پورت ۸۰ و ۴۴۳ و با همان کاربری که وبسرور با آن اجرا میشود پردازش میشوند، از دید فایروال شبکه یک بازدید عادی از سایت به نظر میرسند. با یک شل فعال، مهاجم میتواند:
- فایلهای سایت را بخواند یا تغییر دهد، از جمله فایل پیکربندی و اطلاعات اتصال به دیتابیس
- کاربر مدیر تازه در سیستم مدیریت محتوا بسازد یا لینک و محتوای مخفی تزریق کند
- از سرور شما برای ارسال اسپم یا حمله به دیگران استفاده کند و IP سرور را در لیستهای سیاه بیندازد
- در صورت وجود ضعف در سطح سیستمعامل، سطح دسترسی را بالاتر ببرد
شل از کجا وارد میشود؟
تقریباً همیشه یکی از این چهار مسیر:
- افزونه، قالب یا کتابخانه آسیبپذیر: رایجترین حالت. یک باگ آپلود فایل یا اجرای کد از راه دور در کدی که ماهها بهروزرسانی نشده.
- فرم آپلود بدون اعتبارسنجی درست: فرمی که فقط پسوند را چک میکند و با نامهایی مثل
file.php.jpgیا پسوندهای کمترشناختهشده دور زده میشود. - اعتبارنامه لو رفته: رمز FTP، کنترلپنل یا SSH که روی یک کامپیوتر آلوده ذخیره شده یا در جای دیگری تکرار شده است.
- حساب آلوده در همان سرور: اگر حسابهای کاربری از هم جدا نباشند، آلودگی یک سایت میتواند به بقیه سرایت کند. روی سرورهای اشتراکی، لایسنس کلودلینوکس که در سطح هسته کار میکند حسابها را از هم جدا نگه میدارد تا مشکل یا حمله یک سایت بقیه را درگیر نکند.
نکته مهم این است که فایل شل معلول است، نه علت. تا وقتی مسیر ورود باز باشد، حذف فایل فقط مهلتی کوتاه میخرد و شل دوباره برمیگردد. رایجترین شکل این ورود هم پیچیده نیست: لو رفتن رمز FTP از روی کامپیوتر مدیر سایت، همان الگویی که در کارزار Gumblar و درسهای امروزی آن بررسی شده است.
لایه ۱: کاهش سطح حمله
هسته، افزونهها و قالبها را بهروز نگه دارید و هر چیزی را که استفاده نمیکنید حذف کنید — نه صرفاً غیرفعال. فایلهای افزونه غیرفعال هم روی دیسک باقی میمانند و در بسیاری از آسیبپذیریها همان فایل مستقیم قابل فراخوانی است. نسخه PHP را هم روی شاخهای نگه دارید که هنوز وصله امنیتی میگیرد.
لایه ۲: جلوگیری از اجرای PHP در مسیرهای نوشتنی
مؤثرترین اقدام تکی همین است. اگر مهاجم بتواند فایل آپلود کند اما آن فایل اجرا نشود، شل بیاثر میماند. در آپاچی، داخل پوشه آپلود یک فایل .htaccess با این محتوا بگذارید:
<FilesMatch ".(php|php[0-9]|phtml|phar|inc)$">
Require all denied
</FilesMatch>
در انجینایکس معادل آن در بلوک سرور نوشته میشود:
location ~* /wp-content/uploads/.*.php$ { deny all; }
پیش از اعمال، پیکربندی را با apachectl configtest یا nginx -t بررسی کنید و بعد سرویس را ریلود کنید. اگر افزونهای واقعاً به اجرای PHP در مسیر آپلود نیاز دارد (که کم پیش میآید)، همان یک فایل را استثنا کنید نه کل پوشه را.
لایه ۳: محدودکردن اختیارات PHP
در php.ini توابعی را که سایتهای معمول به آنها نیاز ندارند غیرفعال کنید:
disable_functions = exec, passthru, shell_exec, system, proc_open, popen, dl
هشدار: این تغییر میتواند برخی افزونهها یا ابزارهای بکاپ را بشکند. اول روی یک سرور آزمایشی یا خارج از ساعت اوج اعمال کنید و لاگ خطا را بررسی کنید. همچنین open_basedir را طوری تنظیم کنید که هر سایت فقط به مسیر خودش و پوشه موقت خودش دسترسی داشته باشد.
روی سرورهای اشتراکی، امکاناتی مانند PHP Selector در کلودلینوکس اجازه میدهد نسخه PHP را برای هر حساب جداگانه انتخاب کنید؛ یعنی محدودیتها را بهجای کل سرور، برای هر مشتری تنظیم میکنید.
لایه ۴: اسکن بدافزار و پایش یکپارچگی فایل
پیشگیری کامل نیست، پس باید بتوانید تغییر ناخواسته را زود ببینید. سه ابزار عملی:
- مقایسه با نسخه اصلی: در وردپرس دستور
wp core verify-checksumsوwp plugin verify-checksums --allفایلهای دستکاریشده را نسبت به مخزن رسمی نشان میدهد. - فایلهای تازهتغییریافته:
find /home/user/public_html -name "*.php" -mtime -7 -lsفقط فهرست میگیرد و چیزی را تغییر نمیدهد. فایل PHP تازه در پوشه آپلود یا کش تقریباً همیشه مشکوک است. - اسکنر بدافزار سمت سرور: ابزارهایی مانند ClamAV با دیتابیس امضای بهروز، یا اسکنرهای تجاری که فایل را در لحظه آپلود بررسی میکنند. توجه کنید که هیچ اسکنر امضامحوری همه شلهای مبهمسازیشده را پیدا نمیکند؛ این لایه مکمل است، نه جایگزین. روی سرورهای هاستینگ یکی از رایجترین این ابزارها CXS است و دستورهای پرکاربرد اسکنر CXS کار با آن را نشان میدهد.
کنار بررسی سمت سرور، یک نگاه از بیرون هم کمک میکند: بررسی سلامت سایت بدون نیاز به دسترسی سرور نشان میدهد گواهی SSL، رکوردهای DNS، زنجیره ریدایرکت و خطاهای کنسول مرورگر از دید یک بازدیدکننده عادی چه وضعیتی دارند؛ ریدایرکت یا اسکریپت تزریقشده معمولاً همینجا خودش را نشان میدهد.
لایه ۵: کمترین سطح دسترسی و WAF
مجوز پوشهها را ۷۵۵ و فایلها را ۶۴۴ بگذارید و هرگز ۷۷۷ ندهید. فایل پیکربندی حاوی رمز دیتابیس باید محدودتر باشد (۶۴۰ یا ۶۰۰). هر سایت را با کاربر سیستمی جداگانه و pool مستقل PHP-FPM اجرا کنید تا فرآیند یک سایت نتواند فایل سایت دیگر را بخواند. FTP ساده را کنار بگذارید و ورود SSH را به کلید محدود کنید.
در لبه، یک WAF مانند ModSecurity با قوانین OWASP CRS بخش بزرگی از تلاشهای خودکارِ آپلود و فراخوانی شل را پیش از رسیدن به PHP متوقف میکند. قوانین را ابتدا در حالت فقطگزارش اجرا کنید تا موارد مثبت کاذب را بشناسید. اگر ترجیح میدهید این پیکربندیها را خودتان انجام ندهید، در سرور مجازی مدیریتشده ایران نصب و پیکربندی کنترلپنل، عیبیابی نرمافزارهای نصبشده و پشتیبانی فنی بر عهده تیم آنلاین سرور است.
اگر شل پیدا کردید چه کنید؟
پاککردن فایل، اولین کار نیست. ترتیب درست:
- پیش از هر تغییری یک کپی کامل از فایلها و دیتابیس بگیرید؛ هم برای بازگشت و هم برای بررسی بعدی.
- لاگ دسترسی وبسرور را حول زمان تغییر فایل بررسی کنید تا مسیر ورود مشخص شود.
- دنبال درِ پشتیهای دیگر بگردید: کرانجابهای ناشناس، فایل
.htaccessدستکاریشده، کاربر مدیر تازه، و کد تزریقشده در ابتدای فایلهای قالب. - همه رمزها را عوض کنید: کنترلپنل، دیتابیس، FTP، SSH و حسابهای مدیر.
- مطمئنترین راه بازیابی، بازسازی سایت از نسخه سالم و کد اصلی است، نه وصلهکردن فایلهای آلوده.
اگر مطمئن نیستید سرور کاملاً پاک شده، خدمات پشتیبانی و مدیریت سرور آنلاین سرور روی هاردنینگ ویندوز و لینوکس، فایروال، مقابله با نفوذ و نصب و رفع مشکل کنترلپنل کار میکند.
جمعبندی
هیچ اسکریپت واحدی «آنتیشل» نیست. امنیت در برابر شل حاصل چند تصمیم ساده و پایدار است: بهروز نگهداشتن کد، غیرفعالکردن اجرای PHP در مسیرهای آپلود، محدودکردن توابع پرخطر، جداسازی حسابها و داشتن روشی قابلاتکا برای دیدن تغییرات فایل. هیچکدام بهتنهایی کافی نیست، اما کنار هم هزینه حمله را تا جایی بالا میبرند که مهاجم خودکار سراغ هدف بعدی برود. در کنار اینها، حملههایی مانند CSRF یا XSRF از سمت مرورگر کاربر انجام میشوند و به لایه دیگری از محافظت نیاز دارند.