راه‌اندازی VPS امن برای میزبانی وردپرس: راهنمای گام‌به‌گام سختی‌سازی سرور
چطور یک VPS خام را به سروری امن برای میزبانی وردپرس تبدیل کنیم؟ از سخت‌سازی SSH و پیکربندی فایروال تا Fail2ban، گواهی SSL، پشتیبان‌گیری و تنظیمات امنیتی وردپرس، بر پایه تجربه استقرار دهها سایت روی VPS.
راه‌اندازی VPS امن برای میزبانی وردپرس، تفاوت میان یک سرور آماده بهره‌برداری و یک سرور باز برای نفوذ است، و این تفاوت معمولاً در همان هفته اول بعد از راه‌اندازی روشن می‌شود. تجربه‌ای که در چند پروژه مهاجرت از هاست اشتراکی به VPS داشتم نشان داد که بیشتر شکست‌های امنیتی در VPS تازه، ریشه در پیکربندی پیش‌فرض ناامن دارد، نه در پیچیدگی حملات. این مقاله همان مسیری است که روی VPSهای شخصی و پروژه‌های مشتریان اجرا کرده‌ام.
چرا VPS برای میزبانی وردپرس انتخابی جدی است؟
Virtual Private Server یا همان VPS یک سرور مجازی است که منابع اختصاصی در اختیار شما قرار می‌دهد و برخلاف هاست اشتراکی، همسایه‌های شما تأثیر مستقیمی روی عملکرد سایت‌تان ندارند. سه دلیل اصلی که یک کسب‌وکار وردپرسی را به سمت VPS می‌برد: کنترل کامل روی پیکربندی، انعطاف در منابع و استقلال از محدودیت‌های هاست اشتراکی. اما این آزادی هزینه‌ای دارد که کمتر به آن پرداخته می‌شود: مسئولیت امنیت و نگهداری سرور به‌طور کامل به عهده شماست. تفاوت‌های این دو را در VPS چیست و چه تفاوتی با هاست اشتراکی دارد به‌تفصیل نوشته‌ام.
نکته‌ای که در پروژه‌های مهاجرت زیاد دیده‌ام این است که تیم‌ها VPS را انتخاب می‌کنند چون می‌خواهند از قید و بند هاست اشتراکی رها شوند اما همان‌جا می‌مانند چون امنیت را جدی نمی‌گیرند. یک VPS خام، حتی با منابع قوی، اگر بدون سخت‌سازی رها شود، می‌تواند در هفته اول هدف سیل حملات خودکار قرار بگیرد. اگر با مفاهیم پایه سرور آشنا نیستید، پیشنهاد می‌کنم ابتدا سرور چیست و چگونه کار می‌کند را بخوانید.
VPS یک ابزار قدرتمند است، اما قدرت بدون انضباط امنیتی، در نخستین حمله خودکار به بات‌نت تبدیل می‌شود.
آماده‌سازی پیش از اتصال: حساب، کلید و نقطه بازگشت
پیش از آنکه به SSH وصل شوید، سه تصمیم را باید گرفته باشید: انتخاب توزیع لینوکس، ساخت کلید SSH و تعریف روش بازگشت در صورت قفل شدن از سرور. این سه گام ساده، جلوی بیشتر دردسرهای روز اول را می‌گیرند.
انتخاب توزیع، تصمیم بلندمدتی است. Ubuntu Server LTS و Debian دو انتخاب رایج برای میزبانی وردپرس هستند و پشتیبانی طولانی‌مدت آن‌ها، خیال شما را از به‌روزرسانی‌های امنیتی راحت می‌کند. AlmaLinux و Rocky Linux برای کسانی که با اکوسیستم RHEL آشنایی دارند، گزینه‌های جانشین CentOS هستند. برای تیم‌های تازه‌کار، Ubuntu LTS نقطه شروع بسیار خوبی است.
ساخت کلید SSH اولین اقدام امنیتی است. کلید عمومی روی سرور و کلید خصوصی روی کامپیوتر شما می‌نشیند. روی لینوکس یا مک با دستور زیر می‌توانید کلید بسازید:
ssh-keygen -t ed25519 -C "your_email@example.com"الگوریتم Ed25519 امروز انتخاب پیش‌فرض است؛ سریع‌تر از RSA و با امنیت برابر. کلید خصوصی را در مسیر پیش‌فرض نگه دارید و کلید عمومی را با ابزار پنل هاست یا مستقیماً در فایل authorized_keys سرور قرار دهید. پیش از قطع اتصال فعلی، حتماً یک ترمینال جدید باز کنید و با کلید وارد سرور شوید تا مطمئن شوید دسترسی از دست نمی‌رود.
نقطه بازگشت یعنی قبل از هر تغییر مهم، از سرور snapshot بگیرید یا اطمینان حاصل کنید که دسترسی ترمینال اضطراری دارید. اکثر ارائه‌دهندگان VPS یک کنسول وب ارائه می‌دهند که حتی اگر SSH قطع شود، دسترسی فیزیکی شبیه‌سازی‌شده فراهم می‌کند. این کنسول را قبل از شروع سخت‌سازی تست کنید.
سخت‌سازی SSH: اولین لایه دفاعی
SSH پیش‌فرض روی پورت 22 گوش می‌دهد و ورود با رمز عبور را مجاز می‌کند؛ یعنی مهاجم‌های خودکار فقط باید یک رمز را حدس بزنند. سخت‌سازی SSH سریع‌ترین و پرارزش‌ترین اقدامی است که در روز اول انجام می‌دهید.
سه تغییر کلیدی در فایل /etc/ssh/sshd_config داریم. اول، غیرفعال کردن ورود با رمز عبور. دوم، غیرفعال کردن ورود مستقیم root. سوم، تغییر پورت پیش‌فرض. این سه تغییر، بیشتر حملات خودکار را بدون نیاز به هیچ ابزار اضافی دور می‌کنند.
# در /etc/ssh/sshd_config
Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers yourusername
پس از اعمال تغییرات، قبل از راه‌اندازی مجدد SSH، حتماً در یک ترمینال دیگر ورود با کلید و پورت جدید را تست کنید. اگر بدون تست، سرویس را ری‌استارت کنید و اشتباهی رخ داده باشد، دسترسی SSH از دست می‌رود و باید از کنسول پنل هاست وارد شوید. این اشتباه را در یک پروژه دیده‌ام و بازگشتش دو ساعت وقت برد.
در کنار این سه تغییر، توصیه می‌کنم احراز هویت دوعاملی SSH را هم فعال کنید. یکی از راه‌های ساده، استفاده از ماژول Google Authenticator برای SSH است. با این کار، حتی اگر کلید خصوصی به دست مهاجم بیفتد، بدون کد یک‌بارمصرف نمی‌تواند وارد شود. اصول کلی امنیتی در راهنمای افزایش امنیت سرور به‌تفصیل آمده است.
فایروال و قواعد پورت‌ها
پس از سخت‌سازی SSH، نوبت به فایروال می‌رسد. اصل کار ساده است: هر پورتی که استفاده نمی‌شود، بسته باشد. دو ابزار اصلی فایروال در لینوکس، UFW و firewalld هستند. Ubuntu به‌طور پیش‌فرض UFW دارد و برای تیم‌های تازه‌کار ساده‌تر است.
پیکربندی استاندارد UFW برای یک VPS وردپرسی به این ترتیب است: اجازه SSH روی پورت جدید، اجازه HTTP و HTTPS، و بستن بقیه پورت‌ها. دستورات زیر این پیکربندی را اعمال می‌کنند:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verboseبعد از فعال‌سازی، بلافاصله در یک ترمینال دیگر تست کنید که ورود SSH هنوز کار می‌کند. اشتباه رایج در این مرحله، فعال‌سازی UFW قبل از باز کردن پورت SSH جدید است که منجر به قطع دسترسی می‌شود. اگر پورت پیش‌فرض SSH را عوض نکرده‌اید، حتماً پورت 22 را باز نگه دارید یا قبل از تغییر، پورت جدید را مجاز کنید.
اگر پنل هاست شما فایروال در سطح شبکه دارد، باید قواعد را در هر دو سطح هماهنگ نگه دارید. گاهی پنل هاست قواعد خود را دارد و فایروال داخلی سرور قواعد مستقل. یک روش ساده: یک پورت غیرضروری باز بگذارید و از دو جا (اینترنت و داخل سرور) تست کنید که واقعاً بسته است. تجربه‌های مشابه در فایروال نرم‌افزاری در سرور آمده است.
در فایروال، دستور «همه‌چیز را ببند، بعد استثنا بده» همیشه بهتر از دستور «همه‌چیز را باز بگذار» عمل می‌کند.
Fail2ban و مقابله با حملات خودکار
SSH با کلید و پورت غیراستاندارد، بیشتر مهاجم‌ها را دور می‌کند، اما نه همه. بخشی از حملات با اسکن پورت‌ها پورت جدید را پیدا می‌کند و ورود را با نام‌های کاربری معروف امتحان می‌کند. Fail2ban لایه‌ای است که این حملات را در سطح لاگ شناسایی و IP مهاجم را موقتاً مسدود می‌کند.
نصب Fail2ban در Ubuntu ساده است و پیکربندی پیش‌فرض آن، SSH را پوشش می‌دهد. سه Jail اصلی که در محیط تولید فعال می‌کنم: sshd برای SSH، wordpress-hard برای حمله به wp-login، و recidive برای IPهایی که بارها بلاک شده‌اند.
# /etc/fail2ban/jail.local
[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
[sshd]
enabled = true
port = 2222
[recidive]
enabled = true
bantime = 1w
findtime = 1d
maxretry = 3
برای وردپرس، Jail سفارشی با پایش لاگ وب‌سرور توصیه می‌شود. حمله به wp-login.php و xmlrpc.php از الگوهای رایج است. اگر از وب‌سرور Nginx استفاده می‌کنید، مسیر لاگ /var/log/nginx/access.log است و می‌توانید فیلتر سفارشی با الگوهای خاص وردپرس بسازید.
نکته مهم در پیکربندی Fail2ban، پرهیز از سخت‌گیری بیش از حد است. اگر maxretry را روی 2 بگذارید، حتی خودتان ممکن است هنگام تایپ اشتباه رمز، از سرور بلاک شوید. برای محیط تولید، ترکیب bantime یک ساعته با findtime ده دقیقه‌ای و maxretry پنج، تعادل خوبی است. اگر با حملات سنگین‌تر روبه‌رو هستید، می‌توانید از recidive استفاده کنید که IPهای تکرارکننده را برای هفته‌ها مسدود می‌کند.
انتخاب و پیکربندی وب‌سرور برای وردپرس
سه وب‌سرور اصلی برای وردپرس وجود دارد: Nginx، Apache و LiteSpeed. انتخاب درست، تفاوت چشمگیری در کارایی و امنیت ایجاد می‌کند. Nginx به‌طور سنتی انتخاب اول برای سایت‌های پرترافیک است چون در تحویل فایل‌های استاتیک و مدیریت همزمانی درخواست‌ها عالی عمل می‌کند. Apache به‌دلیل پشتیبانی گسترده از فایل htaccess و سازگاری با تمام افزونه‌های وردپرس، انتخاب بسیاری از پروژه‌های تازه است. LiteSpeed ترکیب کارایی Nginx با سازگاری Apache را فراهم می‌کند اما نسخه رایگان آن محدودیت دارد.
برای اکثر سایت‌های وردپرسی روی VPS، ترکیب Nginx + PHP-FPM انتخاب من است. برای پروژه‌های تازه، Apache با mod_php یا PHP-FPM هم منطقی است و در برخی افزونه‌ها سازگاری بیشتری دارد. تفاوت‌ها در جزئیات کارایی و مدیریت است، نه در سطح امنیت پایه.
در سطح پیکربندی امنیتی، سه تنظیم کلیدی در وب‌سرور وجود دارد که همیشه اعمال می‌کنم. اول، غیرفعال کردن نمایش نسخه سرور در پاسخ‌ها. دوم، محدودسازی اندازه بدنه درخواست‌ها برای جلوگیری از حملات مبتنی بر فایل‌های بزرگ. سوم، محدودسازی نرخ درخواست‌ها (Rate Limiting) برای جلوگیری از حملات Brute Force در سطح وب. برای Nginx، این سه تنظیم به‌ترتیب با server_tokens off، client_max_body_size و limit_req قابل اعمال است.
در سطح PHP، چند تنظیم امنیتی را در php.ini غیرفعال نگه دارید: allow_url_fopen تنها در صورت نیاز فعال باشد، display_errors در محیط تولید غیرفعال باشد، و expose_php غیرفعال باشد. مسیر log خطاها باید به یک فایل خارج از ریشه سایت اشاره کند. اگر با وردپرس و سرور اختصاصی کار می‌کنید، شرایط سرور وردپرس در الزامات سرور وردپرس آمده است.
پایگاه‌داده: MySQL یا MariaDB با تنظیمات امن
پایگاه‌داده وردپرس، قلبی است که اگر ناامن بماند، تمام سخت‌سازی‌های لایه‌های دیگر را بی‌اثر می‌کند. سه اقدام اصلی در این لایه: تنظیم رمز عبور قوی، محدودسازی دسترسی کاربر پایگاه‌داده و تنظیم Bind Address.
اول، کاربر پایگاه‌داده باید فقط از localhost قابل دسترسی باشد. این تنظیم به‌صورت پیش‌فرض در MySQL و MariaDB وجود دارد اما برخی پیکربندی‌ها آن را به 0.0.0.0 تغییر می‌دهند که خطر جدی دارد. مسیر Bind Address در فایل mysqld.cnf یا mariadb.cnf قابل بررسی است.
دوم، دسترسی کاربر وردپرس باید محدود به پایگاه‌داده خودش باشد و نه همه پایگاه‌داده‌های سرور. اصل حداقل دسترسی در پایگاه‌داده به این معنی است که کاربر وردپرس نباید اجازه دسترسی به پایگاه‌داده‌های سیستمی یا سایر پروژه‌ها را داشته باشد. دستور زیر این کار را انجام می‌دهد:
CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'strong_password';
GRANT ALL PRIVILEGES ON `wp_database`.* TO 'wpuser'@'localhost';
FLUSH PRIVILEGES;سوم، دسترسی به phpMyAdmin یا هر ابزار مدیریت وب‌پایه پایگاه‌داده باید محدود به IPهای مشخص باشد یا به‌کلی غیرفعال شود. در محیط تولید، توصیه می‌کنم phpMyAdmin را نصب نکنید و مدیریت پایگاه‌داده را از طریق SSH انجام دهید. اگر نیاز به ابزار گرافیکی دارید، از ابزارهای دسکتاپ مانند DBeaver یا TablePlus با SSH Tunnel استفاده کنید. اصول امنیتی پایگاه‌داده در امن‌سازی دیتابیس وردپرس آمده است.
گواهی SSL و HTTPS اجباری
SSL دیگر یک ویژگی لوکس نیست؛ یک الزام پایه است که هم امنیت داده کاربر را تضمین می‌کند و هم در رتبه‌بندی گوگل اثر دارد. برای سایت‌های وردپرسی روی VPS، ابزار Let's Encrypt با Certbot ساده‌ترین مسیر برای گواهی رایگان و خودکار است.
فرآیند نصب Certbot بسته به وب‌سرور متفاوت است. برای Nginx، پلاگین nginx certbot گزینه طبیعی است. برای Apache، پلاگین apache. یک دستور ساده گواهی را نصب می‌کند و تمدید خودکار را در cron یا systemd timer تنظیم می‌کند. سه نکته که در پروژه‌ها به آن برخورده‌ام: اول، قبل از نصب گواهی، مطمئن شوید دامنه به IP سرور اشاره می‌کند و DNS Propagate شده است. دوم، پورت 80 باید باز باشد چون Let's Encrypt برای تأیید مالکیت دامنه از HTTP-01 Challenge استفاده می‌کند. سوم، تمدید خودکار را تست کنید که واقعاً کار می‌کند.
پس از نصب گواهی، باید HTTPS را اجباری کنید و تمام ترافیک HTTP را به HTTPS هدایت کنید. در Nginx، این کار با تنظیم server block برای پورت 80 که به https ریدایرکت می‌کند انجام می‌شود. در وردپرس، آدرس سایت را باید از http به https تغییر دهید؛ این کار در بخش تنظیمات عمومی وردپرس انجام می‌شود. اگر سایت شما در دیتابیس آدرس‌های http دارد، باید با کوئری SQL یا افزونه‌های جایگزینی، همه آدرس‌ها را به https تغییر دهید.
در سطح هدرهای امنیتی، افزودن HSTS (HTTP Strict Transport Security) را توصیه می‌کنم. این هدر به مرورگر می‌گوید که فقط از HTTPS استفاده کند و از حملات Downgrade به HTTP جلوگیری می‌کند. تنظیم دقیق HSTS شامل max-age مناسب و شاید preload است که باید با احتیاط انجام شود. اگر با مراحل SSL آشنایی ندارید، راهنمای نصب گواهی SSL گام‌به‌گام پیش رفته است.
در HTTPS، تفاوت میان «داریم گواهی» و «گواهی درست پیکربندی شده»، همان تفاوت میان امنیت نمادین و امنیت واقعی است.
سخت‌سازی وردپرس پس از نصب
پس از آماده‌سازی لایه‌های سرور، نوبت به سخت‌سازی خود وردپرس می‌رسد. اقدامات این لایه، سریع‌ترین بازده امنیتی را دارند چون بیشتر حملات به وردپرس، از نقاط شناخته‌شده استفاده می‌کنند.
اولین اقدام، حذف کاربر admin و انتخاب نام کاربری غیرقابل حدس برای مدیر است. اگر سایت شما قبلاً admin دارد، باید حذف و کاربر جدید با نقش Administrator ساخته شود. دومین اقدام، تنظیم رمز عبور قوی برای همه کاربران با نقش مدیریتی. سومین اقدام، فعال‌سازی احراز هویت دوعاملی برای همه کاربران مدیر. افزونه‌هایی مانند Wordfence و iThemes Security این قابلیت‌ها را در یک بسته ارائه می‌دهند. مقایسه آن‌ها را در بهترین افزونه‌های امنیتی وردپرس نوشته‌ام.
اقدام چهارم، محدودسازی دسترسی به فایل‌های حساس وردپرس است. فایل wp-config.php نباید برای همه خواندنی باشد و باید مجوز 600 یا 640 داشته باشد. فایل .htaccess در Nginx کاربرد ندارد اما در Apache باید محدود به خواندن توسط سرور باشد. مجوز پوشه‌ها باید 755 و مجوز فایل‌ها 644 باشد؛ به‌جز فایل‌های حساس که مجوز سخت‌گیرانه‌تری دارند.
اقدام پنجم، غیرفعال کردن ویرایشگر فایل در پیشخوان وردپرس است. با افزودن یک خط به wp-config.php این قابلیت غیرفعال می‌شود:
define('DISALLOW_FILE_EDIT', true);اقدام ششم، غیرفعال کردن XML-RPC است اگر استفاده نمی‌شود. XML-RPC کانال حمله شناخته‌شده‌ای است که در حملات Brute Force و DDoS Amplification استفاده می‌شود. اگر از اپلیکیشن موبایل وردپرس یا ابزارهای جانبی که به XML-RPC نیاز دارند استفاده نمی‌کنید، آن را غیرفعال کنید. اگر با مدیریت وردپرس آشنایی ندارید، وردپرس چیست و چگونه شروع به کار با آن کنیم نقطه شروع خوبی است.
اقدام هفتم، جابجایی و محدودسازی آدرس ورود است. تغییر آدرس wp-login.php به یک مسیر غیرمعمول، بیشتر حملات خودکار را بی‌اثر می‌کند. افزونه‌های امنیتی این قابلیت را دارند و در کنار Fail2ban، لایه دفاعی محکمی می‌سازند. هرچند این تغییر به‌تنهایی امنیت را تضمین نمی‌کند، اما آستانه حمله را بالا می‌برد.
پشتیبان‌گیری امن و بازیابی آزمایشی
پشتیبان‌گیری در VPS، متفاوت از هاست اشتراکی است. در هاست اشتراکی معمولاً شرکت هاست پشتیبان‌گیری روزانه انجام می‌دهد؛ در VPS، این مسئولیت به‌طور کامل به عهده شماست. تجربه‌ای که در چند پروژه داشته‌ام: تیم‌هایی که پشتیبان‌گیری جدی نمی‌گیرند، در نخستین حادثه جدی متوجه می‌شوند که دیگر سایت قابل بازگشت نیست.
سه لایه پشتیبان‌گیری توصیه می‌کنم. لایه اول، پشتیبان‌گیری روزانه از فایل‌های سایت و پایگاه‌داده روی خود VPS. لایه دوم، انتقال خودکار این پشتیبان‌ها به فضای ذخیره‌سازی خارج از سرور مانند S3 یا Object Storage. لایه سوم، پشتیبان‌گیری هفتگی از کل سرور با ابزار Snapshot در سطح ارائه‌دهنده.
ابزارهایی مانند Duplicator، UpdraftPlus و BackupBuddy در سطح وردپرس کار می‌کنند و انتقال سایت را ساده می‌کنند. در سطح سرور، ابزارهایی مانند Restic، Borg و rclone برای پشتیبان‌گیری فایل‌ها و پایگاه‌داده وجود دارند. انتخاب ترکیب مناسب بستگی به سطح تخصص تیم دارد. مقایسه افزونه‌ها در بهترین افزونه‌های پشتیبان‌گیری وردپرس آمده است.
نکته حیاتی که در پروژه‌ها تأکید می‌کنم: پشتیبان‌گیری بدون تست بازیابی، ارزش ندارد. حداقل هر سه ماه یک بار باید یک بازیابی آزمایشی روی محیط staging انجام دهید تا مطمئن شوید پشتیبان‌ها سالم و قابل بازیابی هستند. پشتیبانی که هرگز تست نشده، در زمان حادثه شانس کشف خطا را به بالاترین حد می‌رساند. تفاوت پشتیبان‌گیری جزئی و کامل در تفاوت بکاپ کامل و جزئی آمده است.
پایش و لاگ‌گیری روی VPS
پایش، لایه‌ای است که بسیاری از تیم‌ها تا نخستین حادثه جدی به آن بی‌توجهی می‌کنند. بدون پایش، آسیب‌پذیری یا نفوذ می‌تواند هفته‌ها بی‌سروصدا پیش برود. روی VPS، دو نوع پایش داریم: پایش منابع سرور و پایش امنیتی.
در پایش منابع، ابزارهایی مانند Netdata، Prometheus با Node Exporter یا سرویس‌های پایش خارجی مانند UptimeRobot گزینه‌های رایج هستند. Netdata نصب سریع و رابط کاربری زیبایی دارد و برای تیم‌های تازه‌کار ایده‌آل است. سرویس‌های خارجی امکان پایش از دید بیرونی را فراهم می‌کنند که به تشخیص مشکلات شبکه کمک می‌کند.
در پایش امنیتی، سه ابزار کلیدی وجود دارد. اول، پایش لاگ‌های SSH برای تشخیص تلاش‌های ورود ناموفق. دوم، پایش لاگ‌های وب‌سرور برای تشخیص درخواست‌های مشکوک. سوم، ابزار بررسی یکپارچگی فایل‌ها مانند AIDE یا Tripwire که تغییرات غیرمجاز در فایل‌های سیستمی را شناسایی می‌کنند. این سه ابزار با هم، دید پوششی خوبی از وضعیت امنیتی سرور می‌دهند.
در سطح وردپرس، افزونه‌های امنیتی معمولاً پایش لاگ و هشدار درون‌سایتی دارند. اما این پایش باید در سطح سرور هم پشتیبانی شود؛ به‌ویژه برای حمله‌های سطح پایین که ممکن است از دید وردپرس پنهان بمانند. اصول مشاهده‌پذیری در مقایسه ابزارهای مانیتورینگ سرور به‌تفصیل آمده است.
در سطح هشدار، نکته‌ای که در پروژه‌های واقعی بارها به آن برخورده‌ام: هشدار بدون runbook، هشدار نیست. اگر نگهبان شب با هشدار بیدار شود و نداند چه باید بکند، هشدار ارزش عملی ندارد. برای هر هشدار، یک رویه پاسخ کوتاه بنویسید: چه اقدامی اول، چه اقدامی در صورت تکرار، و چه زمانی باید escalation انجام شود.
اشتباهات رایجی که VPS را ناامن می‌کند
پس از سال‌ها کار با VPS و پاسخ به حادثه‌های امنیتی در پروژه‌ها، الگوهای تکراری از شکست دیده‌ام که بیشتر آن‌ها پیشگیری‌پذیر بودند. شناخت این اشتباهات می‌تواند از دردسرهای هفته‌های آینده جلوگیری کند.
اشتباه اول، نصب وردپرس پیش از سخت‌سازی سرور. تیم‌هایی که بلافاصله بعد از خرید VPS وردپرس نصب می‌کنند، در معرض حمله‌های خودکار در همان ساعت‌های نخست قرار می‌گیرند. ترتیب درست این است: سخت‌سازی سرور، سپس نصب وردپرس.
اشتباه دوم، نصب افزونه‌های متعدد بدون بررسی امنیتی. هر افزونه یک نقطه ورود بالقوه است و افزونه‌های قدیمی یا نال شده، از رایج‌ترین کانال‌های نفوذ هستند. فقط از مخزن رسمی وردپرس یا منبع معتبر افزونه نصب کنید. اصول انتخاب در دانلود افزونه مطمئن وردپرس آمده است.
اشتباه سوم، نادیده گرفتن به‌روزرسانی‌های امنیتی. چه در سطح سرور (کرنل، پکیج‌ها) و چه در سطح وردپرس (هسته، افزونه‌ها، قالب)، تأخیر در به‌روزرسانی امنیتی، درهای باز برای نفوذ است. توصیه می‌کنم به‌روزرسانی‌های امنیتی در سطح سرور را به‌صورت خودکار فعال کنید و به‌روزرسانی‌های وردپرس را روی محیط staging تست و سپس اعمال کنید.
اشتباه چهارم، استفاده از رمز عبور ضعیف یا تکرارشده. حتی اگر SSH با کلید باشد، پایگاه‌داده وردپرس و پیشخوان وردپرس همچنان با رمز محافظت می‌شوند. رمزهای قوی و منحصربه‌فرد برای هر سرویس، پایه هر استراتژی امنیتی است. یک مدیر رمز عبور مانند Bitwarden یا 1Password به تیم کمک می‌کند.
اشتباه پنجم، نداشتن پشتیبان‌گیری خارج از سرور. اگر پشتیبان‌ها روی همان سرور باشند که سایت میزبانی می‌شود، در زمان حادثه جدی (مانند هک یا حذف سرور)، همه پشتیبان‌ها هم از دست می‌روند. قاعده ساده: حداقل یک نسخه پشتیبان باید خارج از سرور باشد.
اشتباه ششم، نادیده گرفتن امنیت پایگاه‌داده. تیم‌هایی که به امنیت SSH و وب‌سرور توجه می‌کنند اما پایگاه‌داده را با رمز ضعیف و دسترسی گسترده رها می‌کنند، از یک کانال حمله مهم غافل می‌شوند. امنیت پایگاه‌داده باید در همان سطح امنیت SSH جدی گرفته شود.
پرسش‌های پرتکرار درباره راه‌اندازی VPS امن
پرسش اول: نصب وردپرس روی VPS خام چقدر طول می‌کشد؟ برای یک تیم با تجربه لینوکس، ۲ تا ۴ ساعت شامل سخت‌سازی و نصب. برای تیم تازه‌کار، یک تا دو روز کار در ساعات مختلف. اگر از پنل‌های مدیریتی مانند cPanel یا CyberPanel استفاده کنید، این زمان به چند ساعت کاهش می‌یابد اما کنترل کمتری روی سطح پایین دارید.
پرسش دوم: UFW کافی است یا firewalld هم لازم است؟ یکی از این دو کافی است. UFW برای Ubuntu و Debian و firewalld برای RHEL و AlmaLinux و Rocky انتخاب استاندارد هستند. استفاده همزمان از هر دو، مشکل سازگاری ایجاد می‌کند و توصیه نمی‌شود.
پرسش سوم: چطور از قفل شدن از SSH پیشگیری کنم؟ قبل از هر تغییر در پیکربندی SSH یا فایروال، یک ترمینال دیگر با کاربر دیگر باز نگه دارید. تغییرات را اعمال کنید و ورود از ترمینال دوم را تست کنید. اگر ورود موفق بود، تغییرات را ذخیره کنید؛ اگر نه، تغییرات را برگردانید. اگر دسترسی کاملاً از دست رفت، از کنسول وب ارائه‌دهنده VPS استفاده کنید.
پرسش چهارم: Fail2ban با کلید SSH هم لازم است؟ بله، هرچند SSH با کلید سطح حمله را به‌طور محسوس کاهش می‌دهد. Fail2ban در سطح وردپرس و وب‌سرور هم مفید است. توصیه می‌کنم در همه سناریوها فعال باشد. حتی اگر حمله SSH شما را نگیرد، حمله به فرم ورود وردپرس رخ می‌دهد و Fail2ban بهترین ابزار برای محدودسازی آن است.
پرسش پنجم: Cloudflare در کنار VPS ضروری است؟ ضروری نیست اما توصیه می‌شود. Cloudflare لایه CDN، WAF و محافظت DDoS در اختیار شما می‌گذارد که روی VPS به‌تنهایی سخت به دست می‌آید. اگر سایت شما ترافیک بالا دارد یا هدف حملات DDoS است، ترکیب Cloudflare و VPS انتخاب قوی است. جزئیات بیشتر در راه‌اندازی Cloudflare برای وردپرس آمده است.
پرسش ششم: هر چند وقت یک بار باید سرور را به‌روزرسانی کنم؟ به‌روزرسانی‌های امنیتی کرنل و پکیج‌های سیستمی را ماهانه اعمال کنید. به‌روزرسانی هسته وردپرس و افزونه‌ها را هر هفته بررسی کنید. برای پروژه‌های حساس، فعال‌سازی به‌روزرسانی خودکار امنیتی در سطح وردپرس توصیه می‌شود. این کار در تنظیمات پیشخوان وردپرس با یک تیک انجام می‌شود.
جمع‌بندی عملی: سفری از سرور خام تا سایت امن
راه‌اندازی VPS امن برای میزبانی وردپرس، مجموعه‌ای از تصمیم‌های کوچک است که با هم یک لایه دفاعی محکم می‌سازند. این مسیر از سخت‌سازی SSH و فایروال شروع می‌شود، با Fail2ban و وب‌سرور پیکربندی‌شده ادامه می‌یابد، در سطح وردپرس با سخت‌سازی و احراز هویت دوعاملی تقویت می‌شود و با پشتیبان‌گیری خارج از سرور و پایش مستمر تثبیت می‌گردد.
نکته‌ای که در پایان باید تأکید کنم این است که امنیت یک وضعیت نیست؛ یک فرآیند است. سایت شما در روز اول راه‌اندازی امن است، اما امنیتش به‌صورت خودکار در طول زمان حفظ نمی‌شود. به‌روزرسانی‌های دوره‌ای، بازبینی مستمر لاگ‌ها و تست بازیابی پشتیبان‌ها، بخشی از کار روزمره نگهداری یک VPS است.
اگر روی VPS خود سایتی دارید، توصیه می‌کنم یک بازبینی امنیتی از همین امروز شروع کنید. یک چک‌لیست ساده بنویسید شامل SSH، فایروال، Fail2ban، SSL، سخت‌سازی وردپرس و پشتیبان‌گیری. هر بخش را یکی‌یکی بررسی کنید و یادداشت کنید کدام بخش‌ها انجام شده و کدام‌ها نیاز به توجه دارند.
اگر تجربه‌ای از راه‌اندازی VPS امن یا مواجهه با حمله امنیتی در سایت وردپرسی داشته‌اید، برای من جالب است بدانم کدام لایه از دفاع به موقع جلوی حادثه را گرفت و کدام لایه نیاز به تقویت داشت. تجربه‌تان را در دیدگاه‌ها بنویسید؛ به‌خصوص اگر رویکردی برای کاهش زمان راه‌اندازی اولیه پیدا کرده‌اید که در این مقاله نیامده است. 🔐
نویسنده در وردپرس کار.