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

۳ اصل ضروری امنیت سرور لینوکس | پادکست

امنیت سرور، به ویژه در محیط لینوکس، یک رویداد واحد نیست، بلکه یک فرآیند مستمر و چندلایه است. این بخش به اصول اساسی و اولین گام‌های حیاتی می‌پردازد که هر مدیر سیستم، صرف نظر از سطح تجربه، باید بلافاصله پس از راه‌اندازی یک سرور جدید اجرا کند.

بخش ۱: پایه‌های امنیت سرور (سطح پایه)

۱.۱. اصول کلیدی امنیت: دفاع چندلایه

امنیت سرور به مجموعه‌ای از فرآیندها، ابزارها و سیاست‌ها اطلاق می‌شود که با هدف محافظت از داده‌ها و خدمات سرور در برابر دسترسی‌های غیرمجاز، نشت اطلاعات و انواع تهدیدات امنیتی به کار گرفته می‌شوند. موفق‌ترین استراتژی‌های امنیتی بر پایه مدل «دفاع چندلایه» (Defense in Depth) بنا شده‌اند. این مدل فرض می‌کند که هیچ لایه امنیتی واحدی به تنهایی کافی نیست و امنیت باید در سطوح مختلف پیاده‌سازی شود.   

این لایه‌ها عبارتند از:

• امنیت فیزیکی: اولین و اساسی‌ترین لایه. این شامل محافظت از تجهیزات و سرورها در برابر دسترسی فیزیکی غیرمجاز از طریق قفل‌ها، اتاق‌های سرور امن، دوربین‌های نظارتی و سیستم‌های کنترل دسترسی است.   
• امنیت شبکه: این لایه بر محافظت از سرور در برابر حملات آنلاین، ویروس‌ها و سوءاستفاده‌های شبکه‌ای تمرکز دارد. ابزارهای کلیدی در این لایه شامل فایروال‌ها (که در بخش ۲ به تفصیل بررسی می‌شوند)، شبکه‌های خصوصی مجازی (VPN) برای رمزنگاری ارتباطات از راه دور  و سیستم‌های تشخیص و پیشگیری از نفوذ (IDS/IPS) هستند.   
• امنیت سیستم‌عامل (OS): این لایه به حفاظت از اجزای حیاتی و خدمات کلیدی خود سرور می‌پردازد. این شامل سخت‌سازی سیستم‌عامل، مدیریت وصله‌های امنیتی و بروزرسانی‌ها، و کنترل دقیق دسترسی‌ها است که هسته اصلی این راهنما را تشکیل می‌دهد.   
• امنیت برنامه: این لایه بر کنترل محتوا و خدماتی که روی سرور میزبانی می‌شوند (مانند وب سرور یا پایگاه داده) تمرکز دارد.   

زیربنای تمام این لایه‌ها، «اصل حداقل دسترسی» (Principle of Least Privilege) است. این اصل حیاتی حکم می‌کند که هر کاربر، فرآیند یا برنامه باید فقط به حداقل منابعی دسترسی داشته باشد که برای انجام وظیفه محوله‌اش مطلقاً ضروری است و نه بیشتر.

۱.۲. مدیریت کاربران و دسترسی‌ها: اولین گام حیاتی از راهنمای امنیت سرور لینوکس

پس از راه‌اندازی سرور، اولین اقدام امنیتی باید پیکربندی دسترسی کاربران باشد. استفاده مستقیم از کاربر root (کاربر سوپرادمین در لینوکس) یکی از بزرگترین خطرات امنیتی است.

چرا هرگز نباید مستقیماً با Root وارد شوید؟ کاربر root دارای دسترسی نامحدود به تمام بخش‌های سیستم است. مهم‌تر از آن، نام کاربری root یک هدف شناخته‌شده و جهانی برای تمام مهاجمان است. حملات خودکار (Brute-Force) به طور مداوم تلاش می‌کنند تا با حدس زدن رمز عبور کاربر root به سرورها نفوذ کنند. با غیرفعال کردن ورود مستقیم root ، شما سطح حمله را به طور چشمگیری کاهش می‌دهید. مهاجم اکنون باید دو چیز را حدس بزند: نام کاربری سفارشی شما و رمز عبور آن.   

آموزش عملی: ایجاد کاربر Sudo رویه صحیح، ایجاد یک حساب کاربری استاندارد و اعطای امتیازات مدیریتی به آن از طریق ابزار sudo است.   

• در توزیع‌های مبتنی بر Debian/Ubuntu:
  1. به عنوان root وارد شوید.
  2. یک کاربر جدید ایجاد کنید (جایگزین <username> شوید):Bashadduser <username>
  3. این کاربر را به گروه sudo اضافه کنید تا امتیازات مدیریتی دریافت کند:Bashusermod -a -G sudo <username>    
• در توزیع‌های مبتنی بر RHEL/CentOS:
  1. به عنوان root وارد شوید.
  2. یک کاربر جدید ایجاد کنید:Bashadduser <username>
  3. برای کاربر جدید رمز عبور تنظیم کنید:Bashpasswd <username>
  4. این کاربر را به گروه wheel اضافه کنید (گروه wheel در RHEL/CentOS معادل گروه sudo است):Bashusermod -a -G wheel <username>

پس از انجام این مراحل، از حساب root خارج شوید و همیشه با کاربر جدید خود وارد شوید. هر زمان که به امتیازات مدیریتی نیاز داشتید، کافی است قبل از دستور خود sudo را اضافه کنید.

۱.۳. سخت‌سازی دسترسی از راه دور (SSH Hardening)

پروتکل SSH (Secure Shell) کانال اصلی و امن برای مدیریت سرورهای لینوکس از راه دور است. این پروتکل تمام ارتباطات بین شما و سرور را رمزنگاری می‌کند و جایگزین پروتکل‌های ناامن و منسوخ‌شده‌ای مانند Telnet است که داده‌ها را به صورت متن ساده (Clear Text) منتقل می‌کردند.   

امن‌سازی SSH مهم‌ترین گام پس از ایجاد کاربر sudo است. ما این کار را با جایگزin کردن کامل احراز هویت مبتنی بر رمز عبور با احراز هویت مبتنی بر کلید عمومی انجام خواهیم داد.

آموزش عملی (گام ۱): ایجاد جفت کلید SSH (در کامپیوتر محلی شما) احراز هویت با کلید SSH از یک جفت کلید رمزنگاری استفاده می‌کند: یک کلید عمومی (Public Key) که روی سرور قرار می‌گیرد و یک کلید خصوصی (Private Key) که به صورت محرمانه روی کامپیوتر شما باقی می‌ماند.

1. در ترمینال کامپیوتر محلی خود (نه سرور)، دستور ssh-keygen را اجرا کنید.
2. توصیه می‌شود از الگوریتم‌های مدرن و قوی استفاده کنید:
   • روش مدرن (توصیه شده):Bashssh-keygen -t ed25519 -C "your_email@example.com"    
   • روش سازگار و قوی:Bashssh-keygen -t rsa -b 4096 -C "your_email@example.com"  (یک کلید RSA 2048 بیتی به تنهایی معادل یک رمز عبور ۶۱۷ رقمی است ).   
