۲۰ راهکار حرفه‌ای برای افزایش امنیت سرور مجازی (VPS)

برای افزایش امنیت سرور مجازی (VPS) نصب یک فایروال یا آنتی‌ویروس کافی نیست. یک VPS Production باید به‌صورت لایه‌ای Hardening شود: سیستم‌عامل پشتیبانی‌شده و Patchشده داشته باشد، دسترسی مدیریتی آن با SSH Key یا سازوکار امن RDP محافظت شود، پورت‌های غیرضروری بسته باشند، اصل Least Privilege اجرا شود، رویدادها لاگ و مانیتور شوند و در نهایت Backup قابل بازیابی و برنامه واکنش به حادثه وجود داشته باشد.

خلاصه عملی: اگر همین امروز یک VPS جدید تحویل گرفته‌اید، اول سیستم‌عامل را Update کنید؛ یک حساب Admin غیر-root بسازید؛ SSH Key یا NLA/MFA را فعال کنید؛ Firewall را روی Default-Deny قرار دهید؛ فقط پورت‌های موردنیاز را باز کنید؛ SELinux یا AppArmor را فعال نگه دارید؛ Log و Monitoring راه بیندازید و قبل از استقرار Production یک Backup و Restore Test واقعی داشته باشید.

اگر هنوز با ساختار این سرویس آشنا نیستید، ابتدا مقاله سرور مجازی چیست را بخوانید. در این راهنما فرض می‌کنیم VPS ساخته شده و هدف شما آماده‌کردن آن برای استفاده واقعی و امن در Production است.

نکته درباره CentOS: CentOS Linux 8 و CentOS Stream 8 دیگر پشتیبانی امنیتی فعال ندارند. بنابراین مثال‌های خانواده RHEL در این مقاله برای CentOS Stream 9، RHEL 9 و توزیع‌های سازگار در نظر گرفته شده‌اند. اگر هنوز CentOS 8 دارید، Migration به یک نسخه پشتیبانی‌شده بخشی از Hardening است، نه یک کار اختیاری.

برای Baseline فنی می‌توانید از CIS Benchmarkهای Ubuntu و Benchmark متناظر سیستم‌عامل خود استفاده کنید. برای طراحی فرآیند Patch و Incident Response نیز NIST SP 800-40 Rev.4 و NIST SP 800-61 Rev.3 مراجع مناسبی هستند.

امنیت سرور مجازی چیست و مسئولیت آن با چه کسی است؟

VPS Security مجموعه‌ای از کنترل‌های پیشگیرانه، تشخیصی و بازیابی است که از سیستم‌عامل، حساب‌های کاربری، سرویس‌ها، شبکه، Application و داده‌های VPS در برابر دسترسی غیرمجاز، سوءاستفاده، Malware، Credential Theft و خرابی محافظت می‌کند.

امنیت VPS یک مدل Shared Responsibility دارد. Provider مسئول لایه‌هایی مانند Host فیزیکی، Hypervisor و بخش‌هایی از شبکه‌ای است که در قرارداد سرویس تعریف شده‌اند؛ در مقابل، در یک VPS مدیریت‌نشده معمولاً Guest OS، Accounts، SSH/RDP، Firewall داخل سیستم‌عامل، Application، Backup و Patch نرم‌افزارهای نصب‌شده برعهده مشتری است. برای درک لایه Host و Guest می‌توانید مقاله مجازی‌سازی چیست را مطالعه کنید.

اگر هنوز در مرحله تهیه VPS هستید، راهنمای خرید سرور مجازی را قبل از انتخاب Managed یا Unmanaged مطالعه کنید.

چک‌لیست ۲۰ راهکار افزایش امنیت سرور مجازی

این جدول براساس اولویت عملی طراحی شده است. سطح ریسک یعنی ریسک اجرا نکردن آن کنترل روی یک VPS متصل به اینترنت در محیط Production.

* اهمیت WAF برای VPSهایی است که Web Application در معرض اینترنت اجرا می‌کنند.

راهکارهای عملی افزایش امنیت VPS؛ از مهم‌ترین اقدام شروع کنید

به‌روزرسانی سیستم‌عامل و ساخت Security Baseline

