امن‌سازی Oracle Linux 9 (بخش ششم): امن‌سازی پردازش‌ها (Process Hardening) و مدیریت Core Dump

سیستم عامل و زیرساخت بازدید: 21

در قسمت قبل

امن‌سازی پیکربندی Bootloader (GRUB2)

انجام شد.

۱. الزامات CIS Benchmark (بخش ۱.۵)

این مقاله به پوشش و پیاده‌سازی بندهای زیر از استاندارد CIS در خصوص امن‌سازی سطح پردازش‌ها می‌پردازد:

  • 1.5.1 Ensure address space layout randomization is enabled (Automated)
  • 1.5.2 Ensure ptrace_scope is restricted (Automated)
  • 1.5.3 Ensure core dump backtraces are disabled (Automated)
  • 1.5.4 Ensure core dump storage is disabled (Automated)

 

۲. مفهوم و دلیل (Concept & Rationale)

در این بخش، سه مکانیزم حیاتی کرنل برای مقابله با سوءاستفاده از حافظه (Memory Exploits) پیکربندی می‌شوند:

  • ASLR (Address Space Layout Randomization): چیدمان آدرس‌های حافظه (مانند Stack، Heap و کتابخانه‌ها) را به‌صورت تصادفی درمی‌آورد. این کار باعث می‌شود مهاجمان نتوانند آدرس دقیق توابع حساس را در حافظه حدس بزنند و در نتیجه حملاتی نظیر Buffer Overflow به شدت محدود می‌شوند.
  • Ptrace Scope: قابلیت ptrace برای دیباگ کردن پردازش‌ها استفاده می‌شود. محدود کردن آن مانع از این می‌شود که یک پردازش معمولی بتواند حافظه پردازش‌های دیگر را بخواند (که یکی از روش‌های رایج برای سرقت کلمات عبور از حافظه است).
  • Core Dump: زمانی که یک برنامه کرش (Crash) می‌کند، سیستم‌عامل محتوای حافظه آن را در فایلی به نام Core Dump ذخیره می‌کند. استاندارد CIS الزام می‌کند که این ویژگی کاملاً غیرفعال شود تا اطلاعات حساس (نظیر کلیدهای رمزنگاری یا داده‌های درون حافظه) در فایل‌های روی دیسک نشت نکنند.

 

۳. بررسی سازگاری با پایگاه داده Oracle (RAC & Grid)

  • ASLR و Ptrace: مقادیر استاندارد و امن این دو پارامتر هیچ‌گونه تداخلی با کارکرد Oracle Database و Oracle Grid Infrastructure ندارند.
  • Core Dump (نکته حیاتی برای DBAها): غیرفعال کردن کامل Core Dump با نیازمندی‌های پشتیبانی اوراکل (Oracle Support / MOS) در تضاد است. در زمان بروز خطاهای بحرانی در سطح باینری (کرش شدید قبل از فعال شدن سیستم ADR اوراکل)، تیم پشتیبانی برای دیباگ و ارائه Patch به فایل Core Dump سیستم‌عامل نیاز دارد.
  • راهکار (Risk Acceptance): تولید Core Dump را برای تمامی کاربران سیستم غیرفعال می‌کنیم، اما یک استثنای صریح برای کاربران oracle و grid در نظر می‌گیریم. این یک توافق منطقی بین امنیت و عملیات در سرورهای دیتابیس است.

 

۴. نحوه بررسی وضعیت فعلی (Audit Script)

این اسکریپت وضعیت پارامترهای کرنل و محدودیت‌های اعمال‌شده برای Core Dump را بررسی می‌کند:

لینک این اسکریپت در github:

modules/audit_06_Process_Hardening_Core_Dump.sh

در صورتی که با bash script  آشنا نیستید، می توانید به آموزشی که برای دیتابیس ادمین ها در سایت گذاشته ام مراجعه کنید.

Bash for Oracle DBAs

#!/bin/bash
# Script: audit_cis_1_5.sh
# Purpose: Audit Process Hardening & Core Dumps (CIS 1.5)

echo "=========================================================================="
echo " CIS Requirement: 1.5 Process Hardening"
echo " - Ensure core dumps are restricted (systemd & limits.conf)."
echo " - Ensure ASLR is enabled (kernel.randomize_va_space=2)."
echo " - Ensure ptrace scope is restricted."
echo " Oracle Context:"
echo " 1. ASLR is fully supported and recommended by Oracle."
echo " 2. Core dumps MUST NOT be restricted for 'oracle' and 'grid' users."
echo "    They are required by Oracle Support for critical diagnostics (MOS)."
echo " 3. Restricting ptrace (scope=1) might require root privileges if DBA"
echo "    needs to run strace/pstack on running Oracle processes."
echo "=========================================================================="

FAIL_COUNT=0

echo -e "\n[*] 1. Checking Core Dump Limits (limits.conf)..."
# Using -h to hide filenames during grep, ensuring ^# works correctly.
LIMIT_CHECK=$(grep -h -r "^\s*\*\s\+hard\s\+core\s\+0" /etc/security/limits.conf /etc/security/limits.d/ 2>/dev/null)
if [ -n "$LIMIT_CHECK" ]; then
    echo -e "  \e[32m[PASS]\e[0m System-wide core dumps are disabled in limits.conf (* hard core 0)."
