امن‌سازی اولیه سرور یک اسکریپت جادویی یا تغییر پورت SSH نیست. هدف، کاهش سطح حمله، محدود کردن اثر نفوذ، حفظ قابلیت بازیابی و قابل‌ردیابی کردن تغییرات است. ترتیب اجرا حیاتی است: اگر password login یا firewall را پیش از آزمون کلید و console محدود کنید، ممکن است خودتان از سرور بیرون بمانید.
پاسخ سریع: ابتدا inventory و دسترسی اضطراری provider را تأیید کنید؛ سیستم را patch کنید، برای هر مدیر حساب جدا با SSH key بسازید و دسترسی را در session دوم بیازمایید. سپس firewall، سرویس‌ها، permission، secret، TLS، backup، log و alert را مرحله‌ای با rollback تنظیم کنید.
امنیت بر اساس Threat Model
سرور وب عمومی، دیتابیس داخلی، bastion و runner CI/CD تهدیدها و دسترسی‌های متفاوت دارند. دارایی، داده حساس، مسیرهای ورودی، مدیران، dependency و RPO/RTO را مشخص کنید. hardening بدون دانستن نقش ممکن است سرویس لازم را قطع یا کنترل مهمی را جا بیندازد.
مرحله صفر: Recovery Access
console، rescue mode یا دسترسی out-of-band ارائه‌دهنده را واقعاً تست کنید. حساب provider باید MFA، credential امن و افراد مجاز روشن داشته باشد. snapshot مفید است اما جای backup مستقل یا console را نمی‌گیرد. روش بازگشت هر تغییر شبکه و SSH را پیش از اجرا ثبت کنید.
Inventory و Baseline
cat /etc/os-release
uname -r
ip -br addr
ss -lntup
systemctl --failed
findmntاین فرمان‌ها نسخه، interface، listener، سرویس failed و mount را بدون تغییر نشان می‌دهند. هر port و process باید owner و دلیل داشته باشد. خروجی حاوی IP و hostname را پیش از اشتراک عمومی پاک‌سازی کنید.
Patch و منبع بسته
update امنیتی را از repository معتبر و با maintenance policy نصب کنید. تغییر kernel یا کتابخانه حیاتی ممکن است reboot/restart بخواهد؛ پس smoke test و window لازم است. repository شخص ثالث یک مرز اعتماد تازه است و باید کلید امضا، owner و چرخه نگهداری مشخص داشته باشد.
حساب جدا و حداقل Sudo
هر مدیر حساب مستقل داشته باشد تا revoke و audit ممکن شود. shared root password مسئولیت را مبهم می‌کند. sudo را به نیاز عملی محدود و دسترسی‌های قدیمی را دوره‌ای بازبینی کنید. service account نباید shell یا مجوز مدیریتی غیرضروری داشته باشد.
SSH Key با ترتیب ضد قفل‌شدن
- کلید عمومی مدیر را از کانال معتبر دریافت کنید.
- permission فایل و پوشه را درست کنید.
- در session دوم login و sudo را آزمایش کنید.
- config daemon را با ابزار همان نسخه validate کنید.
- root/password login را طبق نیاز مرحله‌ای محدود کنید.
- session قبلی و console را تا تأیید نهایی نگه دارید.
private key نباید روی سرور، repository یا پیام عمومی قرار گیرد. passphrase و agent امن، سرقت فایل کلید را سخت‌تر می‌کند. تغییر پورت فقط نویز اسکن را کم می‌کند و جای key، allowlist و patch نیست.
Firewall از روی جریان واقعی
ورودی را به سرویس‌های لازم محدود کنید: وب عمومی است، اما دیتابیس، Redis و پنل داخلی معمولاً نباید عمومی باشند. قبل از فعال‌سازی rule، مسیر SSH مجاز و console را تأیید کنید. cloud firewall، host firewall و ruleهای container ممکن است هم‌زمان اثر داشته باشند؛ source of truth لازم است.
IPv6 را فراموش نکنید
محدودسازی IPv4 در حالی که سرویس روی IPv6 عمومی است یک شکاف رایج است. اگر IPv6 فعال است، DNS، listener و firewall آن نیز باید مدیریت شود. خاموش کردن کور IPv6 ممکن است dependency یا شبکه را مختل کند؛ وضعیت واقعی را ثبت و آگاهانه تصمیم بگیرید.
سرویس و ماژول حداقلی
سرویس بلااستفاده سطح حمله و بار patch را بالا می‌برد. پس از inventory آن را با روش package/service manager مدیریت کنید. فایل binary یا package database را دستی پاک نکنید. پنل و agent جدید نیز privilege و مسیر شبکه اضافه می‌کنند و باید ضرورت آن روشن باشد.
Processها را با Root اجرا نکنید
وب‌سرور، برنامه و دیتابیس باید user مخصوص و دسترسی حداقلی داشته باشند. کد، upload، log و secret را از نظر مالکیت جدا کنید. مجوز 777 درمان permission نیست؛ امکان نوشتن غیرضروری می‌دهد. مسیر write لازم را دقیق و سایر مسیرها را read-only کنید.
Secret Management
رمز دیتابیس، API key و private key را در Git، image، history shell یا log نگذارید. فایل secret باید owner و permission محدود داشته باشد. rotation، revoke و audit را طراحی کنید. credential افشاشده با حذف از آخرین commit امن نمی‌شود؛ history و خود secret باید مدیریت شوند.
وب‌سرور، TLS و Header
TLS باید hostname، chain و renewal معتبر داشته باشد. protocol و cipher به نسخه کتابخانه و clientهای موردنیاز وابسته است؛ config قدیمی را کور کپی نکنید. headerهای امنیتی مانند HSTS و CSP بدون بررسی دامنه و asset می‌توانند سایت را بشکنند؛ ابتدا در staging و با rollout کنترل‌شده اجرا شوند.
دیتابیس و Cache خصوصی
listener دیتابیس و Redis را به شبکه لازم محدود و authentication و TLS را متناسب با معماری تنظیم کنید. اتصال عمومی با رمز قوی همچنان سطح حمله غیرضروری است. backup credential باید دسترسی فقط به عملیات موردنیاز داشته باشد و فایل dump حاوی داده حساس رمزنگاری و محدود شود.
Log و Audit
authentication، sudo، firewall، proxy و application event باید timestamp هماهنگ، retention و owner داشته باشند. secret، cookie و payload پرداخت را log نکنید. log روی همان دیسک بدون rotation می‌تواند خود باعث قطعی شود. دسترسی خواندن log نیز به دلیل داده حساس محدود شود.
Brute Force و Rate Control
SSH key و firewall خط اصلی‌اند؛ ابزار مسدودسازی مبتنی بر log می‌تواند نویز و تلاش تکراری را محدود کند. rule باید log معتبر، threshold و مسیر unban داشته باشد. مهاجم توزیع‌شده یا credential معتبر با block ساده حل نمی‌شود. allowlist مدیریت در صورت IP پایدار کنترل قوی‌تری است.
Backup بخشی از امنیت است
نسخه‌ای خارج از همان سرور و ترجیحاً مرز حساب نگه دارید؛ encryption، retention و دسترسی restore را تعیین کنید. backup بدون restore test یک فرض است. ransomware یا حذف اشتباه ممکن است backup متصل و قابل‌نوشتن را نیز از بین ببرد، بنابراین immutability یا جداسازی اهمیت دارد.
Monitoring و Alert امنیتی
- login ناموفق و تغییر حساب مدیریتی
- port/listener تازه
- تغییر فایل و config حساس
- سرویس failed یا restart غیرعادی
- CPU، memory، disk و network غیرعادی
- انقضای TLS و شکست backup
- نرخ 4xx/5xx و الگوی درخواست غیرعادی
alert بدون مسئول و runbook فقط نویز است. threshold را بر baseline همان سرور تنظیم کنید و کانال هشدار را خارج از زیرساختی نگه دارید که ممکن است قطع شود.
Container امنیت Host را حذف نمی‌کند
image، runtime، host kernel، network و secret همچنان نیازمند patch و محدودیت‌اند. container privileged، mount گسترده host یا socket runtime دامنه نفوذ را بالا می‌برد. image را از منبع معتبر، با نسخه ثابت و اسکن dependency وارد کنید و root داخل container را تا حد امکان حذف کنید.
ترتیب اجرای امن
- تهدید، inventory و recovery access
- backup config و snapshot مناسب
- patch و reboot کنترل‌شده
- حساب جدا، key و session دوم
- SSH و firewall مرحله‌ای
- حذف سرویس و دسترسی اضافه
- permission، secret، TLS و database exposure
- log، backup، monitoring و restore test
- مستندسازی و بازبینی دوره‌ای
چک‌لیست کانفیگ اولیه سرور این مراحل را از دید عملیات و تحویل production نیز پوشش می‌دهد.
چه کارهایی نکنیم؟
- اجرای اسکریپت hardening ناشناخته با root
- بستن SSH پیش از تست key و console
- خاموش کردن firewall برای رفع یک خطا
- قرار دادن دیتابیس و Redis روی اینترنت
- استفاده از
chmod 777 - ذخیره secret در repository
- فعال‌سازی header سخت‌گیرانه بدون تست
- تکیه به snapshot به‌عنوان تنها backup
امنیت یک‌باره نیست
patch، account review، certificate، dependency، restore test و access review چرخه دارند. تغییرات infrastructure باید code review و audit trail داشته باشند. vulnerability تازه یا تغییر نقش سرور threat model را عوض می‌کند؛ baseline را پس از هر تغییر مهم بازبینی کنید.
چه زمانی کمک تخصصی لازم است؟
اگر سرور production، فروشگاهی یا چندسرویسی است، hardening بدون نقشه شبکه ممکن است پرداخت یا دسترسی را قطع کند. نصب و کانفیگ سرور لینوکس می‌تواند baseline امنیت، firewall، backup و monitoring را با مسیر rollback و مستندات اجرا کند.
پرسش‌های متداول
آیا تغییر پورت SSH سرور را امن می‌کند؟
فقط نویز اسکن را کم می‌کند؛ key، محدودسازی دسترسی، patch و monitoring کنترل‌های اصلی‌اند.
آیا Root Login را فوراً ببندیم؟
پس از ساخت حساب مدیریتی، تست key/sudo در session دوم و تأیید console اضطراری، طبق سیاست دسترسی محدود شود.
آیا Firewall نرم‌افزاری کافی است؟
یک لایه مهم است، اما cloud firewall، authentication، patch و امنیت برنامه نیز لازم‌اند.
هر چند وقت Hardening بازبینی شود؟
دوره‌ای و همچنین پس از تغییر نقش، سرویس، شبکه، incident یا انتشار آسیب‌پذیری مرتبط.