اولین اصل Secure VPS این است که سیستم‌عامل و Packageهای آن هنوز Security Update دریافت کنند. Hardening یک سیستم EOL نمی‌تواند نبود Patch را جبران کند.

Ubuntu 22.04:

sudo apt update
sudo apt full-upgrade
sudo apt autoremove
sudo reboot

در Ubuntu Server، ابزار unattended-upgrades برای نصب خودکار Security Update قابل استفاده است. بهتر است به‌جای ویرایش مستقیم فایل اصلی، تنظیمات سفارشی را به‌صورت Drop-in در /etc/apt/apt.conf.d/ قرار دهید.

sudo dpkg-reconfigure unattended-upgrades
systemctl status unattended-upgrades

RHEL / CentOS Stream 9:

sudo dnf check-update
sudo dnf upgrade
sudo reboot

سیستم را بعد از Patch فقط «آپدیت‌شده» فرض نکنید؛ سرویس‌های مهم را Smoke Test کنید، Reboot-required را بررسی کنید و در محیط‌های حساس ابتدا روی Staging یا یک Node آزمایشی Patch را اعتبارسنجی کنید.

منابع رسمی: Ubuntu Security Updates و NIST Patch Management.

یک Patch Cadence مشخص داشته باشید

عبارت «مرتب آپدیت کنید» برای Production کافی نیست. باید Owner، Deadline و Verification وجود داشته باشد. نمونه زیر یک Policy پیشنهادی است و الزام NIST محسوب نمی‌شود؛ بازه واقعی باید با Severity، Exploitability، Exposure و SLA شما هماهنگ شود.

ورود مستقیم root را غیرفعال و Admin مجزا بسازید

روی Linux برای کار روزمره با root وارد نشوید. یک User مجزا بسازید، دسترسی مدیریتی را فقط با sudo بدهید و فعالیت‌های Privileged را قابل ردیابی نگه دارید.

Ubuntu:

sudo adduser vpsadmin
sudo usermod -aG sudo vpsadmin

RHEL-family:

sudo useradd -m vpsadmin
sudo passwd vpsadmin
sudo usermod -aG wheel vpsadmin

قبل از بستن root، حتماً در یک Session دوم ورود User جدید و اجرای sudo را تست کنید تا خودتان را از سرور Lock Out نکنید.

SSH را با Key و تنظیمات سخت‌گیرانه امن کنید

برای Admin Access لینوکسی، Public-Key Authentication باید اولویت بالاتری از Password-only Login داشته باشد. OpenSSH در Ubuntu از Key-based Authentication و کلیدهای مدرن پشتیبانی می‌کند.

روی سیستم Admin:

ssh-keygen -t ed25519 -a 64
ssh-copy-id vpsadmin@SERVER_IP

سپس یک Drop-in برای SSH بسازید:

sudo nano /etc/ssh/sshd_config.d/99-hardening.conf

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
MaxAuthTries 3
AllowGroups sshusers

در صورت استفاده از AllowGroups ابتدا Group و Membership را ایجاد کنید:

sudo groupadd sshusers
sudo usermod -aG sshusers vpsadmin

قبل از Reload حتماً Syntax را Validate کنید:

sudo sshd -t

در Ubuntu:

sudo systemctl reload ssh

در RHEL-family:

sudo systemctl reload sshd

راهنمای کامل‌تر را در استفاده از SSH Key در سرور مجازی و افزایش امنیت SSH بخوانید.

منبع رسمی: Ubuntu OpenSSH Server Documentation.

در Windows VPS، RDP را مثل یک سرویس حساس مدیریت کنید

اگر Windows VPS دارید، RDP را فقط زمانی فعال نگه دارید که واقعاً نیاز است. Network Level Authentication یا NLA باید فعال باشد تا Authentication قبل از ساخت Session کامل انجام شود.

بررسی و فعال‌سازی NLA با PowerShell:

Get-ItemProperty `
  'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name UserAuthentication

Set-ItemProperty `
  'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name UserAuthentication `
  -Value 1

برای Serverهای مهم، RDP عمومی روی اینترنت گزینه مطلوبی نیست. دسترسی را از IPهای Admin محدود کنید یا از VPN / RD Gateway استفاده کنید.

