چک‌لیست امنیت Ubuntu Server: از مستندات رسمی و OpenSSH

نصب تازهٔ اوبونتو معمولاً برای استفادهٔ فوری «معقول» است، اما طبق مقدمهٔ امنیت مستندات رسمی سرور اوبونتو، وضعیت امنیتی بستگی به نحوهٔ استقرار بعدی دارد و باید رویکرد لایه‌لایه داشته باشید — نه یک نقطهٔ دفاع. این مقاله چک‌لیست عملی همان لایه‌هاست، با ارجاع به راهنماهای رسمی فایروال (UFW)، AppArmor، به‌روزرسانی خودکار و پیکربندی OpenSSH؛ نه کپی یک harden.sh ناشناس از اینترنت.

هدف: پایهٔ قابل دفاع برای یک سرور اینترنتی معمولی، با آگاهی از ریسک قفل‌شدن و بدون ادعای compliance کامل CIS/FIPS.

پاسخ کوتاه

لایه‌ها را به ترتیب بسازید: (۱) کاربر غیر‌root + sudo، (۲) به‌روزرسانی و unattended-upgrades، (۳) OpenSSH فقط‌کلیدی با drop-in زودهنگام و `sshd -t`، (۴) UFW با allow برای SSH سپس enable، (۵) تأیید AppArmor در enforce برای پروفایل‌های پیش‌فرض، (۶) حداقل پورت/سرویس، (۷) زمان درست و لاگ قابل‌اتکا. هر لایه را قبل از سفت کردن لایهٔ بعدی تست کنید.

مستندات اوبونتو صریح است: اگر تنها راه دسترسی SSH باشد و پیکربندی را خراب کنید، ممکن است قفل شوید — همیشه مسیر بازیابی داشته باشید.

چارچوب لایه‌لایه (مستند Ubuntu)

صفحهٔ Introduction to security روی مستندات سرور اوبونتو تأکید می‌کند سیستم را به یک دفاع وابسته نکنید و به صفحهٔ پیشنهادهای امنیتی و بسته‌های مرتبط ارجاع می‌دهد. how-to امنیت، بلوک‌های مشخصی می‌چیند: مدیریت کاربر، فایروال، AppArmor، امنیت کنسول، رمزنگاری/OpenSSH، VPN و غیره. این چک‌لیست همان بلوک‌های پرکاربرد را برای یک VM عمومی اولویت‌بندی می‌کند.

• کاهش هویت‌های قدرتمند در معرض شبکه (root SSH).
• کاهش روش‌های احراز هویت حدس‌زدنی (password).
• کاهش سطح شبکه (UFW + SG ابر).
• محدود کردن قابلیت برنامه‌ها (AppArmor).
• کاهش پنجرهٔ آسیب‌پذیری (پچ خودکار امنیتی).

۱) کاربران، sudo و سیاست رمز

طبق مسیر how-to کاربر اوبونتو: حساب روزمره جدا از root، عضویت در گروه sudo، و اجتناب از اشتراک رمز. برای SSH، کلید per-person بهتر از یک حساب مشترک با کلید گروهی است تا revocation معنی داشته باشد.

bash

sudo adduser deploy sudo usermod -aG sudo deploy sudo less /etc/sudoers # ترجیح: فایل در /etc/sudoers.d/ به‌جای ویرایش مستقیم

۲) OpenSSH: drop-in، اولین مقدار، تست

اوبونتو معمولاً `Include` برای `/etc/ssh/sshd_config.d/*.conf` دارد و OpenSSH برای بیشتر کلیدها اولین مقدار را برنده می‌کند. فایل‌های cloud-init ممکن است `PasswordAuthentication yes` بگذارند؛ نام drop-in سخت‌سازی را طوری انتخاب کنید که زود مرتب شود (مثلاً `00-hardening.conf`). حداقل سیاست رایج و هم‌راستا با sshd_config(5):

bash

sudo tee /etc/ssh/sshd_config.d/00-hardening.conf >/dev/null << 'EOF' PermitRootLogin no PasswordAuthentication no KbdInteractiveAuthentication no PubkeyAuthentication yes PermitEmptyPasswords no X11Forwarding no MaxAuthTries 3 LoginGraceTime 30 EOF sudo sshd -t sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin|kbdinteractiveauthentication' sudo systemctl reload ssh