else
    echo -e "  \e[31m[FAIL]\e[0m System-wide core dumps are NOT explicitly disabled in limits.conf."
    FAIL_COUNT=$((FAIL_COUNT + 1))
fi

echo -e "\n[*] 2. Checking Oracle/Grid Core Dump Exceptions..."
ORA_LIMIT=$(grep -h -r "^\s*oracle\s\+hard\s\+core\s\+unlimited" /etc/security/limits.conf /etc/security/limits.d/ 2>/dev/null)
if [ -n "$ORA_LIMIT" ]; then
    echo -e "  \e[32m[PASS]\e[0m Oracle exceptions for core dumps are correctly configured."
else
    echo -e "  \e[33m[WARN]\e[0m Oracle exceptions for core dumps are missing. This impacts diagnostics."
    # Not failing the CIS check, but warning for Oracle context
fi

echo -e "\n[*] 3. Checking Systemd Coredump Configuration..."
# Checking both main conf and drop-in directories
SYSTEMD_CORE=$(grep -h -E "^\s*Storage\s*=\s*none" /etc/systemd/coredump.conf /etc/systemd/coredump.conf.d/*.conf 2>/dev/null)
if [ -n "$SYSTEMD_CORE" ]; then
    echo -e "  \e[32m[PASS]\e[0m Systemd coredump storage is set to 'none'."
else
    echo -e "  \e[31m[FAIL]\e[0m Systemd coredump storage is NOT set to 'none'."
    FAIL_COUNT=$((FAIL_COUNT + 1))
fi

echo -e "\n[*] 4. Checking ASLR (kernel.randomize_va_space)..."
ASLR=$(sysctl -n kernel.randomize_va_space 2>/dev/null)
if [ "$ASLR" == "2" ]; then
    echo -e "  \e[32m[PASS]\e[0m ASLR is enabled."
else
    echo -e "  \e[31m[FAIL]\e[0m ASLR is disabled or misconfigured (Current: $ASLR)."
    FAIL_COUNT=$((FAIL_COUNT + 1))
fi

echo -e "\n[*] 5. Checking Ptrace Scope (kernel.yama.ptrace_scope)..."
PTRACE=$(sysctl -n kernel.yama.ptrace_scope 2>/dev/null)
if [ "$PTRACE" -ge 1 ]; then
    echo -e "  \e[32m[PASS]\e[0m Ptrace scope is restricted (Current: $PTRACE)."
else
    echo -e "  \e[31m[FAIL]\e[0m Ptrace scope is NOT restricted (Current: $PTRACE)."
    FAIL_COUNT=$((FAIL_COUNT + 1))
fi

if [ "$FAIL_COUNT" -eq 0 ]; then
    echo -e "\n\e[32m[+] AUDIT RESULT: PASS\e[0m"
else
    echo -e "\n\e[31m[-] AUDIT RESULT: FAIL ($FAIL_COUNT issues found)\e[0m"
fi

۵. نحوه اعمال تنظیمات (Remediation Bash Script)

این اسکریپت پارامترهای امنیتی کرنل را تنظیم کرده و فایل محدودیت‌های Core Dump را با در نظر گرفتن استثنای کاربران اوراکل ایجاد می‌کند.

لینک این اسکریپت در github:

modules/remediate_06_Process_Hardening_Core_Dump.sh

 

#!/bin/bash
# Script: remediate_cis_1_5.sh
# Purpose: Apply Process Hardening and Core Dump Limits (CIS 1.5)

if [ "$EUID" -ne 0 ]; then echo "Please run as root"; exit 1; fi

echo -e "\n[+] Applying Remediation for Process Hardening (CIS 1.5)..."

# 1. System-wide and Oracle Specific Core Dump Limits
echo "[*] Configuring Core Dump limits with Oracle exceptions..."
cat <<EOF > /etc/security/limits.d/99-disable_core.conf
# CIS 1.5.1: Disable core dumps for all users to prevent info leaks
* hard core 0

# Oracle Exception: Required for Oracle Database / Grid Diagnostics (MOS)
oracle soft core unlimited
oracle hard core unlimited
grid soft core unlimited
grid hard core unlimited
EOF
echo "  [+] Set limits in /etc/security/limits.d/99-disable_core.conf"

# 2. Systemd Coredump Configuration (OL9 Requirement)
echo "[*] Configuring systemd-coredump..."
mkdir -p /etc/systemd/coredump.conf.d/
cat <<EOF > /etc/systemd/coredump.conf.d/99-cis.conf
[Coredump]
Storage=none
ProcessSizeMax=0
EOF
systemctl daemon-reload
echo "  [+] Set Storage=none in systemd coredump config."

# 3. Sysctl Parameters for ASLR and Ptrace
echo "[*] Configuring kernel parameters (ASLR & Ptrace)..."
cat <<EOF > /etc/sysctl.d/50-process-hardening.conf
# CIS 1.5.2: Enable ASLR
kernel.randomize_va_space = 2
# CIS 1.5.3: Restrict Ptrace
kernel.yama.ptrace_scope = 1
EOF

# Apply sysctl parameters
sysctl -q -p /etc/sysctl.d/50-process-hardening.conf
echo "  [+] Applied kernel.randomize_va_space=2 and kernel.yama.ptrace_scope=1"

echo -e "\n[+] Process hardening applied successfully."

در قسمت بعد به سراغ:

پیکربندی سیاست رمزنگاری سراسری

می رویم