منبع رسمی: Microsoft Remote Desktop Security Guidance.

MFA را برای دسترسی‌های Privileged فعال کنید

SSH Key یا Password قوی به‌تنهایی پایان کار نیست. برای حساب‌های Privileged، یک Factor دوم ریسک استفاده از Credential دزدیده‌شده را کاهش می‌دهد.

برای Linux می‌توانید در محیط‌های سازگار از Hardware-backed FIDO/U2F Key در OpenSSH استفاده کنید:

ssh-keygen -t ed25519-sk

برای Windows RDS، معماری‌هایی مانند RD Gateway به‌همراه MFA مناسب‌تر از بازگذاشتن مستقیم 3389 هستند. در انتخاب روش MFA، Factorهای مقاوم‌تر در برابر Phishing مانند Security Key بر SMS ارجحیت دارند.

منابع رسمی: CISA MFA Guidance و مستندات OpenSSH Ubuntu.

Firewall را با سیاست Default-Deny تنظیم کنید

اصل ساده است: هر Port یا Protocolی که برای Business Function لازم نیست، نباید از Internet قابل دسترسی باشد.

Ubuntu با UFW:

sudo ufw default deny incoming
sudo ufw default allow outgoing

# فقط IP مدیریتی نمونه؛ با IP واقعی خود جایگزین کنید.
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

# فقط در صورت اجرای وب‌سرویس:
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

sudo ufw enable
sudo ufw status verbose

RHEL / CentOS Stream 9 با firewalld:

sudo systemctl enable --now firewalld

sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --permanent \
  --add-rich-rule='rule family="ipv4" source address="203.0.113.10/32" service name="ssh" accept'

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

sudo firewall-cmd --list-all

در RHELهای مدرن، برای Configurationهای معمول از firewalld و برای Rule Setهای پیشرفته از nftables استفاده می‌شود. چند Firewall Manager را هم‌زمان روی یک Host مدیریت نکنید. اگر زیرساخت Legacy شما بر iptables است، Ruleها را مستند و Audit کنید؛ اما برای Deployment جدید RHEL-family بهتر است با Toolchain فعلی سیستم‌عامل هماهنگ باشید.

Windows Server:

Set-NetFirewallProfile `
  -Profile Domain,Private,Public `
  -Enabled True `
  -DefaultInboundAction Block

Get-NetFirewallProfile

نمونه Allow کردن RDP فقط از IP مدیریتی:

New-NetFirewallRule `
  -DisplayName "RDP from Admin IP" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 3389 `
  -RemoteAddress 203.0.113.10 `
  -Action Allow

هشدار: قبل از تغییر Remote Firewall، Console اضطراری یا Session دوم داشته باشید و Rule جدید را قبل از حذف Rule قبلی تست کنید.

پورت‌ها و سرویس‌های بلااستفاده را حذف کنید

هر Daemon فعال باید یک دلیل Business یا Technical مشخص داشته باشد. ابتدا Inventory بگیرید:

sudo ss -lntup
sudo systemctl --type=service --state=running

سپس Service واقعاً بلااستفاده را Stop و Disable کنید:

sudo systemctl disable --now SERVICE_NAME

Telnet و FTP بدون رمزنگاری را برای مدیریت و انتقال Credential استفاده نکنید. برای انتقال فایل روی Linux، SFTP مبتنی بر SSH معمولاً انتخاب مناسب‌تری است.

اصل Least Privilege را برای User، Service و File اجرا کنید

هر User و Process باید فقط Permission لازم برای وظیفه خود را داشته باشد. برنامه وب را با root اجرا نکنید و برای Serviceها Account مجزا بسازید.

sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp
sudo chown -R myapp:myapp /srv/myapp
sudo chmod -R o-rwx /srv/myapp

دسترسی‌های sudo را نیز Audit کنید:

sudo -l
sudo visudo

از دادن Ruleهایی مانند ALL=(ALL) NOPASSWD: ALL به Userهای عمومی یا Automation بدون Threat Review خودداری کنید.

SELinux یا AppArmor را خاموش نکنید

Mandatory Access Control می‌تواند حتی پس از Compromise یک Process، دسترسی آن به سایر قسمت‌های سیستم را محدود کند.