3. این دستور از شما مسیری برای ذخیره کلیدها می‌پرسد (پیش‌فرض معمولاً ~/.ssh/id_rsa یا ~/.ssh/id_ed25519 است) و یک “عبارت عبور” (passphrase). وارد کردن passphrase اختیاری است اما به شدت توصیه می‌شود؛ این کار کلید خصوصی شما را رمزنگاری می‌کند، به طوری که حتی اگر فایل کلید خصوصی به سرقت برود، بدون این عبارت عبور قابل استفاده نخواهد بود.

آموزش عملی (گام ۲): کپی کردن کلید عمومی به سرور اکنون باید کلید عمومی (.pub) را به سرور منتقل کنید تا سرور بتواند شما را بشناسد.

• روش توصیه شده (Linux/macOS): از ابزار ssh-copy-id استفاده کنید. این ابزار به طور خودکار کلید را در فایل ~/.ssh/authorized_keys روی سرور قرار می‌دهد و مهم‌تر از آن، مجوزهای (permissions) صحیح فایل و پوشه را تنظیم می‌کند.   Bashssh-copy-id <username>@<server_ip_address>
• روش دستی (Windows یا اگر ssh-copy-id در دسترس نیست):Bashcat ~/.ssh/id_ed25519.pub | ssh <username>@<server_ip_address> "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"    

آموزش عملی (گام ۳): غیرفعال کردن احراز هویت با رمز عبور (گام نهایی) این گام، درب ورودی را برای حملات brute-force برای همیشه می‌بندد.

هشدار حیاتی: قبل از اجرای این گام، حتماً یک بار از سرور خارج شوید و دوباره با استفاده از کلید SSH خود وارد شوید تا مطمئن شوید که ورود مبتنی بر کلید به درستی کار می‌کند. اگر این کار را نکنید و کلید شما به درستی تنظیم نشده باشد، خود را از سرور قفل خواهید کرد.   