از نشست دوم با کلید وارد شوید و تلاش رمز را عمداً شکست دهید. جزئیات بیشتر و دام‌های Include در مقالهٔ سخت‌سازی SSH آمده است.

۳) UFW: فایروال میزبان رسمی اوبونتو

مستند Firewalls اوبونتو می‌گوید ابزار پیش‌فرض پیکربندی فایروال `ufw` است و به‌طور پیش‌فرض غیرفعال است. الگو:

bash

sudo ufw allow OpenSSH sudo ufw allow 443/tcp sudo ufw --dry-run enable # در صورت پشتیبانی؛ یا status را قبل از enable ببینید sudo ufw enable sudo ufw status verbose sudo ufw logging on

• قبل از enable حتماً SSH را allow کنید.
• می‌توانید از نام سرویس در /etc/services یا application profile استفاده کنید (`ufw app list`).
• محدود کردن منبع (`from 203.0.113.0/24 to any port 22`) سطح حمله را پایین می‌آورد اگر IP مدیریتی پایدار دارید.
• UFW جایگزین Security Group ابر نیست؛ هر دو را هم‌تراز کنید.

۴) AppArmor: MAC پیش‌فرض اوبونتو

مستند AppArmor اوبونتو توضیح می‌دهد این LSM با پروفایل per-program قابلیت‌ها را محدود می‌کند و روی اوبونتو به‌طور پیش‌فرض نصب و بارگذاری می‌شود. وضعیت را با `aa-status` ببینید. پروفایل‌ها در حالت complain (ثبت نقض) یا enforce (اعمال) کار می‌کنند. برای بسیاری سرورها، نگه داشتن پروفایل‌های بسته‌شده در enforce و نصب `apparmor-profiles` نقطهٔ شروع است؛ خاموش کردن کامل AppArmor امنیت را کم می‌کند و در نسخه‌های جدیدتر حتی به پارامتر کرنل نیاز دارد.

bash

sudo aa-status sudo apt install apparmor-profiles sudo systemctl status apparmor --no-pager

اگر برنامه‌ای در enforce شکایت می‌کند، به‌جای disable سراسری، با `aa-logprof` یا include محلی در `/etc/apparmor.d/local/` طبق مستند پیش بروید.

۵) به‌روزرسانی خودکار امنیتی

مستند Automatic updates اوبونتو می‌گوید `unattended-upgrades` به‌طور پیش‌فرض به‌روزرسانی‌های امنیتی را بدون تعامل اعمال می‌کند. فایل‌های مهم:

• `/etc/apt/apt.conf.d/20auto-upgrades` — روشن/خاموش و تناوب.
• `/etc/apt/apt.conf.d/50unattended-upgrades` — origins مجاز، blacklist، ایمیل، reboot.
• لاگ در `/var/log/unattended-upgrades/`.

bash

systemctl status apt-daily.timer apt-daily-upgrade.timer --no-pager sudo unattended-upgrade -v --dry-run | tail grep -E 'Unattended-Upgrade|Allowed-Origins|Automatic-Reboot' /etc/apt/apt.conf.d/50unattended-upgrades | head

برای تولید حساس: بسته‌های کرنل/اپ حساس را blacklist کنید یا reboot را زمان‌بندی کنید؛ خاموش کردن کامل پچ امنیتی را فقط با جایگزین مدیریت ناوگان توجیه کنید. Ubuntu Pro/ESM پوشش طولانی‌تر و Livepatch را برای برخی سناریوها پیشنهاد می‌کند — در مقدمهٔ امنیت رسمی آمده است.

۶) حداقل سرویس، TLS و اسرار

• فقط پورت‌های لازم را publish کنید؛ بقیه را از ss پیدا و ببندید.
• برای HTTPS از گواهی معتبر (مثلاً مسیر Let’s Encrypt در مستند TLS اوبونتو) استفاده کنید.
• اسرار را در فایل با مجوز ۶۰۰ و خارج از git نگه دارید.
• در صورت نیاز، 2FA برای SSH (TOTP/U2F) از how-toهای رسمی قابل بررسی است — پیچیدگی عملیاتی دارد.

جدول چک‌لیست اجرایی

ترتیب ایمن اعمال (ضد قفل)

