کانفیگ اولیه سرور مجموعه‌ای از تصمیم‌های امنیتی و عملیاتی است، نه فهرستی از فرمان‌های کپی‌کردنی. سروری که فقط SSH آن روی پورت دیگری قرار گرفته اما backup قابل بازیابی، patch منظم، ساعت صحیح و alert ندارد برای production آماده نیست. ترتیب اجرا نیز مهم است: بستن دسترسی پیش از آزمون کلید و console می‌تواند خود مدیر را بیرون نگه دارد.
پاسخ سریع: از وضعیت فعلی inventory بگیرید، console اضطراری را تأیید کنید، سیستم را patch و حساب مدیریتی جدا با SSH key بسازید. firewall و SSH را مرحله‌ای سخت‌سازی کنید؛ سپس زمان، DNS، log، backup، مانیتورینگ و سیاست نگهداری را تنظیم و آزمون کنید. هر تغییر شبکه باید session دوم و rollback داشته باشد.
مرحله صفر: مالک و هدف سرور
نقش سرور، محیط production/staging، دامنه، داده حساس، RPO/RTO و فرد پاسخ‌گو را ثبت کنید. مشخص کنید چه سرویس‌هایی باید روی آن اجرا شوند و چه چیزهایی نباید نصب شوند. «سرور عمومی» که هم‌زمان وب، دیتابیس، ابزار آزمایشی و حساب‌های مشترک دارد سطح حمله و blast radius را بالا می‌برد.
Inventory خواندنی
cat /etc/os-release
uname -r
ip -br addr
ss -lntup
free -h
df -h
df -i
systemctl --failedاین فرمان‌ها وضعیت را تغییر نمی‌دهند. نسخه سیستم، interfaceها، listenerها، حافظه، دیسک، inode و سرویس failed را ثبت کنید. IP عمومی، hostname داخلی و نام کاربری را پیش از اشتراک‌گذاری ناشناس کنید. هر listener باید مالک و دلیل مشخص داشته باشد.
دسترسی اضطراری پیش از Hardening
console یا recovery mode ارائه‌دهنده را واقعاً باز کنید، نه اینکه فقط فرض کنید وجود دارد. credential و MFA حساب provider باید در محل امن و قابل دسترسی تیم مجاز باشد. اگر firewall یا SSH اشتباه شود، این مسیر تنها راه بازگشت است. snapshot می‌تواند کمک کند اما جای دسترسی console را نمی‌گیرد.
Patch و چرخه به‌روزرسانی
بسته‌ها را از repository معتبر دریافت کنید و updateهای امنیتی را اعمال کنید. تغییر kernel یا کتابخانه حیاتی ممکن است reboot یا restart بخواهد؛ maintenance window و بررسی سرویس پس از آن لازم است. automatic update بدون سیاست reboot و smoke test ممکن است سرویس را در زمان نامناسب تغییر دهد؛ خاموش کردن کامل update نیز مناسب نیست.
کاربر مدیریتی جدا
برای هر مدیر حساب جدا و sudo حداقلی داشته باشید. کلید عمومی روی سرور قرار می‌گیرد؛ private key باید روی دستگاه امن بماند و هرگز در repository یا پیام عمومی ارسال نشود. حساب فرد جدا امکان revoke و audit می‌دهد. shared root password هم مسئولیت را مبهم می‌کند و هم rotation را دشوار.
SSH با ترتیب ضد قفل‌شدن
- کلید را اضافه و permission آن را بررسی کنید.
- در session دوم login را آزمایش کنید.
- sudo و دسترسی ضروری را تست کنید.
- config را با ابزار همان daemon اعتبارسنجی کنید.
- محدودسازی root/password را مرحله‌ای اعمال کنید.
- session قبلی و console را تا تأیید نگه دارید.
تغییر پورت فقط نویز اسکن را کم می‌کند؛ جای key، allowlist، patch و rate control را نمی‌گیرد. الگوریتم‌ها و گزینه‌های SSH به نسخه توزیع وابسته‌اند؛ template قدیمی را کور جایگزین نکنید.
Firewall بر اساس جریان واقعی
ورودی را به سرویس‌های ضروری محدود کنید و قبل از فعال‌سازی rule مدیریت را تأیید کنید. HTTP/HTTPS عمومی است، اما دیتابیس، Redis و پنل داخلی معمولاً باید private باشند. outbound نیز برای update، DNS، NTP، ایمیل و APIها نیازمند نقشه است. rule بیش‌ازحد سخت بدون مستندات می‌تواند callback یا backup را قطع کند.
Cloud Firewall و Host Firewall
فایروال provider و سیستم‌عامل دو لایه جدا هستند. اختلاف آن‌ها عیب‌یابی را دشوار می‌کند؛ source of truth و change record داشته باشید. Docker یا ابزار orchestration نیز ممکن است ruleهای شبکه اضافه کند. فقط خروجی رابط firewall را نبینید؛ از بیرون و از شبکه داخلی مسیر واقعی را تست کنید.
زمان، NTP و Timezone
ساعت اشتباه TLS، token، cron، log و تطبیق incident را خراب می‌کند. وضعیت sync را با timedatectl status بررسی کنید. timezone برای نمایش انسانی است؛ clock صحیح و timestamp قابل تطبیق اصل مهم‌تر است. تغییر دستی ساعت برای عبور از خطای امضا، مشکل را پنهان و داده زمانی را آشفته می‌کند.
Hostname، DNS و Reverse DNS
hostname معنی‌دار اما بدون اطلاعات حساس انتخاب کنید. رکوردهای A و AAAA باید فقط به مسیرهای واقعاً فعال اشاره کنند. IPv6 ناقص برای بخشی از کاربران timeout می‌سازد. reverse DNS به‌خصوص برای ایمیل اهمیت دارد و معمولاً در پنل provider تنظیم می‌شود؛ آن را با DNS forward اشتباه نگیرید.
حداقل سرویس و Package Source
سرویس بلااستفاده را پس از inventory غیرفعال یا حذف کنید. repository شخص ثالث سطح اعتماد تازه‌ای وارد می‌کند و باید مالک، کلید امضا و چرخه update آن مشخص باشد. نصب پنل یا اسکریپت bootstrap ناشناخته می‌تواند firewall، وب‌سرور و SSH را هم‌زمان تغییر دهد؛ ابتدا محتوا و مسیر rollback را بررسی کنید.
اصل حداقل دسترسی برای Processها
برنامه، وب‌سرور و دیتابیس نباید بی‌دلیل با root اجرا شوند. مالکیت کد، فایل upload، log و secret را جدا کنید. مجوز 777 درمان permission نیست و امکان نوشتن ناخواسته می‌دهد. مسیرهای write لازم را دقیق مشخص و بقیه را read-only نگه دارید.
Secret Management
رمز دیتابیس، API key و private key را در repository، image عمومی، history shell یا log نگذارید. فایل secret باید مالک و permission محدود داشته باشد و rotation آن بدون downtime برنامه‌ریزی شود. مخفی کردن مقدار در UI، افشای قبلی را خنثی نمی‌کند؛ credential افشاشده باید rotate شود.
تنظیم Resource Limit
سرویس بدون limit می‌تواند تمام حافظه یا file descriptor را مصرف کند؛ limit بسیار پایین نیز خطای مبهم می‌سازد. مصرف واقعی، concurrency و failure behavior را بسنجید. برای PHP، دیتابیس، container و systemd بودجه منبع هماهنگ تعریف کنید تا مجموع سقف‌ها از ظرفیت فیزیکی عبور نکند.
Swap و OOM
وجود یا نبود swap تصمیم مطلق نیست. swap کوچک می‌تواند فرصت تشخیص بدهد، اما I/O شدید latency را بالا می‌برد و جای RAM کافی نیست. OOM event، فشار حافظه و working set سرویس‌ها را مانیتور کنید. افزایش worker یا cache بدون بودجه حافظه می‌تواند کل سرور را ناپایدار کند.
Log و Journal
لاگ authentication، firewall، وب‌سرور، برنامه و دیتابیس باید محل، retention و مالک مشخص داشته باشد. rotation را پیش از پر شدن دیسک تست کنید. secret، cookie و payload پرداخت را ثبت نکنید. timestamp و request ID مشترک کمک می‌کند یک رخداد از proxy تا برنامه دنبال شود.
Backup مستقل و رمزنگاری‌شده
دیتابیس، فایل کاربر و config را سازگار backup کنید و نسخه‌ای خارج از همان سرور/حساب نگه دارید. retention، encryption و دسترسی restore را تعیین کنید. backup بدون آزمون restore یک فرض است. یک بازیابی دوره‌ای روی محیط جدا انجام و زمان واقعی را با RTO مقایسه کنید.
مانیتورینگ پایه
- دسترسی سرویس و اعتبار TLS
- CPU، load، RAM، swap و OOM
- دیسک، inode و I/O latency
- listener و processهای حیاتی
- نرخ خطا و p95 پاسخ
- تازگی backup و نتیجه jobها
هر alert باید severity، مسئول و runbook داشته باشد. هشدار بعد از ۱۰۰٪ شدن دیسک دیر است؛ threshold باید فرصت اقدام بدهد و trend رشد را نیز نشان دهد.
Audit و ثبت تغییر
چه کسی، چه زمانی و چرا config را تغییر داده است؟ فایل‌ها را نسخه‌دار کنید اما secret را وارد Git نکنید. release یا ticket باید نتیجه validation و rollback را همراه داشته باشد. تغییر دستی بدون ثبت باعث configuration drift و بازگشت خطا در سرور بعدی می‌شود.
Smoke Test تحویل
ss -lntup
systemctl --failed
journalctl -p err -b
df -h
free -hپیام error در journal الزاماً incident فعال نیست؛ سرویس و timestamp را بررسی کنید. از بیرون نیز SSH مجاز، HTTP/HTTPS، DNS و پورت‌های بسته را تست کنید. سپس reboot کنترل‌شده را در صورت امکان اجرا و auto-start سرویس‌ها را تأیید کنید.
ترتیب تحویل Production
- inventory و recovery access
- patch و reboot کنترل‌شده
- user و SSH key
- firewall و network test
- time، DNS و TLS
- runtime و سرویس‌ها
- backup و restore test
- monitor، alert و مستندات
برای استقرار کامل سایت روی Ubuntu، راهنمای راه‌اندازی سرور Ubuntu لایه وب، runtime و DNS را نیز پوشش می‌دهد.
اشتباه‌های رایج
- بستن password/root پیش از تست کلید
- فایروال بدون console اضطراری
- انتشار دیتابیس یا Redis
- اجرای همه چیز با root
- مجوز
777 - secret در Git و log
- backup بدون restore test
- هشدار بدون مسئول پاسخ‌گو
چه زمانی کمک تخصصی لازم است؟
اگر سرور production، فروشگاهی یا دارای شبکه محدود است، ترتیب اشتباه SSH و firewall می‌تواند دسترسی را قطع کند. نصب و کانفیگ سرور لینوکس می‌تواند baseline امنیت، backup، مانیتورینگ و مستندات بازیابی را متناسب با سرویس پیاده کند.
پرسش‌های متداول
آیا اسکریپت Hardening آماده کافی است؟
خیر؛ باید تغییرات، نسخه توزیع، نیاز برنامه و rollback آن را بررسی کنید.
آیا Fail2ban در مرحله اول لازم است؟
می‌تواند مفید باشد، اما بعد از log صحیح، SSH key، firewall و allowlist؛ جای آن‌ها را نمی‌گیرد.
سرور هر چند وقت patch شود؟
بر اساس severity، exposure و maintenance policy؛ update بحرانی نباید تا تقویم ثابت منتظر بماند.
چرا باید reboot را تست کنیم؟
تا auto-start، mount، شبکه و وابستگی‌ها پیش از رخداد واقعی آزموده شوند.