Ubuntu / AppArmor:

sudo aa-status

Profileهای مهم باید در Enforce Mode باشند؛ در زمان Troubleshooting به‌جای خاموش‌کردن کامل Framework، Profile یا Policy مشکل‌دار را بررسی کنید.

RHEL-family / SELinux:

getenforce
sestatus

حالت مطلوب Production معمولاً:

Enforcing

در صورت نیاز موقت برای Debug:

sudo setenforce 0

# بعد از عیب‌یابی:
sudo setenforce 1

Red Hat صراحتاً Enforcing را حالت توصیه‌شده معرفی می‌کند و Disabled کردن SELinux را برای Production توصیه نمی‌کند.

منابع رسمی: Ubuntu AppArmor و Red Hat SELinux.

Fail2Ban را به‌عنوان لایه مکمل Brute-Force Protection استفاده کنید

Fail2Ban Logها را بررسی می‌کند و Hostهایی را که الگوی Authentication Failure تکراری دارند موقتاً Ban می‌کند. اما جایگزین SSH Key، MFA یا Firewall نیست.

Ubuntu:

sudo apt update
sudo apt install fail2ban
sudo systemctl enable --now fail2ban

به‌جای ویرایش /etc/fail2ban/jail.conf یک فایل Local بسازید:

sudo nano /etc/fail2ban/jail.d/sshd.local

[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1h

سپس:

sudo fail2ban-client -t
sudo systemctl restart fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

در RHEL-family ممکن است Package از Repository اضافه مانند EPEL تأمین شود؛ Repositoryهای سازمان خود را قبل از نصب بررسی کنید.

منبع رسمی: Fail2Ban Project.

Management Plane را پشت VPN، Bastion یا IP Allowlist قرار دهید

برای VPS سازمانی، بهتر است SSH یا RDP از کل Internet قابل دسترسی نباشد. یک معماری معمول این است:

Administrator
      |
     MFA
      |
 VPN / Bastion
      |
  Firewall
      |
   SSH/RDP
      |
     VPS

برای Windows، RD Gateway امکان Remote Access از طریق HTTPS را فراهم می‌کند و می‌تواند همراه سازوکارهای MFA استفاده شود. برای Linux نیز WireGuard، IPsec یا VPN سازمانی می‌تواند Management Plane را از ترافیک Public جدا کند.

برای Web Server از TLS و در صورت نیاز WAF استفاده کنید

اگر VPS میزبان Web Application است، تمام HTTP حساس باید روی TLS منتقل شود. WAF نیز در لایه Application می‌تواند Ruleهایی برای الگوهای مخرب Web Request اعمال کند؛ اما WAF جایگزین Patch کردن CMS، Framework یا Application آسیب‌پذیر نیست.

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

نمونه Certbot برای Nginx:

sudo certbot --nginx

و برای Apache:

sudo certbot --apache

پس از نصب Certificate، Renewal را تست کنید:

sudo certbot renew --dry-run

Audit Log، Log Rotation و Centralized Logging راه‌اندازی کنید

اگر بعد از Incident ندانید چه Userی Login کرده، چه Processی اجرا شده یا چه Fileی تغییر کرده، Detection و Forensics بسیار دشوار می‌شود. Logهای امنیتی مهم را فقط روی همان VPS نگه ندارید؛ مهاجمی که Privilege بالا گرفته ممکن است آن‌ها را حذف یا دست‌کاری کند.

Linux auditd:

# Ubuntu
sudo apt install auditd audispd-plugins

# RHEL-family
sudo dnf install audit

sudo systemctl enable --now auditd
sudo auditctl -s

نمونه Watch موقت برای تغییر Account Database:

sudo auditctl -w /etc/passwd -p wa -k identity
sudo auditctl -w /etc/group -p wa -k identity
sudo ausearch -k identity

برای Production، Ruleها را در /etc/audit/rules.d/ Persist کنید و آن‌ها را با Baseline سازمان هماهنگ کنید.

Log Rotation نمونه:

/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
}

قبل از اعمال:

sudo logrotate -d /etc/logrotate.conf

زمان سیستم نیز باید همگام باشد تا Timeline رویدادها قابل اتکا بماند:

timedatectl status
sudo timedatectl set-ntp true

برای Centralized Logging می‌توانید از rsyslog روی TLS، Wazuh، SIEM یا Log Platform سازمان استفاده کنید. راهنمای ابزارهای مرتبط در مقاله نرم‌افزارهای مانیتورینگ شبکه آمده است.

مرجع مفهومی Log Management: NIST SP 800-92.

از HIDS، Wazuh، OSSEC و File Integrity Monitoring استفاده کنید

Firewall به شما نمی‌گوید فایل /etc/ssh/sshd_config چه زمانی تغییر کرده یا Binary مهمی دست‌کاری شده است. برای این موارد به Host-based Detection و FIM نیاز دارید.

Wazuh قابلیت‌هایی مانند File Integrity Monitoring، Vulnerability Detection، Log Analysis و Active Response دارد. بعد از نصب Agent، حداقل سلامت آن را بررسی کنید:

sudo systemctl status wazuh-agent

نمونه مفهومی FIM در Wazuh:

<syscheck>
  <directories check_all="yes" realtime="yes">/etc,/usr/bin</directories>
</syscheck>

OSSEC نیز HIDS متن‌باز با Log Analysis، Integrity Checking، Registry Monitoring، Rootkit Detection و Active Response است. اگر از OSSEC استفاده می‌کنید، Active Response را ابتدا در محیط Test اعتبارسنجی کنید؛ Rule اشتباه می‌تواند IP قانونی را Block کند.

Tripwire: پس از ساخت یک سرور Clean و مورداعتماد Baseline ایجاد کنید:

sudo tripwire --init
sudo tripwire --check

Baseline آلوده عملاً ارزش تشخیصی ندارد؛ ابتدا مطمئن شوید Image و Packageها Trusted هستند.

منابع رسمی: Wazuh Vulnerability Detection، OSSEC Documentation و Open Source Tripwire.

Anti-malware را براساس Workload انتخاب کنید

این تصور که Linux «Malware نمی‌گیرد» صحیح نیست؛ اما از آن طرف هم نصب ClamAV روی هر VPS بدون Threat Model لزوماً بهترین تصمیم نیست. Mail Server، File Server، Upload Server و Shared Hosting سناریوهایی هستند که File Scanning در آن‌ها ارزش بیشتری دارد.

Ubuntu / ClamAV:

sudo apt install clamav clamav-daemon
sudo freshclam

# نمونه اسکن یک مسیر Upload:
sudo clamscan -r --infected /srv/uploads

اگر از clamd استفاده می‌کنید، آن را با Service Account محدود اجرا کنید و TCP Socket آن را روی اینترنت Public باز نکنید.

Windows Server:

Get-MpComputerStatus
Update-MpSignature

rkhunter: می‌تواند صرفاً به‌عنوان Signal ثانویه استفاده شود:

sudo rkhunter --check

اما روی آن به‌عنوان Detection Stack اصلی حساب نکنید. Release رسمی معرفی‌شده در سایت Rootkit Hunter نسخه 1.4.6 مربوط به سال ۲۰۱۸ است؛ برای Production جدید، Wazuh/OSSEC، FIM، Audit و EDR/HIDS مدرن اولویت بیشتری دارند.

منابع رسمی: ClamAV Documentation و Rootkit Hunter Project.

Secretها، Passwordها و Private Keyها را مثل داده حساس مدیریت کنید

Private Key، API Token، Database Password و Cloud Credential را داخل Repository عمومی، فایل قابل‌خواندن برای همه Userها یا Chat ذخیره نکنید.

Permission یک SSH Private Key در Linux:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 600 ~/.ssh/authorized_keys

برای هر Administrator کلید مستقل داشته باشید؛ یک Private Key مشترک میان تیم باعث می‌شود Revocation و Attribution دشوار شود. در زمان خروج کارمند یا احتمال Leak، Credential را Rotate کنید و کلید مرتبط را از authorized_keys حذف کنید.

Backup را خارج از VPS نگه دارید و Restore را آزمایش کنید

Snapshot راحت است اما همیشه معادل Backup مستقل نیست. اگر Backup از همان Credential، همان Storage یا همان Failure Domain استفاده کند، Ransomware یا Compromise می‌تواند هر دو را تحت تأثیر قرار دهد.

