این مقاله عضو خوشهٔ «سرور و عملیات» است. موضوع را جدی انتخاب کرده‌ام چون در تجربهٔ عملی روی سرورهای اشتراکی، آلودگی به وب‌شل از آن اتفاق‌هایی است که صاحب سایت دیر می‌فهمد و دیر متوجه خسارت می‌شود: معمولاً از طریق شکایت میزبان، نه از طریق پنل خودش.
وب‌شل، یک فایل اسکریپت است که روی سرور قرار می‌گیرد و به مهاجم اجازه می‌دهد از طریق مرورگر یا یک درخواست ساده، فرمان اجرا کند؛ فایل بگذارد، فایل بردارد، دیتابیس بخواند، و از سرور تو به بقیه دنیا ترافیک بفرستد. نام «شل» از همین‌جا است: یک ورودی فرمان، از راه دور.
چرا روی هاست اشتراکی خطرناک‌تر است
سه دلیل عملی:
همسایه‌ها شریک‌اند. روی سروری که ده‌ها حساب دارد، یک حساب آلوده می‌تواند به اعتبار IP کل سرور آسیب بزند. یعنی اگر سایت تو سالم باشد ولی همسایه‌اش نباشد، ایمیل تو هم تحت تأثیر قرار می‌گیرد.
منابع مشترک‌اند. سهم روزانهٔ ارسال، سهم CPU و سهم ورودی/خروجی دیسک، بین همه تقسیم می‌شود. وقتی یک حساب آلوده شروع به ارسال انبوه می‌کند، همه احساس کندی می‌کنند و معمولاً هیچ‌کس نمی‌داند چرا.
دسترسی سطح روت، همه‌چیز را در یک صفحه می‌گذارد. اگر چند حساب روی یک سرور داشته باشی، آلودگی یک حساب می‌تواند راهی به بقیه باشد؛ مگر اینکه ایزولاسیون درست تنظیم شده باشد.
از کجا وارد می‌شود
به‌ترتیب فراوانی در پروژه‌های واقعی:
افزونه یا قالب به‌روزشده. نه از مخزن رسمی، بلکه از سایتی که نسخهٔ «نال‌شده» می‌فروشد. این شایع‌ترین ورودی در سایت‌های ایرانی است. مهاجم، فایل‌ها را قبل از تو می‌گیرد و فقط یک درِ پشتی می‌گذارد.
افزونهٔ قدیمی با آسیب شناخته‌شده. بسیاری آلودگی‌ها از یک آسیب قدیمی در افزونه‌ای است که دو سال به‌روز نشده.
رمز ضعیف یا دوباره‌استفاده‌شده. هم حساب وردپرس، هم حساب FTP یا پنل هاست. اگر رمز پنل با رمز یک سرویس دیگر یکی باشد و آن سرویس افشا شده باشد، درِ تو هم باز است.
بارگذاری فایل از طریق فرم. فرم تماسی که پیوست قبول می‌کند و نوع فایل را درست بررسی نمی‌کند؛ یا افزونه‌ای که مسیر ذخیرهٔ بارگذاری‌شده را بیرون از پوشهٔ امن نگه می‌دارد.
حساب کاربری با دسترسی بیش از نیاز. کارمندی که نقش مدیر کل دارد، فقط برای اینکه یک بار لازم بوده چیزی را عوض کند.
اولین نشانه‌ها؛ ترتیب شک
نشانه‌ها به‌ترتیب محتمل بودن:
فایل تازه‌ای که تو نساخته‌ای. داخل مسیر بارگذاری‌ها، یا کنار فایل‌های قالب. نام‌های تصادفی با پسوندهای فریبنده، یا فایل‌هایی با نام‌های معمولی که باید آن‌جا نباشند.
تاریخ تغییر انبوه. اگر بعد از یک آپدیت معمولی، ده‌ها فایل تاریخ تغییر دارند، یا فرآیند واقعی بوده یا یک اسکریپت دست‌جمعی کار کرده. تفاوت را با محتوای فایل می‌فهمی، نه با تاریخ.
ترافیک خروجی غیرعادی. حجم ارسال ایمیل بالا، یا درخواست‌های بیرونی زیاد. روی هاست اشتراکی، معمولاً پیامک میزبان اول‌ترین نشانه است.
خطاهای عجیب در لاگ. درخواست‌هایی به مسیرهایی که در سایت تو وجود ندارند، با کاربرِ عامل غیرمرورگری.
ظاهر سایت تغییر نکرده، ولی رفتار عوض شده. مثلاً فرم‌ها کار نمی‌کنند یا صفحه‌ای کند شده، بدون اینکه چیزی به‌روز کرده باشی.
و نشانهٔ مهمی که اشتباه تفسیر می‌شود: نبودِ علامت. بسیاری از وب‌شل‌ها ماه‌ها بی‌صدا می‌مانند و فقط دسترسی نگه می‌دارند.
جستجوی ساختاریافته، نه چشمی
روش دستی و بی‌ابزار، جواب نمی‌دهد؛ چون هزاران فایل داری. جستجو باید الگوریتمی باشد. چهار الگوی پرتکرار در کد وب‌شل:
توابع اجراسازی با ورودی از بیرون. ترکیب توابعی که متن را به کد تبدیل می‌کنند و ورودی‌شان را از پارامتر درخواست می‌گیرند. در کد سالم وردپرس، این ترکیب تقریباً هیچ‌جا معنا ندارد.
کدهای فشرده و بی‌نام. رشته‌های طولانی بدون فضای خوانا، همراه با بازگشایی زنجیره‌ای.
تغییر نام‌کاربری در فایل‌های هسته. وردپرس فایل‌های هسته دارد که فقط با نسخهٔ رسمی عوض می‌شوند؛ اگر یکی از آن‌ها دست‌خورده باشد، یا مهاجم آن را عوض کرده یا افزونه‌ای بد.
فایل‌های PHP در مسیر بارگذاری. در مسیر آپلود، فایل PHP نباید باشد؛ مگر در مورد‌های خاص افزونه‌ها.
یک مثال عملی با خط فرمان، برای دیدن فایل‌های PHP که در بیست‌وچهار ساعت اخیر تغییر کرده‌اند:
find public_html -name "*.php" -mtime -1 -printf '%T@ %p\n' | sort -nو برای دیدن فایل‌هایی که کد اجراسازی دارند:
grep -RnsE '(eval\(|assert\(|base64_decode\(|str_rot13\()' public_html/wp-content/uploads | head -50این دو خروجی، فهرست بررسی است، نه حکم. بسیاری از موارد، افزونهٔ مشروع‌اند. برای همین مرحلهٔ بعد مهم است.
مقایسه با نسخهٔ سالم؛ مطمئن‌ترین روش
هیچ جستجوی متن‌کاوانه‌ای، جای «مقایسه با فایل سالم» را نمی‌گیرد. سه مقایسهٔ قابل‌اعتماد:
یک: فایل‌های هسته با نسخهٔ رسمی. هر فایل هسته را با همان فایل در بستهٔ رسمی وردپرس مقایسه کن. هر اختلافی، جز تغییرات عامدانهٔ خودت، مشکوک است.
دو: افزونه‌ها با نسخهٔ رسمی مخزن. افزونهٔ نصب‌شده را با همان نسخه از مخزن رسمی مقایسه کن. اگر نسخه‌ای که داری در مخزن رسمی نیست، مشکل از همان‌جاست.
سه: فهرست هش. پیش از آلودگی، فهرست هش فایل‌هایت را در یک فایل نگه دار. بعد از شک، دوباره بگیر و اختلاف را ببین. این ارزان‌ترین کاری است که می‌شود کرد و تقریباً هیچ‌کس انجامش نمی‌دهد تا نیازش پیدا شود:
find public_html -type f -name "*.php" -exec sha256sum {} \; > /home/user/php-hashes.txtنکتهٔ تشخیصی که پیش‌تر هم برایم روشن شده: php -l آلودگی را نمی‌بیند. یک فایل خراب‌شده که فقط بخش اجرا از آن افتاده باشد، از نظر نحوی کاملاً سالم گزارش می‌شود. پس lint ابزار سلامت فایل است، ابزار نه.
پاک‌سازی یا بازسازی؛ انتخاب صادقانه
اینجا جواب محبوب را نمی‌دهم؛ جواب درست‌تر را می‌دهم. اگر آلودگی جدی پیدا کردی، بازسازی، امن‌تر از پاک‌سازی است. دلیلش ساده است: مهاجمی که یک بار دسترسی گرفته، معمولاً بیش از یک در گذاشته است. ممکن است در دیتابیس کد گذاشته باشد، در قالب، در افزونه، در حساب کاربری پنهان، یا در کران زمان‌بندی‌شده.
مسیر بازسازی، به همین ترتیب:
۱. سایت را از دسترس خارج کن و نسخهٔ فعلی را برای بررسی نگه دار؛ پاک نکن، چون مدرک است. ۲. هسته، قالب و افزونه‌ها را از منبع رسمی، دوباره نصب کن؛ نه آپدیت، بلکه جایگزینی کامل. ۳. فایل‌های مسیر بارگذاری را که نمی‌شناسی، منتقل کن بیرون از دسترس وب، سپس بررسی‌شان کن. ۴. دیتابیس: اگر آلودگی به کد درون جدول‌ها کشیده شده، بازگردانی از بکاپِ سالمِ پیش از آلودگی، تنها راه مطمئن است. ۵. رمز همهٔ حساب‌ها، از جمله پنل هاست و FTP را عوض کن؛ با رمز تازه و متفاوت. ۶. همهٔ کلیدهای API و توکن‌ها را باطل و دوباره بساز. ۷. لاگ ورود را برای هفته‌های گذشته ببین تا بفهمی ورود از کجا بوده.
اگر بکاپ سالم نداری، اول همین خلأ را ببند و بعد تصمیم بگیر؛ پاک‌سازی کور، معمولاً آلودگی را نگه می‌دارد و فقط علائم را کم می‌کند.
بعد از پاک‌سازی: درها را ببند
پاک کردن، آلودگی را تمام نمی‌کند؛ دلیلش را اگر نبندی، برمی‌گردد. فهرست حداقل:
به‌روزرسانی منظم. هسته، قالب و افزونه‌ها. افزونه‌ای که دو سال به‌روز نشده، باید حذف شود نه اینکه بماند.
کاهش دسترسی. نقش مدیر کل برای کسانی که لازم دارند، نه برای همه. اگر امکان دارد ورود مدیر را با تأیید دوم‌مرحله‌ای ببند.
بستن اجرای PHP در مسیر بارگذاری. این کار جلوی بسیاری از بارگذاری‌های مخرب را می‌گیرد:
<Directory "/home/user/public_html/wp-content/uploads">
php_admin_flag engine Off
</Directory>روی LiteSpeed با فایل .htaccess هم این کار شدنی است. اگر نمی‌دانی سرورت چیست، این را از میزبان بپرس؛ حدس، بدتر از بازگشت آلودگی است.
ردیف بستن توابع PHP خطرناک. توابعی که برای اجرای فرمان لازم‌اند، در سایت معمولی هیچ کاربرد ندارند.
محدودکردن دسترسی پنل از IP. اگر پنل هاست از هر IPای باز باشد و رمز ضعیف باشد، بقیهٔ کارها بی‌فایده است.
پایش. یک بررسی روزانهٔ تاریخ تغییر فایل‌ها، و یک هشدار حجم ارسال ایمیل. این دو، آلودگی دوم را قبل از شکایت میزبان لو می‌دهند.
چه چیزی را نباید بپذیری
سه ادعای بازاری که در این موضوع زیاد می‌شنوم:
«افزونهٔ امنیتی نصب کن، تمام است.» افزونهٔ امنیتی مفید است ولی نسخهٔ فایل‌های تغییر‌یافتهٔ خودت نیست. هیچ افزونه‌ای، کدی که مهاجم در فایل قالب گذاشته را از فایل‌های هسته رسمی جدا نمی‌کند؛ مگر با مقایسهٔ واقعی، و آن را افزونه‌های مبتنی بر مخزن انجام می‌دهند، نه همهٔ افزونه‌های امنیتی.
«سایت تمیز شد، دیگر نگران نباش.» بدون بستن راه ورود، این جمله فقط یک بازهٔ زمانی دارد.
«ما از راه دور پاک می‌کنیم، تو فقط هزینه بده.» گاهی درست است؛ ولی باید گزارش کتبی بدهند: چه فایل‌هایی، چه تغییری، و راه ورود چه بوده. بدون گزارش، تو نمی‌دانی پاک شده یا پنهان.
یک نمونهٔ تشخیصی، مرحله‌به‌مرحله
فرض کن میزبان به تو پیام داده که از حساب تو ارسال انبوه هرزنامه شده. ترتیب کاری که من انجام می‌دهم، با جزئیات:
یک: دامنهٔ گزارش را با دامنهٔ خودت تطبیق بده. در سروری که ده حساب دارد، ممکن است حساب آلوده، مال تو نباشد. اولین سؤال، قبل از هر اقدام: کدام مسیر؟ اگر دسترسی روت نداری، این را کتبی از میزبان بخواه؛ نه شفاهی.
دو: بازهٔ زمانی را مشخص کن. از پیام میزبان، تاریخ و ساعت را بردار. سپس فایل‌هایی که در آن بازه عوض شده‌اند را دربیاور:
find public_html -type f -newermt "2026-09-01" ! -newermt "2026-09-02" -printf '%p\n'اگر در آن بازه کاری نکرده‌ای، هر فایلی که پیدا شود، مظنون اصلی است.
سه: لاگ وب‌سرور را در همان بازه ببین. درخواست‌های POST به مسیرهای غیرعادی، یا درخواست‌های پشت‌سرهم از یک IP بیرونی. اگر مهاجم از طریق فرم لاگین وارد شده، در لاگ ورود وردپرس هم نشانه هست.
چهار: ارتباط خروجی را ببین. اگر یک فایل ناشناس، به دامنهٔ بیگانه‌ای وصل می‌شود، تو با یک درِ باز روبه‌رویی، نه فقط با یک فایل بد.
پنج: بعد از بستن، دوباره بررسی کن. یک هفته پس از پاک‌سازی، تاریخ تغییر فایل‌ها و حجم ارسال را دوباره نگاه کن؛ آلودگی که برنگردد، تأیید شده است.
یک تجربه: در همان موردی که از آن صحبت کردم، فایل آلوده در مسیر بارگذاری نبود؛ در پوشهٔ یک قالب قدیمی بود که دیگر استفاده نمی‌شد و حذف نشده بود. این حالت را جدی بگیر: پوشه‌های رهاشده، همان جاهای امنِ فراموش‌شده‌اند.
پوشه‌های رهاشده؛ بزرگ‌ترین سطح حملهٔ خاموش
خیلی از سایت‌ها، سال‌ها پوشه‌هایی را نگه می‌دارند که هیچ‌کس به آن‌ها اشاره نمی‌کند: نسخهٔ قبلی قالب، پوشهٔ تست، زیردامنه‌ای که یک‌بار برای کمپین ساخته شده، یا نصبی که روی مسیر دیگری امتحان شده. این‌ها چند خطر دارند:
به‌روز نمی‌شوند. چون در فهرست هیچ‌کس نیستند، نسخهٔ قدیمی افزونه و قالب در آن‌ها باقی می‌ماند؛ و آسیب‌های شناخته‌شده، همان‌جا باز می‌مانند.
از مسیر وب قابل دسترسی‌اند. اگر آدرس را حدس بزنند یا در نقشهٔ سایت مانده باشند، فایل‌های آن نصبِ فراموش‌شده، اجرا می‌شود.
احتمالاً بکاپ هم گرفته نمی‌شوند. یعنی اگر از آن‌ها استفاده‌ای شود، نسخهٔ سالمی نداری.
روش درست‌کردن: فهرست کامل مسیرهای زیر دامنه‌هایت را دربیاور، برای هر کدام بنویس چه کاری می‌کند و آخرین باری که کسی به آن نگاه کرده کی است. هر مسیر که پاسخ مشخص ندارد، یا حذف می‌شود یا به‌روز و پایش می‌شود. کاری که بی‌خطرتر است، جابه‌جایی به بیرون از دسترس وب و تست شکست است: اگر هیچ‌چیز خراب نشد، حذفش کن.
و این فهرست را در همان اسناد پروژه نگه دار؛ در روز آلودگی، این برگه باارزش‌ترین چیزی است که داری.
حساب‌های پنهان و کران‌های دستکاری‌شده
دو جایی که در پاک‌سازی معمولی فراموش می‌شوند:
حساب کاربری اضافه. مهاجم، یک مدیر می‌سازد و ماه‌ها بعد از همان برمی‌گردد. فهرست کاربران با نقش مدیر را نگاه کن و هر نامی که نمی‌شناسی را بررسی کن؛ نه فقط حذف، بلکه ببین چه زمانی ساخته شده تا با بازهٔ آلودگی تطبیق بدهی.
کارهای زمان‌بندی‌شده. اگر مهاجم یک کران گذاشته باشد، بعد از پاک‌سازی، فایل آلوده دوباره ساخته می‌شود. علامت کلاسیکش این است که فایل پاک‌شده، چند ساعت بعد با همان نام برمی‌گردد. پس هم کران‌های وردپرس را ببین و هم کران‌های سطح اکانت در پنل هاست.
نکتهٔ تشخیصی مهم: اگر بعد از بازسازی کامل از منبع رسمی، آلودگی برگشت، یعنی در دیتابیس یا در کران بیرونی، چیزی باقی مانده است؛ نه اینکه پاک‌سازی «کم» بوده.
جمع‌بندی
وب‌شل، علائم کم‌صدا و خسارت بلند دارد؛ روی اشتراکی، خسارتش به همسایه‌ها هم می‌رسد. روش عملی: شک را با فهرست فایل‌های تازه و تاریخ تغییر شروع کن، با جستجوی ساختاریافته محدودش کن، با مقایسه به نسخهٔ سالم تأیید یا ردش کن، و بعد از پاک‌سازی، راه ورود را ببند.
اگر آلودگی جدی است، وقت را با پاک‌سازی نیمه‌باز مصرف نکن: بازسازی از منبع رسمی و بازگردانی از بکاپ سالم، تقریباً همیشه سریع‌تر تمام می‌شود. و از همین امروز، فهرست هش فایل‌ها و بکاپِ تست‌شده را داشته باش؛ دقیقاً همان دو چیزی که در لحظهٔ آلودگی آرزو می‌کنی وجود داشتند.
اعضای دیگر این خوشه، ادامهٔ همین مسیرند: مجوز فایل‌ها و اعداد درست، REST API و اینکه سایت تو چه اطلاعاتی را علنی می‌گذارد، و راهنمای بکاپ و تست بازگردانی در سی‌پنل.
یرتینهی از مالوضورتی بر دارهی حس بشو دهیمت استفادهی وقت حالیف رایبر داره یانیامده به از دسترسی و بی ا دیره یا نیسته استفادهیادار باشتالله
مقالبی بخوانی
- تفاوت LiteSpeed با Nginx و Apache برای وردپرس؛ کدام وب‌سرور واقعیت را سریع می‌کند؟
- disable-dangerous-php-functions
امید بداق
من متخصص سئو که عاشق اینه به کسب‌وکارها کمک کنه تو گوگل دیده بشن!از وردپرس گرفته تا سئو، هرچیزی که برای رشد آنلاین نیاز داری میتونم کمکت کنم.