خرید یک سرور جدید هیجانانگیز است، اما اگر همان لحظهی اول به فکر امن سازی سرور نباشید، احتمالاً تا چند ساعت دیگر لاگینهای ناموفق و تلاشهای نفوذ را در لاگها خواهید دید. اسکنرهای خودکار اینترنت دائماً در حال جستوجوی پورت ۲۲ باز و رمزهای ضعیف هستند. در این مقاله یک چکلیست عملی و زمانبندیشده برای ۶۰ دقیقهی اول بعد از تحویل سرور (توزیعهای مبتنی بر Debian/Ubuntu) آماده کردهایم. هدف: رسیدن به وضعیتی که سرور شما با رمز عبور قابل نفوذ نباشد، پورتهای غیرضروری بسته باشند و ابزارهای پایهی تشخیص نفوذ فعال شده باشند.
قدم اول: بهروزرسانی کامل سیستم (۵ دقیقه)
قبل از هر کاری، مخازن نرمافزاری را بهروز کنید و بستههای نصبشده را ارتقا دهید. سرور تازهتحویلشده ممکن است چند هفته از آخرین بهروزرسانیهای امنیتی عقب باشد.
sudo apt update
sudo apt upgrade -y
sudo apt autoremove -y
اگر کرنل جدیدی نصب شد، بعد از اتمام کل چکلیست، یک بار سرور را ریبوت کنید. بهروزرسانی منظم (مثلاً هفتهای یکبار) را در تقویم خود بگذارید؛ این سادهترین و کمهزینهترین لایهی دفاعی است.
قدم دوم: ساخت کاربر غیر root و فعالسازی sudo (۱۰ دقیقه)
کار کردن با حساب root ریسک بزرگی است: هر اشتباه تایپی یا اسکریپت مخربی، دسترسی کامل به سیستم دارد. بهجای آن، یک کاربر معمولی بسازید و به آن دسترسی sudo بدهید.
- با کاربر root وارد شوید و یک کاربر جدید ایجاد کنید:
adduser deploy
usermod -aG sudo deploy
- خروج و ورود مجدد با کاربر جدید را تست کنید:
exit
ssh deploy@your_server_ip
- از این پس همیشه با
deployوارد شوید و فقط برای دستورات مدیریتی ازsudoاستفاده کنید.
اشتباه رایج: فراموش کردن تست ورود با کاربر جدید قبل از بستن دسترسی root. اگر بعداً SSH را طوری تنظیم کنید که root را رد کند و کاربر جدید هم رمز عبور درستی نداشته باشد، عملاً از سرور قفلشدهاید. همیشه قبل از قطع دسترسی root، یک ترمینال دوم باز نگه دارید.
قدم سوم: تنظیم SSH با کلید عمومی (۱۵ دقیقه)
رمز عبور، حتی قوی، در برابر حملات brute-force آسیبپذیر است. کلید SSH (جفت کلید عمومی/خصوصی) امنیت بسیار بالاتری دارد و ورود بدون رمز را ممکن میکند.
ساخت کلید روی سیستم محلی
روی لپتاپ یا کامپیوتر خودتان (نه روی سرور) این دستور را اجرا کنید:
ssh-keygen -t ed25519 -C "deploy@my-server"
کلید ed25519 امنتر و سریعتر از RSA است. اگر سیستمعامل قدیمی دارید که ed25519 را پشتیبانی نمیکند، از ssh-keygen -t rsa -b 4096 استفاده کنید.
کپی کلید روی سرور
ssh-copy-id deploy@your_server_ip
این دستور کلید عمومی را به فایل ~/.ssh/authorized_keys کاربر deploy اضافه میکند. اگر ssh-copy-id ندارید، بهصورت دستی:
cat ~/.ssh/id_ed25519.pub | ssh deploy@your_server_ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
سختگیری در فایل sshd_config
فایل /etc/ssh/sshd_config را ویرایش کنید:
sudo nano /etc/ssh/sshd_config
این مقادیر را تنظیم و سپس سرویس را ریستارت کنید:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
AllowUsers deploy
sudo systemctl restart sshd
نکتهی مهم: قبل از ریستارت، یک اتصال SSH دوم باز کنید و مطمئن شوید ورود با کلید کار میکند. اگر خطایی رخ داد، اتصال اول را نبندید تا بتوانید فایل را اصلاح کنید.
قدم چهارم: پیکربندی فایروال UFW (۱۰ دقیقه)
فایروال را روشن کنید و فقط پورتهای ضروری را باز بگذارید. UFW (Uncomplicated Firewall) رابط سادهای روی iptables است و برای این کار عالی است.
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable
اگر وبسرور نصب میکنید، پورتهای HTTP و HTTPS را هم باز کنید:
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
وضعیت فایروال را بررسی کنید:
sudo ufw status verbose
خروجی باید چیزی شبیه این باشد:
Status: active
To Action From
-- ------ ----
22/tcp ALLOW Anywhere
80/tcp ALLOW Anywhere
443/tcp ALLOW Anywhere
اشتباه رایج: باز کردن پورتهای اضافی «برای اینکه بعداً لازم میشود». هر پورت باز، سطح حمله را بزرگتر میکند. فقط پورتهایی را باز کنید که همین الان به آنها نیاز دارید.
قدم پنجم: نصب و پیکربندی fail2ban (۱۵ دقیقه)
fail2ban لاگهای سیستم را مانیتور میکند و IPهایی که چند بار در لاگین شکست میخورند را بهطور موقت مسدود میکند. این ابزار جلوی حملات brute-force را میگیرد.
sudo apt install fail2ban -y
فایل پیکربندی محلی بسازید:
sudo nano /etc/fail2ban/jail.local
محتوای پیشنهادی:
[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
[sshd]
enabled = true
port = ssh
logpath = /var/log/auth.log
سرویس را فعال و ریستارت کنید:
sudo systemctl enable fail2ban
sudo systemctl restart fail2ban
برای مشاهدهی IPهای مسدودشده:
sudo fail2ban-client status sshd
خروجی نمونه:
Status for the jail: sshd
|- Filter
| |- Currently failed: 2
| |- Total failed: 47
| `- File list: /var/log/auth.log
`- Actions
|- Currently banned: 3
|- Total banned: 12
`- Banned IP list: 185.220.101.34 91.240.118.87 45.155.205.233
مقدار bantime را میتوانید به 24h یا بیشتر افزایش دهید. برای سرورهای حساس، maxretry = 3 منطقیتر است.
قدم ششم: بررسی نهایی و تست (۵ دقیقه)
در پایان، یک بررسی کلی انجام دهید تا مطمئن شوید همهچیز درست کار میکند:
- از یک ترمینال دیگر، ورود با رمز عبور را تست کنید — باید رد شود.
- ورود با کلید SSH را تست کنید — باید بدون رمز کار کند.
- پورتهای باز را اسکن کنید:
sudo netstat -tulpn | grep LISTEN
فقط پورتهای ۲۲، ۸۰ و ۴۴۳ (و پورتهای سرویسهای ضروری مثل MySQL اگر روی همین سرور است) باید در حال گوش دادن باشند.
- اگر کرنل بهروز شده بود، سرور را ریبوت کنید و دوباره ورود با کلید را تست کنید.
قدم هفتم: اقدامات تکمیلی برای امنیت بیشتر
این موارد را میتوانید بعداً اضافه کنید، اما اگر زمان داشتید، همین حالا انجام دهید:
- فعالسازی unattended-upgrades: نصب خودکار بهروزرسانیهای امنیتی:
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades
- تغییر پورت SSH: اگرچه امنیت واقعی ایجاد نمیکند، اما تعداد حملات خودکار را بهشدت کاهش میدهد. پورت ۲۲ را به مثلاً ۲۲۲۲ تغییر دهید و در فایروال هم اعمال کنید.
- نصب و پیکربندی ابزارهای مانیتورینگ: مثل
logwatchبرای خلاصهی روزانهی لاگها از طریق ایمیل. - غیرفعال کردن IPv6 در فایروال: اگر از IPv6 استفاده نمیکنید، در
/etc/default/ufwمقدارIPV6=noرا تنظیم کنید تا قوانین فایروال روی IPv6 هم اعمال شوند.
جمعبندی
این چکلیست ۶۰ دقیقهای، پایهی امنیت هر سرور لینوکسی است. با حذف ورود root، فعالسازی کلید SSH، بستن پورتهای غیرضروری و نصب fail2ban، سطح حمله را بهطور چشمگیری کاهش میدهید. به یاد داشته باشید که امن سازی سرور یک فرایند مداوم است: بهروزرسانیهای منظم، بررسی لاگها و بازبینی دورهای تنظیمات را فراموش نکنید. اگر به دنبال زیرساختی هستید که این تنظیمات اولیه را سادهتر مدیریت کنید، سرویسهای سرور ابری ServerNet میتوانند نقطهی شروع مناسبی باشند — اما اصول این مقاله را در هر محیطی باید رعایت کنید.
در نهایت، یک توصیهی مهم: این تنظیمات را روی یک سرور تست هم پیادهسازی کنید تا با جریان کار آشنا شوید. اشتباه در محیط تست، هزینهی کمتری دارد تا اشتباه در محیط production.