برای Data مهم، حداقل این ویژگی‌ها را هدف بگیرید:

• Backup زمان‌بندی‌شده و Versioned؛
• نسخه‌ای خارج از VPS اصلی؛
• رمزگذاری در Storage و Transfer؛
• Retention مشخص؛
• نسخه Offline یا Immutable برای داده‌های حیاتی؛
• Restore Test دوره‌ای.

نمونه ساده انتقال Linux به Backup Host:

rsync -aHAX --delete \
  /etc /var/www \
  backupuser@BACKUP_HOST:/srv/backups/vps01/

هشدار: Mirror با --delete به‌تنهایی Backup Versioned محسوب نمی‌شود؛ حذف یا Encryption فایل‌های Source می‌تواند به مقصد Sync شود. مقصد باید Snapshot/Versioning یا Retention مستقل داشته باشد.

برای Windows Server:

Get-WindowsFeature -Name Windows-Server-Backup
Install-WindowsFeature -Name Windows-Server-Backup

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

مرجع Recovery: CISA StopRansomware Guide.

سرویس‌ها را از یکدیگر جدا کنید

Web Server، Database و Worker نباید بدون ضرورت همگی با یک User، یک Permission Set و یک Secret اجرا شوند. حتی روی یک VPS واحد، Service Account مستقل، File Permission مناسب و Namespace/Container می‌تواند Blast Radius را کم کند.

Container به‌خودی‌خود به معنی «امن» نیست. Image و Dependency آن نیز باید Update شوند، Capabilityهای غیرضروری حذف شوند، Secret داخل Image قرار نگیرد و Container بدون ضرورت Privileged اجرا نشود.

Resource و Network Anomaly را مانیتور کنید

افزایش ناگهانی CPU، RAM، Disk I/O، تعداد Connection یا Outbound Traffic می‌تواند نشانه Bug، Traffic Spike یا Abuse امنیتی باشد. Baseline طبیعی سرور را بشناسید و روی انحراف‌های معنی‌دار Alert بسازید.

top
free -h
df -h
ss -s
ss -lntup
journalctl -p warning --since today

ابزارهایی مانند Prometheus، Zabbix، Netdata یا Monitoring Stack سازمان می‌توانند Metricها را به‌صورت متمرکز نگه دارند.

توجه کنید Firewall داخل VPS جایگزین DDoS Mitigation در Upstream نیست. برای شناخت این نوع حمله، مقاله حمله DDoS چیست را ببینید.

همچنین Security Agent یا Logging بیش از حد می‌تواند روی VPS کوچک CPU، RAM و Disk I/O مصرف کند. Monitoring را بعد از هر Control جدید بررسی کنید؛ راهنمای افزایش سرعت سرور مجازی برای تشخیص Bottleneck مفید است.

Incident Response Plan را قبل از Incident آماده کنید

وقتی احتمال Compromise وجود دارد، زمان مناسبی برای تصمیم‌گیری از صفر نیست. حداقل مشخص کنید چه کسی Incident را Declare می‌کند، VPS چگونه Isolate می‌شود، Evidence کجا ذخیره می‌شود، Credentialها چگونه Rotate می‌شوند و Recovery از کدام Backup انجام خواهد شد.

چک‌لیست واکنش:

1. Detect: Alert، Log، User Report یا Anomaly را تأیید کنید.
2. Contain: دسترسی مهاجم را بدون نابودکردن Evidence محدود کنید؛ Firewall، Network Isolation یا Disable Account.
3. Preserve Evidence: Logها، Snapshot/Forensic Image و Timeline را قبل از Cleanup ذخیره کنید.
4. Eradicate: Root Cause را پیدا کنید؛ Patch، Credential Rotation یا Rebuild انجام دهید.
5. Recover: از Image/Backup شناخته‌شده سالم Restore کنید.
6. Monitor: IOCها و Authenticationها را بعد از Recovery زیر نظر بگیرید.
7. Lessons Learned: Control، Runbook و Alertهایی را که شکست خورده‌اند اصلاح کنید.

