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

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

این مطلب فهرست ضدالگو است با نشانه، پیامد، و جایگزین — مکمل چک‌لیست‌های production و امنیت، نه جایگزین‌شان.

پاسخ کوتاه

اگر فقط پنج چیز را درست کنید: کلید SSH به‌جای رمز، فایروال با حداقل پورت، به‌روزرسانی امنیتی روشن، هشدار فضای دیسک و حافظه، و یک بازیابی بکاپِ آزموده. باقی اشتباه‌ها هنوز مهم‌اند، ولی این پنج‌تا بیشترین حوادث روزمره را می‌پوشانند.

امنیت کامل نیست؛ تکرار نکردن اشتباه‌های ارزان، فاصلهٔ شما با اکثر سرورهای رهاشده است.

۱) SSH با رمز و root باز روی ۰.۰.۰.۰

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

• نشانه: هزاران Failed password در journal.
• درست: کلید، PermitRootLogin no، PasswordAuthentication no، تست ضدقفل.

۲) فایروال را «بعداً» گذاشتن

سرویس توسعه روی پورت تصادفی bind به همهٔ آدرس‌ها + نبود UFW/SG یعنی سطح حملهٔ unintentional. «فقط برای تست» روی IP عمومی می‌ماند.

• نشانه: ss نشان می‌دهد 0.0.0.0:PORT برای چیزی که فکر می‌کردید داخلی است.
• درست: bind محلی وقتی ممکن است؛ UFW allow صریح؛ SG ابر هم‌تراز.

۳) chmod 777 و مالکیت بی‌صاحب

برای «کار کند» همه را writable کردن، هر پروسس وب را به نقطهٔ نوشتن کد تبدیل می‌کند. chown به کاربر اشتباه هم همین خانواده است.

• نشانه: دایرکتوری سایت world-writable.
• درست: کمترین مجوز لازم؛ جدا کردن کاربر وب از استقرار؛ فهم گروه و umask.

۴) اجرای اپ روزمره با root

یک RCE در اپ یعنی مالک کل سیستم. systemd می‌تواند User= جدا، و کانتینر می‌تواند non-root اجرا کند.

• نشانه: پروسس node/python/java با uid 0.
• درست: کاربر سرویس، capabilities محدود، جداسازی.

۵) نادیده گرفتن دیسک تا «No space left»

لاگ رشد می‌کند، Docker لایه انباشته می‌کند، بکاپ محلی همان دیسک را می‌ترکاند. وقتی دیسک پر است حتی SSH گاهی بدرفتار می‌شود.

• نشانه: Use% ۹۵٪ بدون آلارم؛ inode پر با بلوک خالی.
• درست: مانیتور Avail و IUse٪؛ logrotate؛ پاک‌سازی هدفمند.

۶) تفسیر غلط حافظه و load

وحشت از buff/cache یا reboot به‌خاطر load بدون نسبت به nproc، یا برعکس نادیده گرفتن OOM واقعی.

• درست: available را بخوانید؛ load را به CPU نرمال کنید؛ لاگ OOM را جدی بگیرید.

۷) بکاپ بدون بازیابی، یا بکاپ روی همان دیسک

فایل‌های `.bak` کنار دیتابیس در برابر سوختن دیسک یا باج‌افزار کمکی نمی‌کنند. بکاپ یعنی نسخهٔ جدا + آزمایش restore دوره‌ای.

۸) به‌روزرسانی را ماه‌ها عقب انداختن

ترس از شکستن سرویس باعث انباشت CVE می‌شود. راه میانه: unattended برای security، staging برای تغییرات بزرگ، blacklist نقطه‌ای نه خاموشی کامل.

۹) پیکربندی موقت که دائمی شد

`iptables -A` دستی، تغییر `ip addr`، ویرایش resolv.conf که بعد از reboot می‌پرد، یا باز کردن پورت «تا فردا». بدون ثبت در Netplan/Ansible/اسناد، سیستم غیرقابل‌تکرار می‌شود.

• درست: هر تغییر شبکه‌ای مسیر پایدار داشته باشد؛ drift را با واقعیت‌سنجی ss/ufw ببینید.

۱۰) ساعت غلط و لاگ بدون زمینه

TLS شکست می‌خورد، همبستگی لاگ بین سرویس‌ها غیرممکن می‌شود، و گواهی‌ها «نارس» به نظر می‌رسند. timezone و NTP را در روز اول درست کنید.

