شروع کار سرورنت: ۲۴ ساعت اول پس از خرید سرویس

ترتیب درست کارهای روز اول: تغییر رمز پیش‌فرض، تنظیم DNS، نصب گواهی SSL و گرفتن اولین بکاپ. چک‌لیست عملی برای مدیر سایتی که تازه سرویس گرفته است.

۷ دقیقه به‌روزرسانی ۸ شهریور ۱۴۰۵

سرویس را خریده‌اید؛ حالا چه؟

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

ترتیب درست این است: امنیت، بعد DNS، بعد گواهی، بعد بکاپ. به همین ترتیب جلو می‌رویم.

قدم اول: تغییر رمز پیش‌فرض، قبل از هر چیز

سرویس‌های هاستینگ معمولاً با یک رمز موقت یا رمزی که در پنل نمایش داده می‌شود تحویل داده می‌شوند. این رمز را هر کسی که به پنل یا ایمیل شما دسترسی داشته باشد می‌تواند ببیند. اولین کاری که بعد از لاگین انجام می‌دهید، تغییر این رمز است. نه بعد از ناهار، نه بعد از تنظیم DNS. همین حالا.

در هاست لینوکس، این کار از طریق بخش مدیریت حساب در پنل انجام می‌شود. رمز جدید باید حداقل ۱۲ کاراکتر داشته باشد و ترکیبی از حروف بزرگ، کوچک، عدد و نماد باشد. اگر از SSH استفاده می‌کنید، بعد از تغییر رمز، ورود با کلید عمومی را فعال کنید:

ssh-keygen -t ed25519 -a 100
ssh-copy-id user@your-server-ip

کلید ed25519 به جای RSA-4096 انتخاب بهتری است؛ کوتاه‌تر است، سریع‌تر است و همان امنیت را می‌دهد. بعد از کپی شدن کلید، ورود با رمز را غیرفعال کنید:

sudo nano /etc/ssh/sshd_config
# PasswordAuthentication no
sudo systemctl restart sshd

این‌جا اشتباه می‌کنند: خیلی‌ها فقط رمز هاست را عوض می‌کنند و رمز پیش‌فرض دیتابیس یا FTP را دست می‌زنند. اگر سرویس شما phpMyAdmin یا FTP دارد، آن‌ها هم رمز پیش‌فرض دارند. همه را عوض کنید. یک رمز مشترک برای همه‌چیز نسازید؛ اگر یکی لو رفت، بقیه هم لو رفته‌اند.

قدم دوم: تنظیم DNS، با آگاهی از TTL

قبل از اینکه رکوردهای DNS را تغییر دهید، TTL (Time To Live) رکورد فعلی را چک کنید. اگر TTL روی ۸۶۴۰۰ ثانیه (۲۴ ساعت) باشد، بعد از تغییر، بعضی کاربران تا ۲۴ ساعت سایت قدیمی را می‌بینند. اگر از قبل برنامه‌ریزی کرده‌اید، ۲۴ تا ۴۸ ساعت قبل از انتقال، TTL را به ۳۰۰ ثانیه (۵ دقیقه) کاهش دهید. اگر همین الان در حال انتقال هستید، این کار را انجام دهید و صبر کنید.

در پنل مدیریت دامنه، رکوردهای A و AAAA را به IP سرور جدید指向 دهید. برای هاست لینوکس سرورنت، IP را از بخش «اطلاعات سرویس» در پنل کاربری پیدا می‌کنید. رکوردهای زیر را تنظیم کنید:

example.com. 300 IN A 185.10.xx.xx
www.example.com. 300 IN A 185.10.xx.xx
example.com. 300 IN AAAA 2a00:xxxx:xxxx::1

اگر ایمیل روی همین دامنه دارید، رکوردهای MX و SPF را هم منتقل کنید. فراموش کردن MX یعنی ایمیل‌های شما بعد از انتقال به سرور جدید، به صندوق ورودی نمی‌رسند و معمولاً هیچ خطایی هم نمی‌بینید. فقط ایمیل‌ها گم می‌شوند.

بعد از تغییر، منتظر نمانید و به صفحه خیره نشوید. از یک سرویس DNS checker استفاده کنید تا ببینید رکوردها از نقاط مختلف دنیا چطور propagate شده‌اند. معمولاً بین ۵ دقیقه تا ۲ ساعت طول می‌کشد.

قدم سوم: نصب گواهی SSL

بعد از اینکه DNS روی سرور جدید نشست، نوبت گواهی SSL است. اگر این کار را قبل از DNS انجام دهید، فرآیند صدور گواهی (مخصوصاً روش HTTP-01) شکست می‌خورد چون سرور Let's Encrypt نمی‌تواند به دامنه شما دسترسی پیدا کند.

برای هاست لینوکس، معمولاً گزینه «SSL/TLS» در پنل وجود دارد که به صورت خودکار گواهی Let's Encrypt را صادر و نصب می‌کند. اگر از سرور مجازی استفاده می‌کنید و خودتان وب‌سرور را مدیریت می‌کنید، با certbot این کار را انجام دهید:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

بعد از نصب، ریدایرکت HTTP به HTTPS را فعال کنید. در nginx، این کار در فایل کانفیگ سایت انجام می‌شود:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

یک نکته: گواهی Let's Encrypt هر ۹۰ روز منقضی می‌شود. تمدید خودکار را فعال کنید و مطمئن شوید که کرون‌جاب مربوطه کار می‌کند. بعد از نصب اولیه، دستور زیر را اجرا کنید تا تمدید خودکار را تست کنید:

sudo certbot renew --dry-run

اگر خروجی شامل Congratulations نبود، یعنی تمدید خودکار کار نمی‌کند و تا ۹۰ روز دیگر سایت شما خطای گواهی می‌دهد.

قدم چهارم: اولین بکاپ، قبل از اینکه چیزی را لمس کنید

بیشتر مردم بکاپ را آخر کار می‌گیرند. این اشتباه است. اولین بکاپ را قبل از نصب هر چیزی بگیرید. چرا؟ چون اگر بعد از نصب وردپرس یا ووکامرس خطایی رخ دهد، می‌خواهید به یک نقطه تمیز برگردید، نه به یک سیستم نیمه‌کاره.

در هاست لینوکس، معمولاً گزینه بکاپ‌گیری در پنل وجود دارد که از فایل‌ها و دیتابیس به صورت جداگانه بکاپ می‌گیرد. اگر از خط فرمان استفاده می‌کنید:

mysqldump -u username -p database_name > /backup/db_$(date +%Y%m%d).sql
tar -czf /backup/files_$(date +%Y%m%d).tar.gz /var/www/html

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

rsync -avz /backup/ user@backup-server:/backups/

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

قدم پنجم: چک‌لیست نهایی و مستندسازی

بعد از این چهار قدم، سایت شما از نظر فنی آماده است. اما یک قدم دیگر هست که大部分人 انجام نمی‌دهند: مستندسازی. اطلاعات دسترسی، IP سرور، مسیر فایل‌ها، نام دیتابیس، و تنظیمات DNS را در یک فایل امن یادداشت کنید. این کار را الان انجام دهید، نه وقتی که سه ماه دیگر فراموش کرده‌اید رمز دیتابیس چیست.

برای پیدا کردن اطلاعات دسترسی سرویس، راهنمای پیدا کردن اطلاعات دسترسی سرویس هاست و سرور را ببینید. اگر حساب کاربری‌تان را با احراز هویت دومرحله‌ای (2FA) فعال نکرده‌اید، همین الان این کار را انجام دهید. راهنمای امنیت حساب کاربری در سرویس‌های ابری و هاستینگ دقیقاً همین موضوع را پوشش می‌دهد.

اگر سایت را از یک هاست دیگر منتقل می‌کنید، چک‌لیست کامل انتقال به سرورنت بدون قطعی سرویس را بخوانید. این چک‌لیست شامل مواردی است که در این مقاله نیامده، مثل انتقال ایمیل‌ها و تنظیم cron jobها.

این‌جا اشتباه می‌کنند: ترتیب کارها

رایج‌ترین اشتباهی که در ۲۴ ساعت اول می‌بینم این است: کسی DNS را تغییر می‌دهد، SSL را نصب می‌کند، سایت را بالا می‌آورد و بعد تازه یادش می‌افتد که رمز پیش‌فرض را عوض نکرده. نتیجه؟ یک سایت در دسترس با رمز پیش‌فرض. ربات‌ها در کمتر از یک ساعت بعد از اینکه DNS propagate شود، شروع به اسکن کردن IP شما می‌کنند. اولین چیزی که امتحان می‌کنند، ترکیب‌های پیش‌فرض مثل admin/admin و root/toor است.

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

انتخاب بین سرعت و امنیت

یک trade-off واقعی وجود دارد: اگر همه این مراحل را با دقت انجام دهید، ممکن است ۲ تا ۳ ساعت طول بکشد. اگر عجله دارید و سایت را همین الان می‌خواهید، وسوسه می‌شوید که DNS را اول تغییر دهید و بقیه را بعداً انجام دهید. این کار را نکنید. یک سایت که ۳ ساعت دیرتر بالا می‌آید، بهتر از سایتی است که در روز اول هک می‌شود.

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

پرسش‌های پرتکرار

چقدر طول می‌کشد تا DNS بعد از تغییر propagate شود؟

معمولاً بین ۵ دقیقه تا ۲ ساعت. اگر TTL قبلی را کاهش داده باشید، سریع‌تر است. اگر TTL روی ۲۴ ساعت باشد، بعضی کاربران تا ۲۴ ساعت سایت قدیمی را می‌بینند. برای چک کردن وضعیت، از سرویس‌های DNS checker استفاده کنید.

آیا می‌توانم SSL را قبل از تغییر DNS نصب کنم؟

خیر. روش HTTP-01 که Let's Encrypt استفاده می‌کند، نیاز دارد که دامنه به سرور شما اشاره کند. اگر DNS هنوز به سرور قبلی اشاره می‌کند، صدور گواهی شکست می‌خورد. اول DNS، بعد SSL.

بکاپ را کجا نگه دارم؟

روی همان سرور نه. یک کپی روی فضای ابری، یک سرور دیگر، یا حداقل یک دیسک جداگانه. اگر سرور از کار بیفتد، بکاپ روی همان سرور هم از بین می‌رود. و یادتان باشد: بکاپ را تست کنید، نه فقط بگیرید.

اگر رمز پیش‌فرض را عوض نکنم چه می‌شود؟

ربات‌ها در کمتر از یک ساعت بعد از propagate شدن DNS، IP شما را اسکن می‌کنند و ترکیب‌های پیش‌فرض را امتحان می‌کنند. اگر موفق شوند، فایل‌های مخرب در سایت شما قرار می‌دهند یا دیتابیس را تخریب می‌کنند. این اتفاق در روز اول یا دوم رخ می‌دهد، نه بعد از یک ماه.

آیا این مطلب برایتان مفید بود؟