flowchart LR
A[Detect] --> B[Contain]
B --> C[Preserve Evidence]
C --> D[Eradicate]
D --> E[Recover]
E --> F[Lessons Learned]

این Flow با اصول جدید Incident Response در NIST SP 800-61 Rev.3 هماهنگ است؛ هدف، آماده‌سازی سازمان برای Detection، Response و Recovery در چارچوب مدیریت ریسک است.

اشتباهات و باورهای غلط درباره امنیت VPS

تغییر پورت SSH امنیت اصلی شما نیست

انتقال SSH از پورت 22 به پورت دیگری می‌تواند مقدار Scan و Noise لاگ را کاهش دهد، اما Port مخفی نیست و مهاجم می‌تواند Port Scan انجام دهد. اگر نیاز عملی دارید تغییرش دهید، اما آن را جایگزین SSH Key، MFA، Allowlist و Firewall نکنید.

Fail2Ban ضعف Password را جبران نمی‌کند

Fail2Ban Layer مکمل است. Credential قوی، Key-based Authentication و محدودکردن Network Access اهمیت بیشتری دارند.

Linux ذاتاً امن و Windows ذاتاً ناامن نیست

امنیت نهایی به Lifecycle، Patch، Configuration، Services، Privileges و Monitoring وابسته است. یک Linux بدون Patch و با SSH ضعیف می‌تواند از Windows Server Hardening‌شده ناامن‌تر باشد.

IPv6 را فقط برای «امن‌تر شدن» خاموش نکنید

مشکل اصلی معمولاً ناهماهنگی Policy بین IPv4 و IPv6 است. اگر IPv6 فعال است، Firewall و Monitoring باید آن را هم پوشش دهند. فقط زمانی Protocol را Disable کنید که معماری شما واقعاً به آن نیاز ندارد و Impact آن بررسی شده است.

WAF مشکل کد آسیب‌پذیر را حل نمی‌کند

WAF می‌تواند Attack Patternها را Filter کند، اما Patch کردن Framework، CMS، Plugin، Dependency و اصلاح Vulnerability همچنان لازم است.

Snapshot همان Backup مستقل نیست

Snapshot برای Rollback سریع بسیار مفید است؛ اما اگر در همان Failure Domain یا همان Account قرار دارد، نباید تنها Recovery Strategy شما باشد.

Antivirus مساوی Secure VPS نیست

Anti-malware فقط یک Layer است. اگر root با Password ضعیف از اینترنت قابل دسترس باشد، نصب چند Scanner مشکل معماری Access Control را حل نمی‌کند.

Container به‌طور خودکار Security Boundary کامل نیست

Containerهای Privileged، Imageهای قدیمی، Socketهای حساس و Secretهای Embedشده می‌توانند همان VPS را در معرض خطر قرار دهند. Isolation باید همراه Least Privilege و Patch باشد.

چک‌لیست امنیت VPS قبل از رفتن به Production

جمع‌بندی؛ Secure VPS یک پروژه یک‌باره نیست

افزایش امنیت سرور مجازی با نصب یک Tool تمام نمی‌شود. ترتیب اولویت اهمیت دارد: ابتدا سیستم‌عامل Supported، Patch، Access Control و Firewall؛ سپس Least Privilege، SELinux/AppArmor، Logging و HIDS؛ و در نهایت Backup، Recovery Test و Incident Response.

به بیان ساده، یک VPS امن سه ویژگی دارد: نفوذ را سخت می‌کند، اتفاق مشکوک را سریع می‌بیند و بعد از Incident قابلیت بازیابی دارد.

هر بار که Service جدید نصب می‌کنید، User جدید می‌سازید، Port باز می‌کنید یا Architecture را تغییر می‌دهید، Threat Surface نیز تغییر می‌کند. بنابراین این چک‌لیست را بعد از هر تغییر مهم و حداقل در Auditهای دوره‌ای دوباره مرور کنید.

سوالات متداول درباره افزایش امنیت سرور مجازی

مهم‌ترین اقدام برای افزایش امنیت VPS چیست؟

یک اقدام واحد کافی نیست؛ اما برای VPS جدید، استفاده از سیستم‌عامل پشتیبانی‌شده و Patchشده، امن‌سازی دسترسی مدیریتی با SSH Key یا NLA/MFA، فعال‌کردن Firewall روی Default-Deny و تهیه Backup قابل بازیابی بیشترین اولویت را دارند.

