آموزش امنیت سرور لینوکس: ترتیب درست امن‌سازی از اولین ورود

آموزش امنیت سرور از یک ترتیب ساده شروع می‌شود: اول راه ورود را ببند (SSH با کلید و بدون root)، بعد پورت‌های اضافه را با فایروال قفل کن، به‌روزرسانی را خودکار کن و در آخر بکاپی داشته باش که روز خرابی نجاتت بدهد. بیشتر نفوذها به سرورهای تازه از همین چند نقطه اتفاق می‌افتد، نه از حمله‌های پیچیده و هالیوودی. این راهنما همین ترتیب را با دستور و مسیر فایل دقیق جلو می‌برد؛ مثال‌ها روی اوبونتو و دبیان است.

سرور تازه دقیقاً با چه چیزی روبه‌روست؟

سروری که آی‌پی عمومی دارد، از همان لحظه روشن شدن توسط ربات‌ها اسکن می‌شود. اگر چند ساعت بعد از تحویل سرور فایل /var/log/auth.log را باز کنی، معمولاً پر از تلاش‌های ورود ناموفق با نام‌کاربری‌هایی مثل root، admin و test است. این ربات‌ها دنبال سه چیزند:

• رمز عبور ضعیف روی SSH، به‌خصوص برای کاربر root
• دیتابیس یا کش بدون رمز که روی اینترنت باز مانده (پورت‌های 3306، 6379، 27017)
• پنل‌ها و نرم‌افزارهای قدیمی با آسیب‌پذیری شناخته‌شده یا رمز پیش‌فرض

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

قفل کردن SSH: مهم‌ترین قدم آموزش امنیت سرور

اول یک کاربر عادی با دسترسی sudo بساز تا دیگر لازم نباشد با root کار کنی:

adduser deploy
usermod -aG sudo deploy

بعد روی لپ‌تاپ خودت (نه روی سرور) کلید بساز و کلید عمومی را به سرور بفرست:

ssh-keygen -t ed25519 -C laptop
ssh-copy-id deploy@SERVER_IP

حالا با ssh deploy@SERVER_IP وارد شو. اگر بدون پرسیدن رمز وارد شدی (یا فقط passphrase کلید را پرسید)، وقت بستن درِ رمز عبور است. اگر با SSH هنوز راحت نیستی، آموزش اتصال به سرور لینوکس با SSH را اول بخوان.

فایل /etc/ssh/sshd_config را باز کن و این خط‌ها را تنظیم کن:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

