سرور دیروز مطابق policy بود، امروز یک تنظیم دستی عوض شده است. امشب هم انطباق را می‌سنجیم و هم یاد می‌گیریم اصلاح را به یک تغییر بازبینی‌پذیر تبدیل کنیم؛ ابزار خودکار نباید بی‌خبر درها را ببندد.

این جلسه بخشی از دورهٔ لینوکس ۳۰۳ در ۴۰ شب است.

محیط تمرین: Rocky Linux 9 Clone؛ openscap-scanner و scap-security-guide؛ sudo؛ Puppet تکمیلی و اختیاری.

جایگاه در دوره: هدف‌های 332.2 آزمون 303-300.

ارزیابی آسیب‌پذیری و انطباق متفاوت‌اند#

SCAP مجموعه‌ای از استانداردها برای بیان و ارزیابی اطلاعات امنیتی است. XCCDF چک‌لیست و نتایج policy را ساختار می‌دهد؛ OVAL برای بیان برخی آزمون‌های وضعیت و آسیب‌پذیری کاربرد دارد؛ CPE به شناسایی محصول مربوط است. وجود یک profile به معنی مناسب بودن آن برای هر سرویس نیست.

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

sudo dnf install openscap-scanner scap-security-guide
oscap --version
rpm -ql scap-security-guide

از فهرست بسته، data stream مخصوص محصول نصب‌شده را پیدا کن. نام فایل Rocky می‌تواند با RHEL فرق کند؛ از روی شمارهٔ ۹ به‌تنهایی انتخاب نکن. مسیر واقعی را در متغیر زیر قرار بده:

ds_file=/path/to/installed/product-ds.xml
oscap info "$ds_file"

خط مسیر placeholder است؛ باید پیش از اجرا با مسیر واقعی جایگزین شود. از خروجی info، Profile ID موجود و مناسب آزمایش را انتخاب کن:

profile_id=PROFILE_ID_FROM_OSCAP_INFO
sudo oscap xccdf eval --profile "$profile_id" \
  --results /tmp/lpic303-results.xml --report /tmp/lpic303-report.html \
  "$ds_file"

گزارش را محلی بخوان و فقط نسخهٔ پاک‌شده را به اشتراک بگذار. وضعیت notapplicable، notchecked، error و fail معنی یکسان ندارند. یک عدد امتیاز، شاهد برطرف شدن تمام ضعف‌ها نیست؛ خطای ابزار هم باید از عدم انطباق جدا شود.

از گزارش به تغییر کوچک#

یک rule ناموفق را انتخاب کن. علت، اثر تغییر بر سرویس، روش آزمون و راه برگشت را بنویس؛ سپس روی Clone فقط همان اصلاح را انجام بده و ارزیابی را دوباره اجرا کن. استفاده از --remediate یا playbook کامل بدون بازبینی می‌تواند ورود، شبکه و کاربرد اصلی را تغییر دهد.

جزوهٔ Puppet دربارهٔ «وضعیت مطلوب» ایدهٔ خوبی دارد، اما نصب Ubuntu 12.04 و فرمان‌های قدیمی آن را تکرار نمی‌کنیم. در VM دارای Puppet آماده، یک manifest محدود با نام catalog.pp می‌تواند چنین باشد:

file { '/tmp/lpic303-catalog.txt':
  ensure  => file,
  content => "managed catalog\n",
  mode    => '0644',
}

ابتدا puppet apply --noop catalog.pp را بخوان؛ سپس در آزمایشگاه apply کن. اجرای دوم نباید تغییر جدیدی لازم داشته باشد. این ویژگی را idempotence، یعنی رسیدن تکرارپذیر به وضعیت یکسان، می‌نامیم. فایل واقعی سرویس و اسرار را وارد این نمونه نکن.

مأموریت امشب#

یک استثنای policy برای نیاز واقعی کتابخانه بنویس: مالک، دلیل، تاریخ بازبینی و کنترل جبرانی. بدون این زمینه، گزارش قرمز را فقط سبز کرده‌ایم.

منابع: مستندات OpenSCAP ، ComplianceAsCode و مرجع نوع file در Puppet .