آموزش امنیت وردپرس

ترتیب واقعی، و چرا بیشتر چک لیست ها ترتیب اشتباهی دارند

یک چک لیست امنیت وردپرس معمولا سی مورد دارد و همه شان هم اندازه به نظر می رسند. در عمل این طور نیست. سه مورد اول بیشتر از بیست و هفت مورد بعدی جلوی مشکل را می گیرند، و ترتیب چیزی است که کسی نمی نویسد چون فهرست بلند حرفه ای تر به نظر می رسد.

ترتیبی که ما روی سایت مشتری اجرا می کنیم شش قدم دارد و بر اساس آسانی مرتب نشده، بر اساس اینکه هرکدام چقدر جلوی مشکل را می گیرد مرتب شده.

اول به روزرسانی، چون بیشتر نفوذهای موفق به یک وردپرس از یک آسیب پذیری عمومی و وصله شده می آیند. بعد کمترین دسترسی، چون اندازه خسارت را حساب هایی تعیین می کنند که وارد شده اند. بعد تایید دو مرحله ای، که رمز لو رفته را از یک فاجعه به یک هشدار تبدیل می کند. بعد بکاپی که یک بار برگردانده شده، چون بکاپ تست نشده یک فرض است نه یک نسخه. بعد یک افزونه امنیتی که هنوز نگهداری می شود. و آخر از همه سخت کردن صفحه ورود، که مفید است و آخر فهرست است، نه اول آن.

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

به روزرسانی؛ چرا این یکی از همه بیشتر جلوی مشکل را می گیرد

یک آسیب پذیری وقتی منتشر می شود، دو چیز همزمان به دنیا می آید: توضیح مشکل و وصله اش. از همان لحظه، هر کسی که بخواهد از آن استفاده کند دقیقا می داند کجا را بزند، و هر کسی که به روز کرده باشد از فهرست بیرون است. کل بازی همان فاصله بین انتشار و به روزرسانی است.

روی همین سایت، از مارس ۲۰۲۵ تا امروز، اسکنر آسیب پذیری ۱۳ اطلاعیه برای نرم افزارهای نصب شده روی همین یک نصب ثبت کرده. ۱۰ تای آنها در افزونه ها بودند، ۲ تا در خود هسته وردپرس و ۱ تا در یک قالب. از نظر نوع، هفت تا اسکریپت میان سایتی بودند، دو تا کنترل دسترسی شکسته، و بقیه یکی یکی: اجرای کد دلخواه، افشای داده حساس، بارگذاری فایل دلخواه و تزریق آبجکت PHP.

دوازده تای این سیزده تا با یک به روزرسانی بسته شدند و بیشترشان ظرف چند روز. این عدد چیزی است که ارزش نگاه کردن دارد: در هجده ماه، روی یک سایت که هیچ اتفاق خاصی برایش نیفتاده، سیزده بار نرم افزاری که رویش نصب بوده آسیب پذیر اعلام شده و تقریبا هر بار جواب یک دکمه بوده.

و حالا چیزی که کمتر گفته می شود و ما خودمان با آن روبرو شده ایم: شمارنده به روزرسانی که صفر نشان می دهد، دلیل به روز بودن نیست. افزونه های تجاری از کانال خودشان به روز می شوند و لایسنس منقضی شده شمارنده را ساکت می کند، نه به روز. روی همین نصب، شمارنده صفر است و اسکنر آسیب پذیری درباره یکی از موارد با آن مخالف است. به همین دلیل اسکنر آسیب پذیری، جدا از شمارنده به روزرسانی، لازم است؛ دومی نصب شما را می بیند و اولی فهرست منتشر شده را.

یک نمونه نزدیک از خود هسته را در نوشته ای جداگانه شرح داده ایم: وصله امنیتی وردپرس ۷.۰.۴ و اینکه کدام سرورها واقعا در خطر بودند.

حساب ها؛ چرا روی سایتی با ۱۲۲۴ کاربر فقط یک مدیر داریم

روی همین سایت ۱۲۲۴ حساب کاربری وجود دارد. یکی از آنها مدیر است. ۱۲۲۳ تای دیگر نقش هایی دارند که نمی توانند چیزی نصب کنند، نمی توانند فایل قالب را ویرایش کنند و داده هیچ کاربر دیگری را نمی بینند.

این عدد یک تصمیم است نه یک تصادف، و دلیلش ساده است: حسابی که لو می رود فقط همان کاری را واگذار می کند که خودش می توانست بکند. کمترین دسترسی بوروکراسی نیست، اندازه انفجار است.

جایی که این قاعده معمولا می شکند دو تاست، و هر دو از سر خوش نیتی اند. اول، دادن حساب مدیر به یک توسعه دهنده یا یک آژانس «فعلا»، که هیچ وقت حذف نمی شود؛ فهرست مدیران یک سایت پنج ساله معمولا آدم هایی دارد که سه سال است با آن کار ندارند. دوم، نقش هایی که یک افزونه اضافه کرده. وردپرس اجازه ها را جمع می کند، پس افزونه ای که به مشترک ها یک توانایی تازه می دهد، فهرست دسترسی شما را عوض کرده و هیچ کجا خبرش را ننوشته است.

