فراتر از «ارتقای مناسب»: خودکارسازی سخت شدن لینوکس برای بارهای کاری بخش عمومی

0 0 خواندن این مطلب 5 دقیقه زمان میبرد

فراتر از «ارتقای مناسب»: خودکارسازی سخت شدن لینوکس برای بارهای کاری بخش عمومی

پیشنهاد ویژه

خرید فالوور واقعی خرید لایک اینستاگرام خرید ویو اینستاگرام خرید فالوور اینستاگرام

خلاصه محتوای ارسالی با محدودیت 200 کلمه به زبان فارسی:

یک تصور غلط رایج، برابر دانستن امنیت با پایداری نسخه‌های LTS اوبونتو یا دبیان است، در حالی که این توزیع‌ها فقط ثبات ارائه می‌دهند، نه加固 (Hardening). سیستم‌های استاندارد ابری برای سازگاری طراحی شده‌اند، در حالی که سیستم‌های hardened بر اساس استانداردهایی مانند BSI یا CIS، برای ایزوله‌سازی و حسابرسی بهینه شده‌اند و این دو فلسفه طراحی در تضاد هستند. در محیط‌های انطباقی مانند BSI IT-Grundschutz یا GDPR، سخت‌سازی دستی یک روش اشتباه است، زیرا غیرقابل مقیاس‌سازی، پرخطا و وابسته به حافظه انسانی است.

این مقاله معماری یک خط لوله خودکار برای سخت‌سازی سرور بدون نیاز انسانی را تشریح می‌کند. تمرکز بر کاهش سطح حمله استاندارد با مکانیزم‌های زیر است:

SSH: تغییر پورت (مثلاً 2222)، غیرفعال‌سازی احراز هویت رمزعبور و اعمال الگوهای رمزنگاری پیشرفته.
هسته تنظیمات امنیتی (Sysctl): غیرفعال‌سازی پذیرش перенапراهای ICMP، محدود‌سازی دسترسی به لاگ‌های سیستم (dmesg) و غیرفعال‌سازی eBPR غیرمجاز.
حسابرسی (Auditd): ثبت تمام اجرای دستورات توسط کاربران عادی برای ردیابی بدافزارها.

این رویکرد کد-محور (نه مستندسازی) با استفاده از ماژول‌های اجرایی حالت (state)، ناتوانی (idempotency) و قابلیت ردیابی تغییرات از طریق کنترل نسخه را فراهم می‌کند. نویسنده با تأکید بر اینکه امنیت یک حالت پیکربندی است، پیشنهاد می‌کند از پیش‌فرض‌های توزیع لینوکس فاصله گرفته و加固 خود را کاملاً خودسازی شود. مخزن "hardened-vps-bootstrap" پیاده‌سازی عملی این ایده است.

یک تصور غلط رایج در بخش عمومی فناوری اطلاعات وجود دارد که استقرار نسخه LTS از اوبونتو یا دبیان مستلزم یک پایه امنیت است. این کار را نمی کند. این به معنای ثبات است، نه سخت شدن.

یک تصویر ابر استاندارد برای طراحی شده است سازگاری و کاهش اصطکاک سواری. برای اطمینان از آن مهندسی شده است ssh root@ بلافاصله کار می کند برعکس، یک سیستم سازگار با BSI یا سیستم سخت شده با CIS برای این طراحی شده است انزوا و قابلیت حسابرسی. این دو فلسفه طراحی متقابل هستند.

در محیط‌های تنظیم‌شده – به‌ویژه تحت BSI IT-Grundschutz (SYS.1.3) یا GDPR Art. 32 الزامات – سخت شدن دستی یک ضد الگو است. اگر در حال ویرایش هستید /etc/ssh/sshd_config در سال 2025، شما قبلاً در ممیزی شکست خورده اید. اگر روش پیکربندی شما به حافظه انسانی متکی باشد، نمی توانید ثبات را در 50 گره ثابت کنید.

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

فهرست مطالب

شکاف انطباق

هنگامی که ما یک تصویر جدید Debian 12 یا Ubuntu 24.04 را مستقر می کنیم، بلافاصله بدهی فنی را به ارث می بریم. بیایید به دلتای بین حالت «نصب تازه» و «آماده انطباق» نگاه کنیم:

جزء	حالت پیش فرض	دولت مورد نیاز (CIS/BSI)	خطر
SSH	پورت 22، رمز عبور	پورت 2222 (معروف)، فقط کلید، سیاست های رمزنگاری	بات‌نت‌های Brute-Force، Credential Stuffing
هسته	انتقال IPv4 غیرفعال است (بیشتر)، تغییر مسیرهای ICMP فعال است	`accept_redirects=0`، `dmesg_restrict=1`، `bpf_jit_harden=2`	MITM، نشت اشاره گر هسته، بهره برداری های eBPF
حسابرسی	`auditd` بسته اغلب گم شده است	قوانین برای `execve`، `passwd`، `sudo`	هیچ دنباله پزشکی قانونی برای افزایش امتیاز
FS	`/tmp` قابل اجرا	`noexec`، `nosuid`، `nodev` روی tmpfs	اجرای بدافزار در فهرست‌های قابل نوشتن در جهان

معماری یک خط لوله سخت کاری خودکار

ما “اسکریپت” نمی نویسیم. ما می نویسیم ماژول های اجرایی دولت. چه از Ansible، چه Salt یا یک چارچوب پوسته بوت استرپ استفاده کنید، منطق یکسان باقی می ماند.