1. کلید SSH را برای کاربر sudo تست کنید.
2. console ابر را باز نگه دارید.
3. drop-in SSH را بنویسید، sshd -t، reload، تست نشست دوم.
4. قانون UFW برای OpenSSH، سپس enable، تست SSH جدید.
5. بقیهٔ پورت‌های اپ را باز کنید.
6. وضعیت AppArmor و unattended-upgrades را تأیید کنید.
7. تغییرات را در مستند/IaC ثبت کنید.

آنچه این چک‌لیست عمداً پوشش نمی‌دهد

• پروفایل کامل CIS یا FIPS (مسیر Ubuntu Pro/compliance جداست).
• WAF، IDS سازمانی، یا zero-trust کامل.
• سخت‌سازی هستهٔ اختصاصی فراتر از پیش‌فرض معقول.
• تضمین در برابر zero-day؛ لایه‌ها ریسک را کم می‌کنند نه صفر.

اشتباه‌های رایج در «سخت‌سازی»

• ویرایش فقط sshd_config اصلی و نادیده گرفتن sshd_config.d و cloud-init.
• enable کردن UFW قبل از allow SSH.
• غیرفعال کردن AppArmor به‌خاطر یک خطای برنامه.
• روشن کردن Automatic-Reboot بدون پنجرهٔ نگهداری.
• اتکا به پورت غیر۲۲ به‌عنوان امنیت اصلی.

هم‌ترازی با Security Group ابر

UFW روی میزبان و قوانین ابر باید داستان یکسان بگویند. باز بودن ۲۲ در UFW و بسته بودن در SG یعنی از اینترنت نمی‌آیید؛ برعکسش یعنی UFW را دور زده‌اید و فقط به ابر تکیه کرده‌اید. در چک‌لیست، هر پورت allow را در هر دو لایه تیک بزنید. برای مدیریت، محدود کردن SSH به IP دفتر/VPN در SG اغلب مؤثرتر از بازی با پورت غیر۲۲ است.

لاگ امنیتی و نگهداشت شواهد

journal واحد ssh و لاگ UFW (در صورت روشن بودن logging) را به سامانهٔ مرکزی بفرستید تا مهاجم با دسترسی محلی نتواند به‌راحتی ردپا را پاک کند. نگهداری بیش از حد لاگ روی خود ریشه، شما را به مقالهٔ دیسک پر برمی‌گرداند — سقف و ارسال خارجی را با هم طراحی کنید.

bash

sudo journalctl -u ssh --since today | tail -n 20 sudo ufw status verbose

Ubuntu Pro به‌عنوان لایهٔ اختیاری

مقدمهٔ امنیت رسمی به Ubuntu Pro، ESM و Livepatch اشاره می‌کند. برای ناوگان کوچک رایگان تا سقف مشخص ماشین، و برای سازمان‌ها به‌عنوان پوشش طولانی‌تر. این جایگزین UFW/SSH/AppArmor نیست؛ پوشش پچ و بعضی قابلیت‌های compliance را گسترش می‌دهد. تصمیم خرید را با موجودی بسته و نیاز قانونی بسنجید.

بازبینی فصلی

چک‌لیست یک‌بار مصرف نیست. هر فصل: کاربران sudo، کلیدهای SSH، قوانین UFW، وضعیت aa-status، و dry-run به‌روزرسانی را مرور کنید. دسترسی کسانی که تیم را ترک کرده‌اند اولین چیزی است که معمولاً جا می‌ماند.

پیوند کنترل‌ها به تهدیدهای واقعی

بستن password SSH تهدید بروت‌فورس اینترنتی را کم می‌کند. UFW تهدید سرویس accidental-exposed را کم می‌کند. AppArmor دامنهٔ آسیب بعد از نفوذ به یک سرویس را محدود می‌کند. unattended-upgrades پنجرهٔ بهره‌برداری از CVEهای شناخته‌شده را کوتاه می‌کند. اگر کنترل را به تهدید وصل نکنید، لیست طولانی و بی‌اولویت می‌شود و تیم خسته رهایش می‌کند.