قدم بعدی تایید دو مرحله ای است و انتخاب روشش اهمیت دارد. روی این سایت فقط روش برنامه احرازکننده فعال است، نه پیامک و نه ایمیل. دلیلش این است که پیامک به شماره وابسته است و شماره را می شود از اپراتور گرفت، و ایمیل به صندوقی وابسته است که خودش با یک رمز باز می شود؛ اگر همان رمز لو رفته باشد، مرحله دوم دیگر مرحله دومی نیست.

و یک نکته که مخصوص وردپرس است: رمزهای برنامه. اینها رمزهای جداگانه ای هستند که برای اتصال ابزارها ساخته می شوند و تایید دو مرحله ای را دور می زنند، چون قرار است بدون آدم کار کنند. اگر دو مرحله ای را روشن کرده اید، فهرست رمزهای برنامه همان حساب را هم نگاه کنید؛ در غیر این صورت یک در باز کنار در قفل شده باقی مانده.

بکاپ تست نشده بکاپ نیست، و خودش هم می تواند نشت کند

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

اما یک نکته دوم هست که تقریبا هیچ جا گفته نمی شود، و ما با آن روی همین سرور روبرو شدیم.

افزونه رایج مهاجرت وردپرس، آرشیوهای دویست مگابایتی می سازد و آنها را داخل یک پوشه در wp-content می گذارد، و آن پوشه را با یک فایل htaccess. محافظت می کند. روی nginx آن فایل هیچ کاری نمی کند؛ اصلا خوانده نمی شود. ما پیش از اینکه قانون فعلی را بنویسیم، آزمودیم و دیدیم آرشیو با یک درخواست ساده روی HTTP قابل دانلود است و سرور حتی به درخواست دانلود بخشی هم جواب می دهد. داخل هر آرشیو کل پایگاه داده است: ردیف کاربران، درهم رمزها، کلیدهای سرویس ها و محتوای فایل تنظیمات.

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

راه حل امروز این سایت این است که درخواست چنین فایلی به PHP سپرده می شود تا مجوز را بررسی کند؛ مدیر وارد شده فایل را می گیرد و بقیه ۴۰۴. همین امروز دوباره آزمودیمش: درخواست مهمان به یکی از آن آرشیوها، حتی با هدر درخواست بخشی، ۴۰۴ گرفت.

سه قاعده ای که از این ماجرا باقی می ماند: بکاپ نباید روی همان ماشین بماند، چون بکاپی که کنار سایت است از اشتباه جان سالم به در می برد و از خرابی ماشین نه. دسترسی به بکاپ باید همان قدر محدود باشد که دسترسی به خود پایگاه داده. و بازگردانی را سالی یک بار روی یک پوشه موقت تمرین کنید؛ روش کارش در مسیر مبانی کامپیوتر جداگانه توضیح داده شده.

چه چیزهایی ارزش وقت گذاشتن ندارند

حالا موضع صریح، چون بخش زیادی از توصیه های امنیت وردپرس در فارسی کارهایی است که حس امنیت می دهند و امنیت نمی دهند.

پنهان کاری به تنهایی دفاع نیست. عوض کردن آدرس صفحه ورود، پنهان کردن شماره نسخه وردپرس و عوض کردن پیشوند جدول ها هیچ آسیب پذیری ای را نمی بندند؛ فقط پیدا کردن سایت را برای اسکنر خودکار کمی کندتر می کنند. کسی که هدفش شما باشد، ظرف چند دقیقه هر سه را پیدا می کند.

و حالا نیمه صادقانه اش، چون این سایت خودش هر سه کار را کرده. آدرس ورود اینجا عوض شده و آدرس فایل های افزونه ها هم بازنویسی شده. چیزی که این کار می خرد کاهش نویز است نه امنیت، و لاگ خودمان هر دو نیمه را نشان می دهد: در سه روز، ۱۲۷ درخواست سراغ آدرس پیش فرض ورود وردپرس رفتند و هیچ کدام به فرم ورودی نرسیدند، چون آن آدرس برای مهمان به یک صفحه دیگر تغییر مسیر می دهد. آن ۱۲۷ درخواست حذف نشدند؛ فقط دیگر روی چیزی نمی نشینند. اگر همین سایت به روز نبود، آن آدرس عوض شده یک روز هم دوام نمی آورد.

سه چیز دیگر که معمولا توصیه می شوند و ما توصیه نمی کنیم. عوض کردن پیشوند جدول های پایگاه داده روی یک سایت زنده، ریسکش از فایده اش بیشتر است؛ کارش نصف نصف انجام می شود و افزونه هایی که پیشوند را جایی ذخیره کرده اند می شکنند. خاموش کردن کامل REST API، ویرایشگر وردپرس را می شکند و مشکلی را حل نمی کند که با محدود کردن دسترسی حل نشود. و افزونه امنیتی ای که کارش فقط نمایش یک فهرست بلند از قوانین فایروال است، اگر آن فهرست را نمی خوانید هیچ چیزی به شما اضافه نکرده.

معیار ساده ای که می شود روی هر توصیه امنیتی گذاشت این است: این کار جلوی کدام حمله مشخص را می گیرد، و اگر کسی از قبل داخل باشد چه فرقی می کند. توصیه هایی که جواب روشنی به این دو سوال ندارند، معمولا حس امنیت اند.