۱۱) یک نفر، یک کلید، بدون جانشین

تنها کسی که به production دسترسی دارد مرخص می‌شود یا کلید را گم می‌کند. حساب‌های شکست‌شیشه، دسترسی console ابر، و مستند بازیابی بخشی از امنیت است نه ضد آن.

۱۲) کپی کور اسکریپت سخت‌سازی

اسکریپتی که پورت SSH را عوض می‌کند، UFW را فعال می‌کند و password را می‌بندد — بدون console و بدون تست — کلاسیک‌ترین راه قفل شدن است. هر دستور را بفهمید؛ از مقاله‌های مبتنی بر مستند رسمی به‌عنوان نقشه استفاده کنید نه از paste ناشناس.

اولویت‌بندی اصلاح

1. هر چیزی که تصاحب فوری می‌دهد: SSH رمز، پورت‌های مدیریتی باز، 777 روی وب‌روت.
2. هر چیزی که بازیابی را می‌کشد: نبود بکاپ آف‌سایت، نبود console.
3. هر چیزی که پایداری را می‌کشد: دیسک، OOM، ساعت.
4. بهینه‌سازی و زیباسازی آخر.

داستان کوتاه: قفل شدن با harden.sh

ادمین تازه‌کار اسکریپتی از وب پیدا می‌کند که همزمان پورت SSH را عوض می‌کند، PasswordAuthentication را می‌بندد، و UFW را enable می‌کند — در حالی که قانون allow هنوز روی پورت قبلی است. نشست فعلی قطع می‌شود و کلید روی پورت جدید تست نشده است. بدون console ابر، سرور عملاً از دست رفته تا پشتیبانی تیکت بدهد. درس: تغییرات دسترسی را اتمیک و قابل‌برگشت کنید؛ از نشست دوم تست بگیرید؛ console را قبل از جادوی امنیتی باز کنید.

داستان کوتاه: ۷۷۷ و وب‌شل

برای رفع خطای آپلود، پوشهٔ uploads و گاهی کل پروژه 777 می‌شود. هفته‌ها بعد یک آسیب‌پذیری آپلود فایل، وب‌شل می‌نشاند چون نوشتن برای everyone باز بوده است. مجوز درست معمولاً مالکیت کاربر سرویس + نوشتن فقط روی همان پوشهٔ آپلود با اجرای محتوای آپلود‌شده به‌صورت استاتیک یا خارج از root وب است — نه 777 سراسری.

داستان کوتاه: بکاپ روی همان دیسک

کرون هر شب `/var/www` را به `/var/backups/www.tgz` می‌فرستد. دیسک می‌میرد یا حجم پاک می‌شود؛ هر دو نسخه می‌روند. بکاپ یعنی حداقل یک مقصد جدا (آبجکت استوریج، منطقهٔ دیگر، یا نوار در مدل‌های کلاسیک) و تست بازگردانی روی ماشین تمیز.

فرهنگ پیشگیری در تیم‌های کوچک

حتی اگر نفر دوم ندارید، چک‌لیست PR برای Terraform/Ansible، آلارم دیسک، و یک سند «اگر من نبودم» سه کاری است که جلوی تکرار این اشتباه‌ها را می‌گیرد. ابزار گران لازم نیست؛ عادت لازم است.

چرا اشتباه‌ها تکرار می‌شوند؟

چون کوتاه‌مدت پاداش دارند: 777 سریع‌تر از فهم مجوز است، رمز SSH سریع‌تر از توضیح کلید به همکار است، بکاپ محلی سریع‌تر از ساخت باکت و تست restore است. تا وقتی هزینهٔ حادثه به فرد یا تیم برنگردد، ضدالگو برنده می‌شود. راهکار مدیریتی این است که هزینهٔ پیشگیری را کم کنید (قالب آماده، تصویر طلایی، چک‌لیست PR) و هزینهٔ میانبر را زیاد کنید (آلارم، review، تمرین بازیابی).

آموزش نقطه‌ای بعد از حادثه مؤثرتر از کلاس طولانی قبل از آن است — به شرطی که به تغییر قالب و چک‌لیست منجر شود نه فقط به سرزنش. هر حادثه باید یک مورد به این فهرست یا به تصویر پایه اضافه کند.