1. با کلید SSH خود به سرور وارد شوید و فایل پیکربندی SSH daemon را باز کنید:Bashsudo nano /etc/ssh/sshd_config    
2. دو خط زیر را در این فایل پیدا کنید، آنها را از حالت کامنت خارج کنید (علامت # را بردارید) و مقادیر آنها را تغییر دهید:Ini, TOML# تغییر دهید 'yes' به 'no' PasswordAuthentication no # همچنین ورود مستقیم root را غیرفعال کنید PermitRootLogin no    
3. فایل را ذخیره کرده و خارج شوید.
4. سرویس SSH را مجدداً راه‌اندازی کنید تا تغییرات اعمال شوند:Bashsudo systemctl restart sshd  (در برخی سیستم‌ها ممکن است sshd.service باشد).   

اکنون، سرور شما فقط اتصالات مبتنی بر کلید SSH را می‌پذیرد. این یک تغییر پارادایم در امنیت است. شما مدل حمله را از «حدس زدن یک راز» (Brute-forcing a password) که می‌تواند از هر نقطه‌ای در اینترنت به صورت خودکار انجام شود، به «سرقت یک دارایی فیزیکی» (سرقت فایل کلید خصوصی شما از کامپیوترتان) تغییر داده‌اید. این امر به طور چشمگیری امنیت ورود به سرور را افزایش می‌دهد.

بخش ۲: پیکربندی دفاع محیطی (فایروال‌های لینوکس)

در بخش دوم راهنمای امنیت سرور لینوکس ، پس از ایمن‌سازی درب ورودی (SSH)، گام بعدی ساختن یک دیوار دفاعی در اطراف سرور است. فایروال به عنوان اولین خط دفاعی شبکه عمل می‌کند و نقش حیاتی در فیلتر کردن ترافیک ورودی و جلوگیری از دسترسی‌های غیرمجاز دارد. در اکوسیستم لینوکس، چندین ابزار محبوب برای مدیریت فایروال مبتنی بر هسته (Netfilter/iptables) وجود دارد.   

۲.۱. انتخاب فایروال مناسب: UFW در مقابل FirewallD در مقابل iptables

• iptables: ابزار فایروال کلاسیک، بسیار قدرتمند و انعطاف‌پذیر لینوکس است. این ابزار مستقیماً با زیرسیستم Netfilter هسته کار می‌کند و امکان تعریف قوانین بسیار پیچیده و دقیق را از طریق «جداول» (Tables) و «زنجیره‌ها» (Chains) فراهم می‌کند. با این حال، سینتکس آن پیچیده است  و مدیریت آن برای مبتدیان دشوار است.   
• UFW (Uncomplicated Firewall): یک رابط کاربری (frontend) ساده و کاربرپسند برای iptables است که به صورت پیش‌فرض در اوبونتو گنجانده شده است. هدف UFW ساده‌سازی فرآیند تنظیم فایروال با دستورات قابل فهم است.   
• FirewallD (Firewall Dynamic): فایروال پیش‌فرض در توزیع‌های مدرن مبتنی بر RHEL (مانند CentOS 7+، Fedora) است. FirewallD از iptables (و اخیراً nftables) در پس‌زمینه استفاده می‌کند اما یک مدل مدیریتی متفاوت مبتنی بر «نواحی» (Zones) و «سرویس‌ها» (Services) ارائه می‌دهد. این مدل برای مدیریت شبکه‌های پیچیده (مثلاً سرورهایی با چندین رابط شبکه در سطوح اعتماد مختلف) بسیار کارآمد است.   

جدول ۱: مقایسه فایروال‌های لینوکس

۲.۲. راهنمای عملی UFW (Uncomplicated Firewall) برای اوبونتو

UFW طوری طراحی شده است که استفاده از آن آسان باشد و در عین حال امنیت پیش‌فرض قوی را فراهم کند.   

گام ۱: نصب و بررسی وضعیت UFW معمولاً به صورت پیش‌فرض روی اوبونتو نصب است. اگر نه، آن را نصب کنید:   

Bash

sudo apt update
sudo apt install ufw

برای بررسی وضعیت فعلی:

Bash

sudo ufw status verbose

 (به احتمال زیاد «غیرفعال» یا inactive است).   

گام ۲: تنظیم سیاست‌های پیش‌فرض (Default Policies) این مهم‌ترین گام است. ما همه چیز را به صورت پیش‌فرض مسدود می‌کنیم و سپس فقط موارد ضروری را باز می‌کنیم (اصل حداقل دسترسی).

Bash

sudo ufw default deny incoming
sudo ufw default allow outgoing

این تنظیمات تمام اتصالات ورودی را مسدود کرده و به سرور اجازه می‌دهد آزادانه به اینترنت (مثلاً برای بروزرسانی‌ها) دسترسی داشته باشد.

گام ۳: باز کردن پورت‌های حیاتی هشدار حیاتی: قبل از فعال کردن فایروال، باید دسترسی SSH را مجاز کنید، در غیر این صورت ارتباط شما با سرور قطع خواهد شد.

Bash

# با استفاده از نام سرویس (توصیه شده)
sudo ufw allow ssh

# یا با شماره پورت
sudo ufw allow 22/tcp

اگر این سرور یک وب سرور است، پورت‌های HTTP و HTTPS را نیز باز کنید:

Bash

sudo ufw allow http
sudo ufw allow https

 (این معادل allow 80/tcp و allow 443/tcp است).   

گام ۴: فعال کردن فایروال پس از اینکه مطمئن شدید قوانین لازم (به خصوص SSH) اضافه شده‌اند، فایروال را فعال کنید:

Bash

sudo ufw enable

مدیریت پیشرفته (اختیاری):

• مسدود کردن یک IP یا رنج:Bashsudo ufw deny from 23.24.25.0/24    
• اجازه به IP خاص برای پورت خاص (بسیار امن):Bashsudo ufw allow from 203.0.113.4 to any port 22    
• حذف قوانین:Bashsudo ufw delete allow http    یا با استفاده از شماره (ابتدا sudo ufw status numbered را اجرا کنید):Bashsudo ufw delete 2    
• غیرفعال کردن یا ریست:Bashsudo ufw disable sudo ufw reset    

۲.۳. راهنمای عملی FirewallD برای CentOS/RHEL

FirewallD از مفهوم «نواحی» (Zones) برای مدیریت قوانین استفاده می‌کند. یک ناحیه، مجموعه‌ای از قوانین است که بر اساس سطح اعتمادی که به شبکه‌ای که به آن متصل هستید، تعریف می‌شود. ناحیه پیش‌فرض معمولاً public است.   

گام ۱: فعال‌سازی و بررسی وضعیت

Bash

# شروع سرویس
sudo systemctl start firewalld
# فعال‌سازی در هنگام بوت
sudo systemctl enable firewalld
# بررسی وضعیت
sudo firewall-cmd --state

گام ۲: مدیریت ناحیه‌ها (Zones)

Bash

# مشاهده ناحیه پیش‌فرض
firewall-cmd --get-default-zone
# مشاهده ناحیه‌های فعال و رابط‌های شبکه‌ای که به آنها اختصاص داده شده‌اند
firewall-cmd --get-active-zones

گام ۳: افزودن سرویس‌ها و پورت‌ها (به صورت دائمی) تغییرات در FirewallD می‌توانند موقتی یا دائمی باشند. برای اینکه تغییرات پس از ریبوت باقی بمانند، باید از پرچم --permanent استفاده کنید.

• باز کردن SSH: (معمولاً به طور پیش‌فرض در ناحیه public مجاز است)Bashsudo firewall-cmd --zone=public --add-service=ssh --permanent    
• باز کردن وب سرور:Bashsudo firewall-cmd --zone=public --add-service=http --permanent sudo firewall-cmd --zone=public --add-service=https --permanent    
• باز کردن یک پورت سفارشی (مثلاً برای یک برنامه):Bashsudo firewall-cmd --zone=public --add-port=8080/tcp --permanent

گام ۴: اعمال تغییرات پس از افزودن یا حذف قوانین با پرچم --permanent، باید فایروال را مجدداً بارگذاری (reload) کنید تا تغییرات اعمال شوند:

Bash

sudo firewall-cmd --reload

۲.۴. مروری بر iptables (برای متخصصان)

iptables ابزار پایه‌ای و بسیار قدرتمندی است که کنترل دقیق بر هر بسته (packet) شبکه را فراهم می‌کند.

• ساختار: iptables از جداول (Tables) مانند filter (اصلی)، nat و mangle تشکیل شده است. هر جدول شامل زنجیره‌های (Chains) از پیش تعریف‌شده مانند INPUT (بسته‌های ورودی به سرور)، OUTPUT (بسته‌های خروجی از سرور) و FORWARD (بسته‌هایی که مسیریابی می‌شوند) است.   
• مثال‌های کاربردی:
  • تنظیم سیاست پیش‌فرض (مهم): ابتدا همه چیز را مسدود کنید.Bashsudo iptables -P INPUT DROP    
  • هشدار: قبل از اجرای دستور بالا، باید اتصالات موجود و SSH را مجاز کنید، در غیر این صورت ارتباط شما فوراً قطع می‌شود.
  • اجازه به اتصالات قبلاً برقرار شده (بسیار مهم):Bashsudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
  • اجازه به رابط Loopback:Bashsudo iptables -A INPUT -i lo -j ACCEPT    
  • باز کردن SSH (پورت ۲۲):Bashsudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT    
  • مسدود کردن یک آدرس IP مزاحم:Bashsudo iptables -A INPUT -s 192.168.1.100 -j DROP    
• ذخیره قوانین: قوانین iptables به طور پیش‌فرض پس از ریبوت پاک می‌شوند. شما باید آنها را ذخیره کنید:
  • Bashsudo iptables-save > /etc/iptables/rules.v4    
  • و برای بازیابی آنها در زمان بوت (که روش آن بسته به توزیع متفاوت است) یا به صورت دستی:
  • Bashsudo iptables-restore < /etc/iptables/rules.v4    

۲.۵. دفاع فعال: مسدود کردن مهاجمان با Fail2Ban

فایروال شما (مانند UFW) پورت SSH را باز نگه می‌دارد، اما این به مهاجمان اجازه می‌دهد تا حملات Brute-Force (آزمون و خطای مکرر رمز عبور) را روی آن اجرا کنند. Fail2Ban یک ابزار دفاعی پویا است که این مشکل را حل می‌کند.   

• مفهوم: Fail2Ban فایل‌های لاگ سرور شما (مانند /var/log/auth.log) را به صورت زنده مانیتور می‌کند. اگر یک آدرس IP خاص را ببیند که به طور مکرر در ورود ناموفق است (مثلاً ۵ بار در ۱۰ دقیقه)، به طور خودکار یک قانون به فایروال سیستم (iptables) اضافه می‌کند تا آن IP را برای مدت زمان مشخصی مسدود کند.   
• آموزش (گام ۱): نصب
  • در Debian/Ubuntu:Bashsudo apt update && sudo apt install fail2ban    
  • در CentOS/RHEL (نیاز به مخزن EPEL دارد):Bashsudo yum install epel-release sudo yum install fail2ban    
• آموزش (گام ۲): پیکربندی jail.local
  • اصل حیاتی: هرگز فایل jail.conf را مستقیماً ویرایش نکنید، زیرا در بروزرسانی‌های بعدی بازنویسی می‌شود. همیشه یک فایل jail.local برای تغییرات خود ایجاد کنید.   
  • Bashsudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
  • فایل جدید را باز کنید:
  • Bashsudo nano /etc/fail2ban/jail.local
• آموزش (گام ۳): فعال‌سازی Jail برای SSH
  • در فایل jail.local، به بخش “ بروید و می‌توانید تنظیمات پیش‌فرض مانند bantime (مدت زمان مسدودیت) و maxretry (تعداد تلاش‌های ناموفق) را تغییر دهید.   
  • سپس، بخش مربوط به سرویس مورد نظر خود، مثلاً [sshd]، را پیدا کنید و مطمئن شوید که فعال است:
  • Ini, TOML[sshd] enabled = true port = ssh # می‌توانید maxretry و bantime را به صورت خاص برای این jail بازنویسی کنید maxretry = 5 bantime = 3600s    
• آموزش (گام ۴): راه‌اندازی سرویسBashsudo systemctl start fail2ban sudo systemctl enable fail2ban    
• بررسی وضعیت:
  • برای بررسی لاگ‌ها: sudo nano /var/log/fail2ban.log    
  • برای دیدن وضعیت jail مربوط به SSH (شامل لیست IP‌های مسدود شده): sudo fail2ban-client status sshd

ترکیب یک فایروال ایستا (UFW/FirewallD) که پورت‌ها را می‌بندد و یک فایروال پویا (Fail2Ban) که به رفتارها واکنش نشان می‌دهد، یک دفاع محیطی بسیار قوی ایجاد می‌کند.

بخش ۳: نگهداری، نظارت و یکپارچگی سیستم (سطح متوسط)

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

۳.۱. مدیریت بروزرسانی سیستم‌عامل

یکی از اساسی‌ترین و در عین حال مؤثرترین استراتژی‌های امنیتی، بروز نگه داشتن سیستم است. توسعه‌دهندگان توزیع‌های لینوکس به طور مداوم آسیب‌پذیری‌های امنیتی را کشف و رفع می‌کنند. اعمال منظم این وصله‌ها (Patches) سرور شما را در برابر تهدیدات شناخته‌شده محافظت می‌کند.   

• بروزرسانی دستی:
  • در Debian/Ubuntu:Bashsudo apt update && sudo apt upgrade    
  • در RHEL/CentOS:Bashsudo dnf upgrade  (یا yum update در نسخه‌های قدیمی‌تر)   
• اتوماسیون: راه‌اندازی unattended-upgrades (اوبونتو) مدیریت دستی بروزرسانی‌ها، به ویژه برای وصله‌های امنیتی حیاتی، می‌تواند مستعد خطا و تأخیر باشد. ابزار unattended-upgrades این فرآیند را برای بسته‌های امنیتی خودکار می‌کند.   
• گام ۱: نصبBashsudo apt install unattended-upgrades apt-listchanges  (apt-listchanges تغییرات را قبل از نصب به شما ایمیل می‌کند).   
• گام ۲: فعال‌سازی اولیه این دستور یک فایل پیکربندی اولیه ایجاد می‌کند و شما را برای فعال‌سازی راهنمایی می‌کند:Bashsudo dpkg-reconfigure -plow unattended-upgrades  (در پنجره‌ای که باز می‌شود، ‘Yes’ را انتخاب کنید).   
• گام ۳: پیکربندی دقیق فایل اصلی پیکربندی در 50unattended-upgrades قرار دارد:Bashsudo nano /etc/apt/apt.conf.d/50unattended-upgrades    در این فایل، مطمئن شوید که خطوط مربوط به بروزرسانی‌های امنیتی فعال هستند (از حالت کامنت خارج شده‌اند)، مانند:Unattended-Upgrade::Origins-Pattern { "origin=Ubuntu,suite=${distro_codename}-security"; }; تنظیمات مهم (اختیاری):
  • دریافت هشدار ایمیلی:Unattended-Upgrade::Mail "sysadmin@example.com";    
  • ریبوت خودکار (برای آپدیت‌های کرنل):Unattended-Upgrade::Automatic-Reboot "true"; Unattended-Upgrade::Automatic-Reboot-Time "02:00";    
• گام ۴: اجرای آزمایشی (Dry Run) برای تست پیکربندی بدون اعمال تغییرات واقعی:Bashsudo unattended-upgrades --dry-run    

۳.۲. نظارت بر یکپارچگی فایل (FIM) با AIDE

چگونه می‌فهمید که آیا یک مهاجم موفق به نفوذ به سرور شما شده و فایل‌های سیستمی حیاتی (مانند /bin/bash یا /etc/passwd) را تغییر داده است؟ اینجا است که سیستم نظارت بر یکپارچگی فایل (FIM) وارد می‌شود. AIDE (Advanced Intrusion Detection Environment) یک ابزار استاندارد صنعتی برای این کار است.   

• مفهوم: AIDE یک «پایگاه داده» (Baseline) از وضعیت فعلی سیستم شما ایجاد می‌کند. این پایگاه داده شامل هش‌های رمزنگاری (مانند SHA256) و ویژگی‌های (مانند مجوزها، مالک) تمام فایل‌های مهم است. با اجرای دوره‌ای AIDE و مقایسه وضعیت فعلی با پایگاه داده، هرگونه تغییر غیرمجاز فوراً شناسایی می‌شود.   
• گام ۱: نصب
  • در Debian/Ubuntu: sudo apt install aide    
  • در RHEL/CentOS: sudo yum install aide    
• گام ۲: ایجاد پایگاه داده اولیه (Baseline) هشدار: این گام باید روی یک سیستم «تمیز» و تازه نصب شده اجرا شود.Bashsudo aide --init    این فرآیند ممکن است زمان زیادی طول بکشد. پس از اتمام، یک فایل پایگاه داده جدید در /var/lib/aide/aide.db.new.gz ایجاد می‌شود.
• گام ۳: فعال‌سازی پایگاه داده پایگاه داده جدید را به عنوان پایگاه داده فعال تغییر نام دهید:Bashsudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz    
• گام ۴: بررسی یکپارچگی برای اسکن سیستم و مقایسه با پایگاه داده:Bashsudo aide --check    اگر هیچ خروجی وجود نداشته باشد (یا پیام “Everything is OK” )، سیستم شما تمیز است. هرگونه خروجی نشان‌دهنده تغییراتی است که باید فوراً بررسی شوند.   
• گام ۵: بروزرسانی پایگاه داده (پس از تغییرات مجاز) پس از انجام تغییرات قانونی (مانند apt upgrade)، پایگاه داده قدیمی دیگر معتبر نیست. شما باید یک پایگاه داده جدید ایجاد کنید:Bashsudo aide --update    این دوباره یک فایل aide.db.new.gz ایجاد می‌کند که باید جایگزین فایل aide.db.gz قدیمی شود.
• اتوماسیون: AIDE باید به صورت دوره‌ای (مثلاً روزانه در ساعت ۴:۰۵ صبح) از طریق cron اجرا شود تا گزارش‌های منظمی از وضعیت یکپارچگی سیستم ارائه دهد.   

۳.۳. حسابرسی و تجزیه و تحلیل لاگ‌ها

سرورها مقادیر عظیمی از داده‌های لاگ را تولید می‌کنند. بررسی دستی این لاگ‌ها غیرممکن است. ما به ابزارهایی برای خلاصه‌سازی و حسابرسی دقیق نیاز داریم.   

• Logwatch: خلاصه‌ساز لاگ‌ها
  • مفهوم: Logwatch ابزاری است که لاگ‌های حجیم سیستم را در دایرکتوری /var/log تجزیه و تحلیل کرده و یک خلاصه گزارش روزانه از فعالیت‌های کلیدی (مانند تلاش‌های ورود، فعالیت فایروال، خطاهای دیسک) ایجاد می‌کند و می‌تواند آن را برای مدیر سیستم ایمیل کند.   
  • نصب:
    • RHEL/CentOS: sudo yum -y install logwatch    
    • Debian/Ubuntu: sudo apt install logwatch    
  • پیکربندی: فایل پیکربندی پیش‌فرض در /usr/share/logwatch/default.conf است. برای سفارشی‌سازی، یک فایل در /etc/logwatch/conf/logwatch.conf ایجاد کنید.   
  • تنظیمات کلیدی (در logwatch.conf):Ini, TOML# ایمیلی که گزارش به آن ارسال می‌شود MailTo = your-email@example.com # فرمت گزارش (html یا text) Format = html # سطح جزئیات (Low, Med, High) Detail = Med    
  • Logwatch به طور خودکار طوری تنظیم می‌شود که روزانه از طریق cron.daily اجرا شود.   
• Auditd: حسابرس دقیق سیستم
  • مفهوم: در حالی که Logwatch یک دید کلی ارائه می‌دهد، Linux Audit Daemon (auditd) یک ابزار حسابرسی بسیار دقیق و سطح کرنل است. این ابزار می‌تواند هر رویدادی در سیستم را ردیابی کند، از جمله هر فراخوانی سیستمی (syscall)، دسترسی به فایل، یا تغییر در پیکربندی.   
  • کاربرد: auditd برای پاسخ به سؤالات امنیتی بسیار خاص استفاده می‌شود، مانند: “چه کسی و در چه زمانی فایل /etc/shadow را خواند؟”
  • پیکربندی: فایل‌های پیکربندی اصلی در /etc/audit/ قرار دارند (مانند auditd.conf و audit.rules).   
  • ابزارهای کلیدی:
    • ausearch: ابزاری قدرتمند برای جستجو در لاگ‌های حجیم حسابرسی.   
    • aureport: برای ایجاد گزارش‌های خلاصه از رویدادهای ثبت‌شده (مانند گزارش تمام ورودهای ناموفق).   

این سه ابزار (بروزرسانی، AIDE، و Logwatch/Auditd) یک چرخه امنیتی سه‌گانه ایجاد می‌کنند. unattended-upgrades یک ابزار پیشگیرانه (آینده‌نگر) است که از حملات شناخته‌شده جلوگیری می‌کند. AIDE یک ابزار تشخیصی (زمان حال) است که در لحظه وقوع یک تغییر غیرمجاز، به شما هشدار می‌دهد. Logwatch و auditd ابزارهای بازبینی (گذشته‌نگر) هستند که به شما کمک می‌کنند بفهمید چه اتفاقی افتاده است.

بخش ۴: سخت‌سازی پیشرفته هسته و سیستم‌عامل (سطح تخصصی)

این بخش به تنظیمات پیشرفته‌ای می‌پردازد که فراتر از پیکربندی‌های اولیه هستند و برای مدیران سیستم حرفه‌ای که به دنبال به حداکثر رساندن امنیت در سطح سیستم‌عامل و هسته (Kernel) هستند، طراحی شده است.

۴.۱. سخت‌سازی پارامترهای هسته (Kernel) با sysctl.conf

sysctl یک رابط در لینوکس است که به مدیران اجازه می‌دهد پارامترهای هسته (Kernel) را در زمان اجرا (runtime) مشاهده و تغییر دهند. این پارامترها جنبه‌های مختلفی از جمله عملکرد شبکه، مدیریت حافظه و امنیت را کنترل می‌کنند.   

• پیکربندی دائمی: برای اینکه تغییرات پس از ریبوت باقی بمانند، نباید مستقیماً در /proc/sys نوشته شوند، بلکه باید در فایل /etc/sysctl.conf یا فایل‌های جداگانه در /etc/sysctl.d/ اضافه شوند.   
• اعمال تغییرات: پس از ویرایش فایل sysctl.conf، دستور زیر را اجرا کنید تا تغییرات بدون نیاز به ریبوت اعمال شوند:Bashsudo sysctl -p    

جدول ۳: پارامترهای کلیدی sysctl.conf برای سخت‌سازی شبکه این تنظیمات به محافظت از پشته شبکه هسته در برابر حملات رایج کمک می‌کنند.   

۴.۲. مقدمه‌ای بر کنترل دسترسی اجباری (MAC): SELinux در مقابل AppArmor

مدل امنیتی استاندارد لینوکس، «کنترل دسترسی اختیاری» (DAC) است: مالک یک فایل تصمیم می‌گیرد که چه کسی (کاربر، گروه، دیگران) می‌تواند آن را بخواند، بنویسد یا اجرا کند.

«کنترل دسترسی اجباری» (MAC) یک لایه امنیتی اضافی و قدرتمندتر است که توسط ماژول‌های امنیتی لینوکس (LSM) مانند SELinux و AppArmor پیاده‌سازی می‌شود. در مدل MAC، یک سیاست (Policy) امنیتی سراسری که توسط مدیر سیستم تعریف شده، تصمیم می‌گیرد که آیا یک فرآیند (Subject) می‌تواند به یک منبع (Object) دسترسی داشته باشد یا خیر، حتی اگر مجوزهای DAC به آن اجازه دهند.   

سناریوی کلیدی: تصور کنید وب سرور Apache شما (که با کاربر www-data اجرا می‌شود) هک شده است. تحت مدل DAC، مهاجم اکنون می‌تواند هر فایلی را که کاربر www-data به آن دسترسی دارد بخواند. اما در مدل MAC، فرآیند Apache در یک “جعبه شنی” (Sandbox) محبوس است. سیاست MAC به فرآیند Apache اجازه نمی‌دهد چیزی خارج از دایرکتوری‌های وب (مانند /var/www) را بخواند، بنابراین مهاجم نمی‌تواند به فایل /etc/shadow دسترسی پیدا کند، حتی اگر کنترل کامل فرآیند Apache را در دست داشته باشد.   

• SELinux (Security-Enhanced Linux): توسعه‌یافته توسط NSA. از یک مدل پیچیده مبتنی بر «برچسب» (Label-based) استفاده می‌کند. هر فایل، فرآیند، پورت و… در سیستم یک “برچسب” (Context) امنیتی دریافت می‌کند. امنیت با نوشتن قوانینی که تعامل بین این برچسب‌ها را کنترل می‌کنند، اعمال می‌شود. SELinux بسیار دقیق و گرانولار  اما بسیار پیچیده است.   
• AppArmor (Application Armor): از یک مدل ساده‌تر مبتنی بر «مسیر فایل» (Path-based) استفاده می‌کند. «پروفایل»‌های امنیتی مستقیماً به مسیر فایل اجرایی (مانند /usr/sbin/nginx) اعمال می‌شوند و مشخص می‌کنند که آن برنامه به کدام فایل‌های دیگر (بر اساس مسیرشان) می‌تواند دسترسی داشته باشد.   

جدول ۲: مقایسه کنترل دسترسی اجباری (SELinux در مقابل AppArmor)

۴.۳. راهنمای عملی AppArmor (اوبونتو/دبیان)

AppArmor به طور پیش‌فرض در اوبونتو نصب و فعال است. مدیریت آن عمدتاً شامل درک و عیب‌یابی «پروفایل»‌ها است.   

• گام ۱: بررسی وضعیت از دستور aa-status (یا apparmor_status) برای دیدن وضعیت فعلی استفاده کنید:Bashsudo aa-status    این دستور لیستی از تمام پروفایل‌های بارگذاری‌شده را نشان می‌دهد و مشخص می‌کند که کدام‌ها در حالت enforce (اجرایی) و کدام‌ها در حالت complain (گزارش‌دهی) هستند.
• گام ۲: درک حالت‌ها
  • Enforce Mode (اجرا): حالت پیش‌فرض. AppArmor به طور فعال سیاست‌ها را اجرا می‌کند. هرگونه نقض (violation) هم مسدود (Block) می‌شود و هم در لاگ‌های سیستم (مانند dmesg یا /var/log/audit/audit.log) ثبت می‌شود.   
  • Complain Mode (گزارش‌دهی): حالت عیب‌یابی. AppArmor سیاست‌ها را اجرا نمی‌کند (یعنی نقض‌ها مسدود نمی‌شوند)، اما هر نقضی را در لاگ‌ها ثبت می‌کند. این حالت برای تست پروفایل‌های جدید یا عیب‌یابی برنامه‌هایی که به درستی کار نمی‌کنند، حیاتی است.   
• گام ۳: عیب‌یابی یک برنامه (مثلاً Nginx)
  • سناریو: شما Nginx را نصب کرده‌اید اما به درستی کار نمی‌کند و مشکوک هستید که AppArmor مقصر است.
  • ۱. انتقال به حالت Complain: پروفایل Nginx را به حالت complain ببرید تا جلوی کار آن را نگیرد، اما به شما بگوید مشکل کجاست:Bashsudo aa-complain /etc/apparmor.d/usr.sbin.nginx    
  • ۲. بازتولید خطا: سرویس Nginx را مجدداً راه‌اندازی کنید و کاری را که قبلاً شکست می‌خورد، تکرار کنید.
  • ۳. بررسی لاگ‌ها: لاگ‌های (audit) را بررسی کنید تا ببینید AppArmor چه دسترسی‌هایی را ثبت کرده است.
  • ۴. بازگشت به Enforce: پس از ویرایش پروفایل (/etc/apparmor.d/usr.sbin.nginx) و رفع مشکل، آن را به حالت امن enforce بازگردانید:Bashsudo aa-enforce /etc/apparmor.d/usr.sbin.nginx    
• گام ۴: بارگذاری مجدد پروفایل‌ها پس از ویرایش دستی یک فایل پروفایل، باید آن را مجدداً در هسته بارگذاری کنید:Bashsudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx    

۴.۴. راهنمای عملی SELinux (سنت‌او‌اس/RHEL)

SELinux بدون شک پیچیده‌ترین بخش امنیت لینوکس است. ۹۰٪ مشکلاتی که مدیران با آن مواجه می‌شوند، به دلیل درک نادرست از «برچسب‌های Context» است.

• گام ۱: بررسی و تغییر حالت‌ها
  • حالت‌ها:
    • Enforcing: پیش‌فرض. سیاست‌ها اجرا و مسدود می‌شوند.   
    • Permissive: سیاست‌ها اجرا نمی‌شوند (مسدود نمی‌شوند)، اما نقض‌ها در لاگ (/var/log/audit/audit.log) ثبت می‌شوند. این حالت ایده‌آل برای عیب‌یابی است.   
    • Disabled: SELinux کاملاً غیرفعال است (توصیه نمی‌شود).   
  • بررسی حالت فعلی:Bashgetenforce  (خروجی: Enforcing یا Permissive)   Bashsestatus  (اطلاعات کامل‌تر)   
  • تغییر حالت موقت (برای عیب‌یابی):Bash# تغییر به حالت گزارش‌دهی (Permissive) sudo setenforce 0 # تغییر به حالت اجرایی (Enforcing) sudo setenforce 1    
  • تغییر حالت دائمی (نیازمند ریبوت): ویرایش فایل sudo nano /etc/selinux/config و تنظیم SELINUX=enforcing (یا permissive).   
• گام ۲: درک مفهوم حیاتی: Context (برچسب امنیتی)
  • مفهوم: SELinux با تطبیق برچسب‌های فرآیند (Subject) و برچسب‌های فایل/منبع (Object) کار می‌کند.   
  • مشاهده Context:Bashls -Z /path/to/file    
  • مثال:unconfined_u:object_r:httpd_sys_content_t:s0
    • httpd_sys_content_t «نوع» (Type) است و مهم‌ترین بخش برچسب است.
• گام ۳: آموزش عملی (مشکل رایج: وب سرور و دایرکتوری‌های سفارشی)
  • سناریو: شما مدیر یک وب سرور (Apache یا Nginx) هستید و تصمیم گرفته‌اید فایل‌های وب‌سایت را به جای /var/www/html، در /srv/my-website قرار دهید. مجوزهای فایل (chmod 755) درست هستند، اما کاربران با خطای “403 Forbidden” مواجه می‌شوند.   
  • تشخیص مشکل:
    1. بررسی لاگ‌های audit: sudo grep nginx /var/log/audit/audit.log
    2. بررسی Context فایل‌ها: ls -Z /srv/my-website
    3. نتیجه: شما می‌بینید که فرآیند Nginx (با Context httpd_t ) در حال تلاش برای خواندن فایل‌هایی با Context default_t یا var_t است و SELinux این دسترسی را (با type=AVC در لاگ‌ها) مسدود کرده است. httpd_t فقط مجاز به خواندن httpd_sys_content_t است.   
  • راه حل بد : غیرفعال کردن SELinux (setenforce 0). این کار را نکنید.   
  • راه حل موقت (برای تست): chcon chcon (Change Context) برچسب یک فایل را موقت تغییر می‌دهد.   Bashsudo chcon -R -t httpd_sys_content_t /srv/my-website    مشکل: این تغییر موقتی است و در صورت ریبوت یا اجرای restorecon از بین می‌رود.   
  • راه حل صحیح و دائمی: semanage + restoreconsemanage ابزار مدیریت سیاست‌های SELinux است و تغییرات دائمی ایجاد می‌کند.
    • ۱. افزودن قانون (Rule): به SELinux بگویید که دایرکتوری /srv/my-website (و همه چیز درون آن) باید همیشه برچسب httpd_sys_content_t داشته باشد.Bash# (اگر semanage نصب نیست: sudo yum install -y policycoreutils-python-utils) sudo semanage fcontext -a -t httpd_sys_content_t "/srv/my-website(/.*)?"  (عبارت (/.*)? به معنای “این دایرکتوری و/یا هر چیزی درون آن” است).   
    • ۲. اعمال قانون (Apply): restorecon (Restore Context) فایل‌ها را بررسی می‌کند و برچسب‌های آن‌ها را بر اساس قوانینی که semanage تعریف کرده، “بازیابی” یا “اصلاح” می‌کند.   Bashsudo restorecon -Rv /srv/my-website    اکنون وب سرور شما کار خواهد کرد و امنیت SELinux نیز حفظ شده است.
• Booleans (پرچم‌های فعال/غیرفعال): SELinux همچنین دارای “Booleans” است که به شما اجازه می‌دهد بخش‌هایی از سیاست را به سادگی روشن یا خاموش کنید.
  • مثال: اگر وب سرور شما نیاز به اتصال به شبکه برای ارتباط با پایگاه داده دارد:Bash# -P برای دائمی کردن تغییر است sudo setsebool -P httpd_can_network_connect 1

تسلط بر SELinux (به ویژه semanage fcontext و restorecon) تفاوت بین یک مدیر سیستم تازه‌کار که امنیت را غیرفعال می‌کند و یک مدیر سیستم حرفه‌ای که از قدرتمندترین ابزار امنیتی لینوکس بهره می‌برد را نشان می‌دهد.

بخش ۵: استراتژی‌های پشتیبان‌گیری و بازیابی فاجعه (Disaster Recovery)

حفاظت از داده‌ها فقط به معنای جلوگیری از نفوذ نیست؛ بلکه به معنای توانایی بازیابی اطلاعات پس از وقوع یک فاجعه (مانند خرابی سخت‌افزار، خطای انسانی، یا حمله باج‌افزار) نیز می‌باشد. یک نسخه پشتیبان (بکاپ) که تست نشده باشد، به سادگی یک امید است، نه یک استراتژی.   

۵.۱. تدوین استراتژی بکاپ

• قانون ۱-۲-۳: یک استراتژی استاندارد صنعتی که می‌گوید شما باید همیشه ۳ نسخه از داده‌های خود را، روی ۲ نوع رسانه ذخیره‌سازی مختلف، با ۱ نسخه در مکانی خارج از سایت (Off-site) نگهداری کنید.
• انواع بکاپ:
  • کامل (Full): یک کپی کامل از تمام داده‌ها. این روش ساده‌ترین بازیابی را دارد اما بیشترین زمان و فضا را مصرف می‌کند.   
  • افزایشی (Incremental): فقط فایل‌هایی را که از آخرین بکاپ (اعم از کامل یا افزایشی) تغییر کرده‌اند، کپی می‌کند. این روش سریع‌ترین بکاپ را دارد اما بازیابی آن پیچیده‌تر است، زیرا نیازمند بکاپ کامل اولیه و تمام بکاپ‌های افزایشی بعدی به ترتیب است.   
  • تفاضلی (Differential): فایل‌هایی را که از آخرین بکاپ کامل تغییر کرده‌اند، کپی می‌کند. فضای بیشتری نسبت به افزایشی مصرف می‌کند، اما بازیابی آن سریع‌تر است (فقط به بکاپ کامل و آخرین بکاپ تفاضلی نیاز دارد).   
• محل ذخیره‌سازی: حیاتی‌ترین قانون بکاپ‌گیری این است که نسخه‌های پشتیبان هرگز نباید در همان سخت‌افزار یا سرور اصلی ذخیره شوند. اگر سرور اصلی دچار مشکل سخت‌افزاری یا حمله شود، بکاپ نیز همزمان با داده‌های اصلی از بین خواهد رفت. همیشه از یک سرور ریموت، فضای ذخیره‌سازی ابری یا دیسک‌های فیزیکی جداگانه استفاده کنید.   

۵.۲. استفاده از rsync برای پشتیبان‌گیری کارآمد

rsync (Remote Sync) ابزار منتخب در دنیای لینوکس برای همگام‌سازی و پشتیبان‌گیری فایل‌ها است.   

• چرا rsync؟
  • کارآمدی: rsync از «الگوریتم انتقال دلتا» (delta-transfer algorithm) استفاده می‌کند. این بدان معناست که به جای کپی کردن کل فایل، فقط بخش‌هایی از فایل را که تغییر کرده‌اند، منتقل می‌کند. این باعث صرفه‌جویی عظیم در زمان و پهنای باند شبکه می‌شود.   
  • امنیت: rsync می‌تواند به راحتی از طریق SSH به عنوان حامل (transport) استفاده کند، بنابراین تمام داده‌های در حال انتقال رمزنگاری می‌شوند.   
  • انعطاف‌پذیری: می‌تواند برای بکاپ‌گیری محلی (Local) یا ریموت (Remote) استفاده شود.   
• تشریح گزینه‌های (Flags) پرکاربرد: دستور rsync گزینه‌های زیادی دارد، اما ترکیب زیر معمولاً برای بکاپ‌گیری استفاده می‌شود: rsync -avz
  • -a (Archive): حالت آرشیو، که معادل مجموعه‌ای از گزینه‌ها (-rlptgoD) برای حفظ تمام ویژگی‌های فایل است :
    • -r: بازگشتی (Recursive)، برای کپی کردن پوشه‌ها به صورت تو در تو.   
    • -l: حفظ سیمبولیک لینک‌ها (Symlinks).
    • -p: حفظ مجوزهای فایل (Permissions).   
    • -t: حفظ زمان‌های تغییر (Timestamps).   
    • -g: حفظ گروه (Group).
    • -o: حفظ مالک (Owner).
  • -v (Verbose): نمایش خروجی دقیق عملیات.   
  • -z (Compress): فشرده‌سازی داده‌ها قبل از انتقال، که برای شبکه‌های کندتر مفید است.   
  • -h (Human-readable): نمایش اعداد (مانند حجم فایل‌ها) به فرمت خوانا (KB, MB, GB).   
  • --delete: این گزینه فایل‌هایی را در مقصد (بکاپ) حذف می‌کند که دیگر در مبدا (سرور اصلی) وجود ندارند. این برای ایجاد یک «آینه» (Mirror) دقیق استفاده می‌شود.   
  • --exclude=PATTERN: الگوهایی (مانند *.log یا /tmp/* یا /proc/*) را از فرآیند بکاپ‌گیری مستثنی می‌کند.   
• مثال عملی ۱: بکاپ کامل سیستم (با مستثنی کردن دایرکتوری‌های سیستمی)Bashsudo rsync -aAXv / \ --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} \ /path/to/backup/destination/    
• مثال عملی ۲: بکاپ به سرور ریموت از طریق SSH این امن‌ترین روش برای بکاپ‌گیری Off-site است:Bashsudo rsync -avz -e ssh /path/to/local/source/ \ backup_user@remote_server_ip:/path/to/remote/backup/    
• اتوماسیون: این دستورات rsync باید در یک اسکریپت قرار داده شده و به طور منظم (مثلاً هر شب در ساعت ۲:۳۰ بامداد) از طریق cron (زمان‌بند لینوکس) اجرا شوند.   

۵.۳. حیاتی‌ترین گام: تست و بازیابی بکاپ

یک بکاپ تست نشده، بکاپ نیست. این مهم‌ترین اصل بازیابی فاجعه است. دلایل زیادی وجود دارد که یک بکاپ ممکن است شکست بخورد: خرابی فایل در حین انتقال، ناقص بودن بکاپ، خطاهای I/O، یا ناسازگاری نرم‌افزار. شما نمی‌خواهید در لحظه‌ای که به داده‌های خود نیاز دارید، متوجه شوید که بکاپ شما خراب یا غیرقابل استفاده است.   

• چگونه تست کنیم؟
  • بهترین روش: به طور منظم (مثلاً هفتگی یا ماهانه) فرآیند بازیابی را در یک محیط ایزوله (مانند یک سرور مجازی یا کانتینر دیگر) شبیه‌سازی کنید.   
  • فایل‌ها را از بکاپ بازیابی کنید و بررسی کنید: آیا داده‌ها کامل هستند؟ آیا پایگاه داده به درستی import می‌شود؟ آیا برنامه اجرا می‌شود؟
  • برای بکاپ‌های پایگاه داده SQL، ابزارهای داخلی مانند RESTORE VERIFYONLY یا استفاده از WITH CHECKSUM در هنگام ایجاد بکاپ می‌توانند به تایید سلامت فایل کمک کنند.   
• روند بازیابی (Restore) با rsync بازیابی با rsync به سادگی معکوس کردن مبدا (Source) و مقصد (Destination) در دستور بکاپ است :   Bashrsync -avz -e ssh \ backup_user@remote_server_ip:/path/to/remote/backup/ \ /path/to/local/restore_location/    

هشدار استراتژیک: rsync در درجه اول یک ابزار همگام‌سازی (Synchronization) است، نه یک ابزار بایگانی (Archiving) مانند tar. اگر از rsync با گزینه --delete  برای ایجاد یک آینه استفاده می‌کنید، مراقب باشید. اگر فایلی را به طور تصادفی در سرور اصلی (مبدا) حذف کنید، اجرای بعدی rsync آن فایل را از بکاپ (مقصد) شما نیز حذف خواهد کرد.   

برای مقابله با این مشکل، یک استراتژی بکاپ حرفه‌ای rsync نباید فقط یک آینه را رونویسی کند. به جای آن، باید از اسنپ‌شات‌های (Snapshots) تاریخی استفاده کند (ابزارهایی مانند Timeshift  این کار را به طور خودکار انجام می‌دهند) تا بتوانید به نسخه‌های قبلی فایل‌ها بازگردید، حتی اگر حذف یا خراب شده باشند.   

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

امنیت سرور یک مقصد نیست، بلکه یک سفر مداوم است. این فرآیند مستمر بر پایه مدل دفاع چندلایه بنا شده است که شامل لایه‌های فیزیکی ، شبکه ، سیستم‌عامل  و برنامه ، همراه با نظارت مستمر و برنامه‌ریزی برای بازیابی فاجعه است.   

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

چک‌لیست عملی امنیت سرور لینوکس:

1. دسترسی اولیه:
   • [ ] آیا ورود مستقیم کاربر root از طریق SSH (PermitRootLogin no) غیرفعال شده است؟    
   • [ ] آیا یک کاربر مدیریتی با امتیازات sudo ایجاد شده است؟    
2. سخت‌سازی SSH:
   • [ ] آیا احراز هویت با رمز عبور (PasswordAuthentication no) به طور کامل غیرفعال شده است؟    
   • [ ] آیا ورود به سرور فقط از طریق جفت کلید SSH امن انجام می‌شود؟    
   • [ ] (اختیاری اما موثر) آیا پورت پیش‌فرض SSH به یک شماره غیر استاندارد تغییر یافته است؟    
3. دفاع محیطی (فایروال):
   • [ ] آیا فایروال (UFW یا FirewallD) فعال است؟    
   • [ ] آیا سیاست پیش‌فرض برای ترافیک ورودی (incoming) روی DENY یا DROP تنظیم شده است؟    
   • [ ] آیا فقط پورت‌های سرویس‌های ضروری (مانند SSH, HTTP/S) به صورت صریح باز شده‌اند؟    
4. دفاع فعال:
   • [ ] آیا Fail2Ban نصب و پیکربندی شده است تا از سرویس‌های حیاتی (حداقل SSH) در برابر حملات Brute-Force محافظت کند؟    
5. نگهداری و یکپارچگی:
   • [ ] آیا سیستم‌عامل و تمام بسته‌ها به طور منظم بروزرسانی می‌شوند؟    
   • [ ] (توصیه شده) آیا بروزرسانی‌های امنیتی خودکار (مانند unattended-upgrades در اوبونتو) فعال شده‌اند؟    
   • [ ] آیا ابزار نظارت بر یکپارچگی فایل (FIM) مانند AIDE نصب، پیکربندی و به طور منظم اجرا می‌شود؟    
   • [ ] آیا ابزار خلاصه‌سازی لاگ (مانند Logwatch) برای بازبینی روزانه لاگ‌ها تنظیم شده است؟    
6. سخت‌سازی پیشرفته (MAC):
   • [ ] آیا ماژول کنترل دسترسی اجباری (MAC) توزیع شما (SELinux در RHEL/CentOS یا AppArmor در Ubuntu/Debian) در حالت Enforcing فعال است؟ (با getenforce یا aa-status بررسی کنید).   
7. بازیابی فاجعه (Backup):
   • [ ] آیا یک استراتژی بکاپ خودکار (مانند rsync به یک مکان Off-site) در حال اجرا است؟    
   • [ ] آیا بکاپ‌ها در مکانی متفاوت از سرور اصلی ذخیره می‌شوند؟    
   • [ ] (مهم‌ترین سوال): آیا اخیراً فرآیند بازیابی (Restore) بکاپ خود را با موفقیت تست کرده‌اید؟