آیا تغییر پورت SSH باعث امن شدن VPS می‌شود؟

تغییر پورت می‌تواند Scanهای خودکار و Noise لاگ را کاهش دهد، اما کنترل امنیتی اصلی نیست. SSH Key، غیرفعال‌کردن Password Login در شرایط مناسب، MFA، IP Allowlist و Firewall اهمیت بیشتری دارند.

آیا Fail2Ban برای امنیت SSH کافی است؟

خیر. Fail2Ban تلاش‌های Authentication تکراری را شناسایی و IP را Ban می‌کند، اما جایگزین Authentication قوی و محدودکردن دسترسی شبکه نیست.

آیا روی VPS لینوکس به آنتی‌ویروس نیاز داریم؟

به Workload بستگی دارد. برای Mail Server، File Server، Upload Server و محیط‌هایی که فایل‌های کاربران را پردازش می‌کنند ClamAV یا ابزار مشابه می‌تواند مفید باشد؛ اما Anti-malware جایگزین Patch، Access Control، FIM و Monitoring نیست.

SELinux را برای رفع خطا خاموش کنیم؟

در Production بهتر است نه. ابتدا Denialهای SELinux را بررسی و Policy یا Label مشکل‌دار را اصلاح کنید. برای عیب‌یابی موقت می‌توان از Permissive استفاده کرد و پس از رفع مشکل دوباره به Enforcing برگشت.

AppArmor و SELinux چه نقشی در امنیت VPS دارند؟

هر دو Mandatory Access Control هستند و می‌توانند مشخص کنند یک Process حتی بعد از اجرا با User مجاز به چه فایل‌ها و Resourceهایی دسترسی داشته باشد. Ubuntu معمولاً از AppArmor و خانواده RHEL از SELinux استفاده می‌کند.

Snapshot برای Backup سرور مجازی کافی است؟

برای Recovery سریع مفید است، اما بهتر است تنها Backup شما نباشد. برای اطلاعات حیاتی نسخه‌ای خارج از VPS و ترجیحاً خارج از Failure Domain اصلی نگه دارید و Restore آن را آزمایش کنید.

Managed VPS یعنی دیگر مسئولیتی برای امنیت نداریم؟

خیر. Scope عبارت Managed بین Providerها متفاوت است. حتی در سرویس مدیریت‌شده، Accountها، Application، Business Data، Secretها و بخشی از Access Control می‌توانند همچنان برعهده مشتری باشند؛ SLA را دقیق بررسی کنید.

Wazuh بهتر است یا OSSEC؟

هر دو برای Host-based Detection قابل استفاده‌اند. Wazuh قابلیت‌های متمرکز مانند FIM، Vulnerability Detection و Integrationهای گسترده‌ای ارائه می‌دهد؛ OSSEC نیز HIDS متن‌باز فعال با Log Analysis، Integrity Checking و Active Response است. انتخاب باید بر اساس اندازه زیرساخت، منابع VPS، Workflow هشدار و نیاز تیم انجام شود.

در صورت شک به هک شدن VPS اولین کار چیست؟

قبل از Cleanup عجولانه، Incident را ارزیابی کنید، دسترسی مهاجم را Contain کنید و Logها و Evidence ضروری را حفظ کنید. سپس Root Cause را پیدا کرده، Credentialها را از یک سیستم سالم Rotate کنید و در صورت نیاز VPS را از Image یا Backup شناخته‌شده سالم Rebuild کنید.

منابع رسمی و استانداردها

• NIST SP 800-40 Rev.4 — Enterprise Patch Management
• NIST SP 800-61 Rev.3 — Incident Response
• NIST SP 800-92 — Log Management
• CIS Ubuntu Linux Benchmarks
• Ubuntu Security Updates
• Ubuntu OpenSSH Server
• Ubuntu AppArmor
• Red Hat SELinux Documentation
• Microsoft Windows Server Security Baseline
• Fail2Ban Official Project
• Wazuh Documentation
• OSSEC Documentation
• ClamAV Documentation
• Open Source Tripwire
• CISA StopRansomware Guide