WIUNIX ACADEMY
سخت‌سازی سرویس‌های systemd با آزمون و بازگشت امن
صفحهٔ 2 از 3؛ مراحل قبلی و پیش‌نیازها را پیش از ادامه مرور کن.
آموزش متناسب با محیط تو
کجا اجرا می‌کنی؟
سیستم‌عامل و نسخه را انتخاب کن تا مراحل، دستورها و راه‌حل‌ها برای همان محیط نمایش داده شوند.
آموزش متناسب با مقادیر تو
تنظیمات این آموزش
مقادیر نمونه را برای محیط خودت تنظیم کن؛ متن و دستورهای مرتبط با هم تغییر می‌کنند. رمز، کلید خصوصی و توکن وارد نکن. مقادیر فقط در همین زبانه نگهداری می‌شوند و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شوند. پیش از اجرا، DNS، گواهی‌ها و سیاست شبکهٔ واقعی را بررسی کن.
آی‌پی، دامنه یا پورت مثال‌ها با محیط تو فرق دارد؟ دکمهٔ زیر را باز کن، مقادیر را تغییر بده و «اعمال در آموزش» را بزن؛ سپس دستورهای به‌روز‌شده را کپی کن.
تنظیم مقادیر برای محیط من3 مقدار قابل‌تغییر
قدم بعدی
پس از خروج سرویس موقت، دید میزبان را بررسی کنید
namespace سرویس نباید mount میزبان را فقط‌خواندنی کرده باشد. فایل مجاز را بررسی کنید، نبود فایل ممنوع را ببینید و کنترل دوم را از خود میزبان بنویسید.
این نتیجه نشان می‌دهد محدودیت در محیط اجرای فرایند اعمال شده و نوشتن عادی میزبان برقرار مانده است. نام یا فایل متعلق به آزمایش هم‌زمان دیگری را به کار نبرید.
ترمینال همان میزبان معرفی‌شده در توضیح گام
sudo test -s '/var/lib/academy-sandbox-lab/state/allowed-inside'
sudo test ! -e '/var/lib/academy-sandbox-lab/forbidden-inside'
sudo sh -c 'printf control > "$1/control-after"' sh '/var/lib/academy-sandbox-lab'
sudo stat -c '%U %G %a %n' '/var/lib/academy-sandbox-lab/control-after'خروجی مجاز موجود است، فایل ممنوع وجود ندارد و میزبان همچنان در شاخهٔ خودش می‌نویسد.
محدودیت را با قرارداد واقعی برنامه تطبیق دهید
کاربر و گروه اختصاصی سرویس واقعی را حفظ کنید. /var/lib/example-app باید از نیاز واقعی برنامه آمده باشد. ReadWritePaths مالکیت Unix را عوض نمی‌کند و فایل‌سیستم زیربناییِ فقط‌خواندنی را هم نوشتنی نمی‌کند. فهرست مسیرها بین drop-inها ممکن است جمع شود؛ افزودن مسیر تازه، استثنای وسیع قبلی را لغو نمی‌کند.
ProtectSystem ارتباط با سوکت Unix قابل دسترس را قطع نمی‌کند و محدودیت‌های mount propagation دارد. فایل‌سیستم‌های API مستثنا هستند و PrivateTmp هم شاخهٔ موقت خصوصی نوشتنی می‌سازد. این آزمایش فقط اجازه یا منع نوشتن در دو مسیر مشخص را می‌سنجد، نه مهار فرایند مخرب root با capability باقی‌مانده.
قدم بعدی
فقط یک drop-in تازه برای همین سرویس بسازید
پس از توافق بر زمان تغییر و راه بازگشت، فایل مشخص این آموزش را به‌صورت انحصاری بسازید. اگر نامش موجود است متوقف شوید و مالک تنظیم را بررسی کنید؛ آن را بازنویسی نکنید.
فایل vendor و drop-inهای دیگر دست‌نخورده می‌مانند. ویرایش فقط در همین فایل تازه انجام می‌شود تا بازگشت نیز دقیق و محدود باشد.
ترمینال همان میزبان معرفی‌شده در توضیح گام
sudo install -d -m 0755 '/etc/systemd/system/example-app.service.d'
sudo sh -c 'set -C; : > "$1"' sh '/etc/systemd/system/example-app.service.d/90-academy-hardening.conf' || exit 1
sudoedit '/etc/systemd/system/example-app.service.d/90-academy-hardening.conf'فایل اختصاصی تازه برای ویرایش آماده است؛ فایل هم‌نام یا سیاست قبلی جایگزین نشده است.
مسیرهای مجاز برای نوشتن را محدود و مشخص نگه دارید
این قطعه نقطهٔ شروع یک سرویس معمولی پس از بررسی سازگاری است، نه نسخهٔ یکسان برای همهٔ برنامه‌ها. User و Group موجود را عوض نمی‌کند. مسیر نوشتنی باید به وضعیت لازم برنامه محدود باشد؛ در صورت تناسب می‌توانید از مدیریت بومی StateDirectory استفاده کنید.
برنامه‌ای که از فایل‌های خانه یا فایل موقت مشترک استفاده می‌کند، به تصمیم متناسب نیاز دارد. برای بهترشدن امتیاز، فیلتر syscall یا capability بی‌حساب اضافه نکنید.
محتوای فایل؛ این پنل را در ترمینال اجرا نکنید
[Service]
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes
ReadWritePaths=/var/lib/example-app
قدم بعدی
تنظیم ادغام‌شده را بررسی و همان سرویس را restart کنید
قبل از restart، verifier بومی و تنظیم ادغام‌شده را بررسی کنید. property ناشناخته، نادیده‌گرفته‌شده یا خطای namespace باید روشن شود. daemon-reload به‌تنهایی فرایند در حال اجرا را به sandbox تازه منتقل نمی‌کند.
restart وقفه ایجاد می‌کند و جای استقرار rolling، migration یا روند quorum خود برنامه نیست. فقط در پنجرهٔ مجاز و برای همین سرویس اجرا کنید؛ بعد لاگ و عملیات واقعی برنامه را ببینید.
ترمینال همان میزبان معرفی‌شده در توضیح گام
sudo systemd-analyze verify 'example-app.service' || exit 1
sudo systemctl daemon-reload
sudo systemctl cat 'example-app.service'
sudo systemctl restart 'example-app.service'
sudo systemctl status 'example-app.service' --no-pager
sudo journalctl -u 'example-app.service' --since '-5 min' --no-pager -n 80تنظیم مورد نظر بارگذاری شده و سرویس دوباره اجرا می‌شود؛ پذیرش نهایی به بررسی کارکرد واقعی برنامه وابسته است.
کار مجاز برنامه و مرز ممنوع را جدا بیازمایید
یک عملیات معمول برنامه، ماندگاری وضعیت، تحویل لاگ، DNS، ارتباط شبکه و سوکت‌های لازم را بررسی کنید. بعد با روش غیرمخرب خود برنامه، منع نوشتن در یک مسیر ممنوع را بسنجید.
فعال‌بودن unit کافی نیست. آزمایش موقت، پشتیبانی مکانیزم میزبان را نشان داده؛ سازگاری برنامه و اثر واقعی هر محدودیت باید جدا بررسی شود.