مخزن hardened-vps-bootstrap (پیوند زیر) این منطق را در Bash خالص پیاده سازی می کند تا بدون وابستگی به سیستم های دارای شکاف هوا باقی بماند.

1. SSH: سیاست رمزنگاری و مبهم

تغییر پورت SSH بحث برانگیز است. ناب گرایان استدلال می کنند که این “امنیت از طریق ابهام” است. در عمل، انتقال SSH به پورت 2222 (یا بالاتر) نویز ورود به سیستم را تقریباً 99٪ کاهش می دهد. این در مورد پنهان شدن از یک مهاجم هدف نیست. این در مورد کاهش نسبت سیگنال به نویز است تا SIEM شما بتواند در واقع مهاجم هدف را شناسایی کند.

پیاده سازی:

اجبار رمزهای پست کوانتومی و با امنیت بالا
echo “Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com” >> /etc/ssh/sshd_config
echo “KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256” >> /etc/ssh/sshd_config
echo “MACs hmac-sha2-512-etm@openssh.com” >> /etc/ssh/sshd_config

غیرفعال کردن Legacy Auth
sed -i ‘s/^#?PasswordAuthentication./PasswordAuthentication no/’ /etc/ssh/sshd_config
sed -i ‘s/^#?PermitRootLogin./PermitRootLogin no/’ /etc/ssh/sshd_config

متن

ما به صراحت غیرفعال می کنیم PasswordAuthentication. تکیه بر گذرواژه‌های ضعیف در دوره‌ای از کلاسترهای کرک با شتاب GPU، سهل انگاری است.

2. سخت شدن هسته: لایه خاموش

پشته شبکه هسته به طور پیش فرض مجاز است. ما باید مدیریت ICMP و دسترسی به حافظه را قفل کنیم.

پارامترهای کلیدی Sysctl:

net.ipv4.tcp_syncookies = 1: حفاظت اساسی در برابر حملات DoS سیل SYN.
net.ipv4.conf.all.accept_redirects = 0: از دستکاری یک روتر سرکش در همان زیرشبکه جلوگیری می کند.
kernel.dmesg_restrict = 1: از مشاهده بافر حلقه هسته توسط کاربران غیرمجاز جلوگیری می کند (dmesg) که می تواند آدرس های حافظه مفید برای توسعه اکسپلویت (بای پس ASLR) را افشا کند.
kernel.unprivileged_bpf_disabled = 1: استفاده غیرمجاز eBPF را غیرفعال می کند. آسیب‌پذیری‌های اخیر هسته اغلب از eBPF استفاده می‌کنند. اگر برنامه وب شما به آن نیاز ندارد، آن را غیرفعال کنید.

3. مسیرهای حسابرسی: “ضبط کننده پرواز”

در حال نصب auditd بدون قوانین بی فایده است مجموعه قوانین استاندارد اغلب بردار بحرانی را از دست می دهند: اعدام.

ما باید بدانیم چی دستورات اجرا شدند، نه فقط سازمان بهداشت جهانی وارد شده است.

/etc/audit/rules.d/exec.rules
تمام اجرای دستورات (sys_execve) را برای UIDهای معتبر ضبط کنید
-a always,exit -F arch=b64 -S execve -F euid>=1000 -F euid!=4294967295 -k audit_cmd

متن

این تضمین می کند که اگر یک مهاجم موفق به اجرا شود ./exploit.sh، رویداد اجرا – از جمله آرگومان ها – به سیستم وارد می شود /var/log/audit/audit.log.

اتوماسیون در مقابل مستندسازی

یک runbook از لحظه ای که نوشته می شود مرده است. کد زنده است

با کپسوله کردن این مراحل سخت شدن در یک مخزن، به موارد زیر دست پیدا می کنیم:

ناتوانی: اجرای مجدد اسکریپت مجدداً حالت را اجرا می کند (دریفت تصحیح).
کنترل نسخه: ما می توانیم ردیابی کنیم چه زمانی تصمیم گرفتیم غیرفعال کنیم UsePAM از طریق Git commit history.
سرعت: میانگین زمان برای بازیابی (MTTR) به طور قابل توجهی کاهش می یابد زمانی که تامین سرور خودکار است.

مخزن “Hardened VPS Bootstrap”.

من چارچوب داخلی را که برای پروژه‌های زیرساختی بخش عمومی استفاده می‌کنم منبع باز کرده‌ام. این طراحی شده است که:

حداقل: بدون وابستگی پایتون/روبی.
مدولار: فعال/غیرفعال کردن ویژگی ها از طریق پرچم
آماده حسابرسی: هر تغییری که ایجاد می کند را ثبت می کند.

SSH، Sysctl، Fail2Ban/CrowdSec، UFW و به‌روزرسانی‌های خودکار را پوشش می‌دهد.

👉 مخزن GitHub: patrick-bloem/hardened-vps-bootstrap

افکار نهایی

امنیت یک محصول نیست. این یک وضعیت پیکربندی است. توزیع‌های استاندارد لینوکس تجربه «خارج از جعبه» را در اولویت قرار می‌دهند. به عنوان مهندسان زیرساخت، وظیفه ما این است که این اولویت را به سمت «ایمن با طراحی» قرار دهیم.

اعتماد به پیش فرض ها را متوقف کنید. sysctls خود را تأیید کنید. سخت شدن خود را خودکار کنید

درباره نویسنده
پاتریک بلوم یک مهندس ارشد زیرساخت متخصص در محیط های لینوکس سازگار با BSI، راه حل های ذخیره سازی ZFS و جداسازی شبکه در بخش عمومی است.