برای هر سرور، سه تهدید بالای خود را بنویسید — مثلاً تصاحب SSH، باج‌افزار روی داده، یا نشت داده از پنل ادمین — و ببینید چک‌لیست کدام را پوشش می‌دهد. شکاف‌ها را آگاهانه بپذیرید یا برایشان کار تعریف کنید؛ نادیده‌گرفتن خام بدترین حالت است.

تغییرات امنیتی را مثل تغییرات کد review کنید. یک PR که UFW و sshd_config.d را عوض می‌کند باید توضیح ریسک قفل و پلان تست داشته باشد. فرهنگ review جلوی harden.shهای شبانه را می‌گیرد.

در نهایت، به یاد داشته باشید امنیت میزبان فقط یک لایه است: هویت اپ، کنترل دسترسی داده، و رمزنگاری در مسیر/در سکون همچنان لازم‌اند. این مقاله میزبان اوبونتو را محکم می‌کند نه کل محصول را.

جمع‌بندی اجرایی برای یک بعدازظهر

اگر فقط یک بعدازظهر وقت دارید: کاربر sudo و کلید را تمام کنید، drop-in OpenSSH را با تست ضدقفل اعمال کنید، UFW را با OpenSSH و پورت اپ enable کنید، aa-status و unattended-upgrades را تأیید کنید، و خروجی ss را از نظر پورت اضافی پاکسازی کنید. این مجموعه مطابق روح مستندات رسمی اوبونتو و OpenSSH است و ریسک رایج‌ترین حملات و اشتباه‌ها را کم می‌کند.

فردای آن روز: لاگ مرکزی، محدود کردن SSH به VPN/IP مدیریتی، و بازبینی کاربرها را انجام دهید. هفتهٔ بعد: سیاست reboot و blacklist بسته‌های حساس را با تیم استقرار هماهنگ کنید. امنیت یک پروژهٔ پایان‌دار نیست؛ یک صف اولویت‌دار است.

هر مورد چک‌لیست را در تیکت یا PR با شاهد فرمان ببندید تا «فکر می‌کنم انجام دادم» جای «sshd -T نشان می‌دهد password no است» را نگیرد. شواهد کوتاه، ممیزی طولانی را ساده می‌کنند.

خلاصه

امنیت Ubuntu Server از مستندات رسمی یک داستان لایه‌لایه است: هویت، OpenSSH درست‌پیکربندی‌شده، UFW، AppArmor، و پچ خودکار. چک‌لیست بالا همان لایه‌ها را به ترتیب ضد‌قفل اجرا می‌کند. بعد از پایه، مانیتورینگ، بکاپ و حداقل سطح سرویس را از مقالهٔ آماده‌سازی production اضافه کنید.

سوالات متداول

آیا fail2ban اجباری است؟

در مستند اصلی how-to امنیت به‌عنوان ستون اول نیست. با بستن password ارزشش کم می‌شود؛ به‌عنوان لایهٔ اضافه در برابر نویز اسکن می‌تواند مفید باشد، نه جایگزین کلید و فایروال.

UFW برای سرور gateway کافی است؟

خودِ man/مستند می‌گوید ufw عمدتاً برای فایروال host-based و قوانین ساده است. سناریوهای پیچیده ممکن است به nftables/Shorewall و طراحی شبکه نیاز داشته باشند.

آیا باید AppArmor را برای Docker دست بزنم؟

کانتینرها مدل جدا دارند (پروفایل‌های moby/snap و …). پیش‌فرضها را نفهمیده disable نکنید؛ مستند همان نسخه و runtime را بخوانید.

منابع و مراجع

• Ubuntu Server — Introduction to security: https://documentation.ubuntu.com/server/explanation/intro-to/security/
• Ubuntu Server — Security how-to index: https://documentation.ubuntu.com/server/how-to/security/
• Ubuntu Server — Firewalls (ufw): https://documentation.ubuntu.com/server/how-to/security/firewalls/
• Ubuntu Server — AppArmor: https://documentation.ubuntu.com/server/how-to/security/apparmor/
• Ubuntu Server — Automatic updates: https://documentation.ubuntu.com/server/how-to/software/automatic-updates/
• Ubuntu Server — OpenSSH server how-to: https://documentation.ubuntu.com/server/how-to/security/openssh-server/
• sshd_config(5): https://man.openbsd.org/sshd_config.5
• OpenSSH manuals: https://www.openssh.com/manual.html