اگر از نرم‌افزار به‌عنوان سرویس مدیریت‌شده به VPS خودمدیریت مهاجرت می‌کنید، انتظار داشته باشید مسئولیت‌هایی که قبلاً پنهان بود ناگهان روی دوش شما بیفتد: پچ، دیسک، ساعت، کلید. فهرست این مقاله را به‌عنوان بدهی انتقال صریح کنید و زمان برایش بگذارید.

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

جدول جمع‌بندی ضدالگو → عادت

این جدول را کنار مانیتور on-call بگذارید. وقتی دست برای میانبر می‌رود، یک نگاه کافی است تا هزینهٔ واقعی یادآوری شود. اگر مورد جدیدی کشف کردید، ردیف اضافه کنید — فهرست باید مال تیم شما باشد نه فقط مال این مقاله.

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

برنامهٔ ۷ روزه برای پاکسازی

روز ۱: SSH و کاربران. روز ۲: فایروال و پورت‌ها. روز ۳: مجوزهای وب‌روت و مالکیت. روز ۴: آلارم دیسک و حافظه. روز ۵: بکاپ و یک restore آزمایشی کوچک. روز ۶: به‌روزرسانی و reboot برنامه‌ریزی‌شده اگر لازم است. روز ۷: مرور دسترسی‌ها و مستند. این برنامه برای یک VPS تنها واقع‌بینانه است و فهرست اشتباه‌ها را از حالت شرمنده به حالت انجام‌شده می‌برد.

اگر ناوگان دارید، همان هفت روز را روی تصویر طلایی و خودکارسازی پیاده کنید نه روی هر ماشین دستی. مقیاس، دشمن قهرمانی دستی است.

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

از فهرست به تصویر طلایی

هدف نهایی این نیست که هر هفته همین فهرست را با شرم بخوانید؛ هدف این است که ضدالگوها در تصویر یا playbook پایه غیرممکن شوند: password SSH از روز صفر بسته، UFW فعال، مجوزهای وب‌روت قالب‌شده، عامل مانیتورینگ نصب، و مسیر بکاپ وصل. وقتی پیش‌فرض درست باشد، اشتباه رایج باید کارِ اضافه بخواهد نه کارِ پیش‌فرض.

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

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

شاخص سلامت عادت‌ها

ماهانه بپرسید: چند میزبان هنوز password SSH می‌پذیرند؟ چند تا UFW/SG ناهم‌تراز دارند؟ آخرین restore موفق کی بود؟ چند پورت listen بدون صاحب در موجودی‌اند؟ این چهار عدد بهتر از حس کلی «ما مواظبیم» وضعیت را نشان می‌دهند. وقتی عددها را روی دیوار تیم بگذارید، میانبر کمتر جذاب می‌شود.

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

این شاخص‌ها را در مرور ماهانهٔ زیرساخت کنار ظرفیت و هزینه بگذارید تا امنیت و بهداشت عملیاتی فقط وقتی به یاد نیاید که حادثه رخ داده است.

خلاصه

سرور لینوکس بیشتر از اینکه به ابزار عجیب نیاز داشته باشد، به نکردن کار خطرناک نیاز دارد. رمز روی SSH، فایروال رها، مجوز باز، root دائمی، دیسک بی‌هشدار و بکاپ تزئینی را از محیط‌تان حذف کنید. بعد سراغ سخت‌سازی ظریف‌تر بروید.

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

سرور داخلی پشت VPN هم این‌ها را می‌خواهد؟

بله با شدت کمتر روی سطح شبکه؛ اشتباه‌های مجوز، بکاپ و به‌روزرسانی همچنان گران‌اند.

آیا پورت SSH غیر۲۲ ضروری است؟

خیر به‌عنوان کنترل اصلی. نویز را کم می‌کند ولی جای کلید و فایروال را نمی‌گیرد.

چطور تیمی این لیست را زنده نگه داریم؟

چک‌لیست PR برای تغییر زیرساخت، آلارم‌های حداقل، و بازبینی فصلی دسترسی‌ها.

منابع و مراجع

• Ubuntu Server security how-to index: https://documentation.ubuntu.com/server/how-to/security/
• OpenSSH sshd_config(5): https://man.openbsd.org/sshd_config.5
• Ubuntu UFW documentation: https://documentation.ubuntu.com/server/how-to/security/firewalls/
• مقالات هم‌سری FutureForge: ۱۵۹ سخت‌سازی SSH، ۱۷۲ دیسک، ۱۷۳ حافظه، ۱۷۸ production، ۱۷۹ امنیت اوبونتو