انجین‌اکس؛ شب ۴۹: اصلاح یافته‌های ممیزی و آزمون بازگشت
فهرست نوشته
هر یافتهٔ audit باید به تغییر قابل بررسی تبدیل شود. امشب یکی از موارد نامطابق واقعی را اصلاح می‌کنیم، اثر آن بر برنامه را می‌سنجیم و استثنای لازم را با دلیل ثبت می‌کنیم.
این جلسه بخشی از دورهٔ انجین‌اکس در ۵۰ شب است. قرارداد آزمایشگاه، مسیرها و روال اعمال تغییر در راهنمای دوره آمده است.
محیط: worksheet شب ۴۸، benchmark مشخص، backup config و Snapshot؛ نتیجهٔ baseline برای درخواست‌های سالم/منفی ثبت شده است. فهرست عمومی این درس جای شماره و متن کنترل‌های PDF را نمی‌گیرد.
تغییر کوچک با شاهد قبل و بعد#
مثلاً اگر status روی همهٔ addressها منتشر شده، آن را مثل شب ۴۷ به loopback محدود کن؛ اگر worker می‌تواند config را بنویسد، owner/mode و ACL واقعی مسیر را اصلاح کن؛ اگر backend TLS verify خاموش است، chain/name را طبق شب ۲۴ درست کن و verify را فعال کن. یافته‌ای را که در ماشین خودت مشاهده نشده، با نتیجهٔ فرضی pass/fail گزارش نکن.
برای هر مورد ثبت کن: کنترل دقیق، رفتار قبلی، فایل/line تغییر، دلیل، آزمون موفقیت و روش rollback. فقط همان مورد را اصلاح کن و nginx -t بگیر؛ روی failure reload نکن. برای firewall و systemd که restart/قطع دسترسی دارند، ابتدا console و زمان بازگشت را آماده کن.
روش HTTP مطابق نیاز برنامه#
اگر سیاست سازمان methodهای مجاز را مشخص کرده است، آن را با WordPress، REST، preflight و API واقعی تطبیق بده. بستن همهٔ POSTها login و upload را خراب می‌کند. نمونهٔ آموزشی در http برای یک سایت ساده:
map $request_method $lab_method_allowed {
default 0;
GET 1;
HEAD 1;
}
در server سایت static:
if ($lab_method_allowed = 0) { return 405; }
if فقط برای return در این مثال استفاده شده است؛ آن را به rewrite/پراکسی پیچیده گسترش نده. GET و HEAD باید سالم و POST/TRACE در همین سایت 405 باشند. WordPress این policy را به ارث نگیرد؛ برای آن فهرست متناسب و آزمون مستقل لازم است. این مثال را بدون تطبیق شمارهٔ واقعی PDF «کنترل شمارهٔ X از CIS» ننام.
regression در چند مسیر#
| مسیر | چه چیزی باید دوباره بررسی شود؟ |
|---|---|
| static/TLS | نام صحیح و ناشناخته، 200/404، هدرها، HTTP/2 |
| مدیریت | IP مجاز/غیرمجاز، credential غلط، هدر XFF جعلی |
| برنامه | URI، redirect/cookie، WSS، SSE، timeout و failure |
| WordPress | login، permalink، upload، cron، عدم اجرای PHP upload |
| WAF | درخواست سالم، probe کنترل‌شده و دامنهٔ استثنا |
| کانتینر | user/mount/port، DNS بعد recreate، drain و rollback |
| stream | ACL TCP/UDP، failover، SNI و دوطرف PROXY protocol |
استفاده از curl -I فقط HEAD را می‌سنجد؛ برای GET، body و header هر دو را بررسی کن. payload یا دادهٔ خصوصی را وارد گزارش نکن. برای rate limit، وضعیت واقعی 429 و log لازم است؛ افزودن دستور روی دیسک کافی نیست.
استثنای پذیرفته‌شده#
اگر یک کنترل طبق scope قابل اعمال نیست یا با نیاز برنامه تعارض دارد، شماره/نسخه، دلیل، ریسک مشخص، کنترل جبرانی، مسئول و تاریخ بازبینی را ثبت کن. استثنا را pass تبدیل نکن و جمع امتیاز چند benchmark متفاوت را با هم مخلوط نکن. افزایش امتیاز scanner اگر backup، TLS یا WordPress خراب شده باشد نتیجهٔ عملی مناسب نیست.
بازگشت: config/permission/drop-in قبلی همان تغییر را برگردان، validate و reload/restart متناسب کن؛ سپس شاهد runtime تازه بگیر. بررسی نهایی را با evidence تازه به همان worksheet پیوند بده.
منبع: CIS NGINX ، map ، return در rewrite module .