یک تله رایج این‌جاست: در اوبونتو ۲۲.۰۴ به بعد، بالای همین فایل خط Include /etc/ssh/sshd_config.d/*.conf وجود دارد و در SSH اولین مقداری که خوانده شود برنده است. اگر فایلی مثل 50-cloud-init.conf در آن پوشه PasswordAuthentication yes داشته باشد، تنظیم تو نادیده گرفته می‌شود. مقدار واقعی را این‌طور چک کن:

sudo sshd -T | grep -i passwordauthentication
sudo sshd -t
sudo systemctl restart ssh

دستور sshd -t قبل از ری‌استارت، خطای نگارشی فایل را نشان می‌دهد. اگر خروجی نداشت، فایل سالم است.

تغییر پورت 22 به عددی دیگر، لاگ‌ها را خلوت‌تر می‌کند ولی جای کلید را نمی‌گیرد. اگر عوضش کردی، یادت باشد در اوبونتو ۲۴.۰۴ که SSH با socket activation بالا می‌آید، بعد از ویرایش فایل باید sudo systemctl daemon-reload و sudo systemctl restart ssh.socket را بزنی و پورت جدید را قبلش در فایروال باز کنی.

فایروال: فقط چیزی باز باشد که واقعاً لازم است

قبل از نوشتن هر قانونی، ببین چه چیزی روی سرور گوش می‌دهد:

sudo ss -tulpn

هر خطی که آدرسش 0.0.0.0 یا [::] است، از بیرون قابل دسترسی است مگر فایروال جلویش را بگیرد. حالا ufw را با سیاست «همه بسته، جز موارد لازم» راه بینداز:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

ترتیب مهم است: allow OpenSSH حتماً قبل از enable بیاید. اگر آی‌پی ثابت داری، می‌توانی SSH را فقط برای خودت باز کنی: sudo ufw allow from 1.2.3.4 to any port 22 proto tcp.

به‌روزرسانی خودکار و fail2ban

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

sudo apt update && sudo apt upgrade -y
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

تنظیمات جزئی‌تر در /etc/apt/apt.conf.d/50unattended-upgrades است. بعضی به‌روزرسانی‌ها (مثل کرنل) تا ری‌استارت اعمال نمی‌شوند؛ اگر فایل /var/run/reboot-required وجود داشت، یعنی سرور منتظر ری‌استارت است.

حالا fail2ban که آی‌پی‌های پرتلاش را موقتاً مسدود می‌کند:

sudo apt install fail2ban

فایل /etc/fail2ban/jail.local را بساز (فایل jail.conf را دست نزن، با به‌روزرسانی بازنویسی می‌شود):

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

روی دبیان ۱۲ که به‌طور پیش‌فرض rsyslog و فایل auth.log ندارد، خط backend = systemd را هم به همین بخش اضافه کن، وگرنه سرویس بالا نمی‌آید. بعد از sudo systemctl restart fail2ban، وضعیت را با sudo fail2ban-client status sshd ببین. وقتی ورود با رمز را بسته‌ای، fail2ban بیشتر لاگ را تمیز نگه می‌دارد تا اینکه جلوی نفوذ را بگیرد؛ ولی برای nginx و سرویس‌های دیگر هم jail دارد و همان‌جا ارزشش بیشتر می‌شود.

سرویس‌ها و اپلیکیشن: جایی که بیشتر نشت‌ها رخ می‌دهد

فایروال خط دفاع دوم است؛ خط اول این است که سرویس داخلی اصلاً روی اینترنت گوش ندهد.

• MySQL: در /etc/mysql/mysql.conf.d/mysqld.cnf مقدار bind-address = 127.0.0.1 را بگذار. روی MariaDB فایل معمولاً /etc/mysql/mariadb.conf.d/50-server.cnf است.
• Redis: در /etc/redis/redis.conf خط bind 127.0.0.1 -::1 و protected-mode yes را نگه دار و برای اطمینان requirepass هم تعریف کن.
• nginx: در بلوک http فایل /etc/nginx/nginx.conf بنویس server_tokens off; تا نسخه در هدرها لو نرود، و با sudo certbot --nginx گواهی TLS بگیر. جزئیات نصب و پیکربندی در آموزش نصب وب سرور nginx آمده.
• اپلیکیشن خودت: با کاربر جداگانه اجرا شود، نه root. اگر نفوذی به اپ برسد، دسترسی مهاجم به همان کاربر محدود می‌ماند.
• پنل‌های مدیریتی (phpMyAdmin، پنل داکر و مانند آن): یا پشت VPN و تونل SSH باشند یا اصلاً نصب نشوند.

بعد از هر تغییر، دوباره sudo ss -tulpn را بزن. هدف این است که جز SSH و وب، هیچ چیزی روی 0.0.0.0 نمانده باشد.

لاگ، پایش و بکاپ برای روزی که چیزی شکست خورد

امنیت یعنی فرض کنی روزی یکی از لایه‌ها کم می‌آورد. برای اینکه بفهمی چه شده، چند دستور را بلد باش:

sudo journalctl -u ssh --since today
last -n 20
sudo lastb | head
sudo grep 'Accepted' /var/log/auth.log

خط‌های Accepted ورودهای موفق‌اند. اگر ورودی از آی‌پی ناآشنا دیدی، معمولاً یعنی کلید یا رمزی لو رفته و باید فوراً کلیدها را عوض کنی.

بکاپ را این‌طور ببین: نسخه‌ای که روی همان سرور است بکاپ نیست، چون با همان نفوذ یا خرابی دیسک از بین می‌رود. قاعده ۳-۲-۱ را رعایت کن: سه نسخه، روی دو نوع ذخیره‌ساز، یکی بیرون از سرور. و مهم‌تر از گرفتن بکاپ، تست بازگردانی آن است؛ بکاپی که هیچ‌وقت بازیابی نشده، فقط یک فرض است.

اگر نفوذ قطعی شد، سعی نکن سرور را «تمیز» کنی. مهاجم ممکن است در cron، کلیدهای ~/.ssh/authorized_keys یا سرویس‌های systemd ردپا گذاشته باشد. سرور تازه بساز، امن‌سازی را تکرار کن و داده را از بکاپ سالم برگردان.

تمرین آموزش امنیت سرور روی سرور ساعتی

بدترین جا برای یاد گرفتن امن‌سازی، سرور اصلی است؛ یک خط اشتباه در sshd_config یا فراموش کردن allow OpenSSH کافی است تا خودت را بیرون بیندازی. روش امن‌تر این است که یک سرور ساعتی بسازی، کل مراحل بالا را رویش اجرا کنی، عمداً اشتباه کنی، ببینی چطور برمی‌گردی و بعد حذفش کنی. در پاسارگاد میزبان این سرور با کیف پول تومانی و پرداخت ساعتی ساخته می‌شود و فقط برای همان چند ساعت تمرین هزینه می‌دهی؛ نرخ‌ها را در قیمت سرورهای ساعتی ببین. اگر آی‌پی سرور از ایران باز نشد، راهنمای تعویض آی‌پی فیلترشده را بخوان.

بعد از تمرین، این فهرست را روی سرور واقعی مرور کن:

برای نسخه گام‌به‌گام و فشرده‌تر روی اوبونتو، امن‌سازی سرور اوبونتو در ۱۰ قدم را هم داشته باش.

جمع‌بندی

امنیت سرور با یک ترتیب ثابت قابل مدیریت است: کاربر sudo و کلید SSH، بستن root و رمز عبور، فایروال با حداقل پورت، به‌روزرسانی خودکار، محدود کردن سرویس‌ها به localhost و بکاپ بیرون از سرور. این‌ها را یک بار روی سروری تمرین کن که خراب شدنش اهمیتی ندارد، تا روی سرور اصلی بدون ترس و با یک چک‌لیست اجرا شوند؛ برای شروع می‌توانی از ساخت سرور ساعتی ایران و خارج استفاده کنی و بعد از تمرین حذفش کنی.