คู่มือใช้งาน IPradr PHP Guard Pack v1.1.0
จัดทำ 24 ตุลาคม 2569

เริ่มต้น: อ่านขอบเขตให้ตรงกับงาน
แพ็กนี้ตรวจ PHP และช่วย hardening บางส่วน ไม่ใช่โปรแกรมติดตั้งแพตช์ PHP2Shell อัตโนมัติ การแก้ต้นเหตุต้องอัปเดต PHP จากผู้ผลิต และตรวจแพตช์ backport ของระบบที่ใช้งาน
Linux มีตรวจไฟล์แบบ polling และแก้ INI 4 ค่า พร้อม backup/rollback; Windows และ Docker มีสคริปต์ตรวจและคู่มือแก้ไข ยังไม่เปลี่ยนระบบให้อัตโนมัติ
ควรเริ่มบน staging และใช้เฉพาะระบบที่รับผิดชอบ ผลตรวจ CLI ไม่ยืนยัน runtime ของเว็บไซต์

เตรียมพร้อมก่อนเริ่ม
ต้องมี Python 3.9 ขึ้นไป ไม่ต้อง pip install; บน Windows ใช้ py -3 หรือ python ตามการติดตั้ง
ใช้โฟลเดอร์ที่ผู้ดูแลเขียนได้เท่านั้น เก็บรายงานและ baseline เป็นข้อมูลภายใน ไม่เก็บใน web root
สำหรับ Docker ต้องมี Docker CLI และสิทธิ์เข้าถึง daemon พร้อมชื่อ container ที่ต้องการตรวจ
ชื่อไฟล์รายงานในตัวอย่างเป็นตัวอย่าง ให้เปลี่ยนชื่อเมื่อรันครั้งถัดไป โดยตัวตรวจข้ามแพลตฟอร์มจะปฏิเสธการทับไฟล์เดิม

Linux — ขั้นตอนที่ 1: ดาวน์โหลดและตรวจไฟล์
ดาวน์โหลด ZIP และ SHA-256 จากหน้า https://h.sran.net/phpguard แล้วเปิด Terminal ในโฟลเดอร์ดาวน์โหลด
    sha256sum -c ipradr-phpguard-pack-v1.1.0.zip.sha256
ผลที่ต้องได้คือ OK หากค่าไม่ตรงให้หยุดและดาวน์โหลดใหม่ ไฟล์ checksum ต้องอยู่โฟลเดอร์เดียวกับ ZIP
แตกไฟล์แล้วเข้าโฟลเดอร์ phpguard:
    unzip ipradr-phpguard-pack-v1.1.0.zip
    cd phpguard
    python3 --version
    python3 phpguard.py --help
หากไม่มี unzip ให้ใช้โปรแกรมแตก ZIP ของระบบ รุ่น Python ต้องไม่น้อยกว่า 3.9

Linux — ขั้นตอนที่ 2: ติดตั้งและตรวจระบบก่อนแก้ไข
รันจากโฟลเดอร์ phpguard ที่แตกแล้ว:
    sudo install -d -m 0755 /opt/phpguard
    sudo install -m 0755 phpguard.py /opt/phpguard/phpguard.py
    sudo install -m 0644 phpguard_common.py /opt/phpguard/phpguard_common.py
    sudo install -d -m 0700 /var/lib/phpguard
    sudo python3 /opt/phpguard/phpguard.py audit --output /var/lib/phpguard/audit-before.json
เปิดรายงานด้วย:
    sudo less /var/lib/phpguard/audit-before.json
ตรวจ runtimes, version, assessment, ini_files, packages และ services ถ้าคำสั่งย่อยมี error หรือ returncode ไม่ใช่ 0 ต้องตรวจเพิ่มเติม ไม่ถือว่าเครื่องปลอดภัย
ตรวจ Apache/Nginx virtual host และ FPM pool ให้ทราบว่าเว็บไซต์ใช้ PHP ตัวใดจริง อย่าใช้ php -v ของ CLI เพียงอย่างเดียวตัดสินทุกเว็บไซต์

Linux — ขั้นตอนที่ 3: ประเมินแพตช์และสำรอง
สถานะ version_match_vendor_patch_unverified หมายถึงหมายเลขเข้าข่าย แต่ยังไม่ตรวจแพตช์ backport; at_or_above_upstream_fix หมายถึงถึงเกณฑ์ upstream ของกฎที่มี ไม่ได้ยืนยันปลอดภัยจากทุกช่องโหว่
unknown, collection_failed, outside_reviewed_branches, prerelease_manual_review และ vendor_build_manual_review ต้องตรวจเพิ่มเติม ไม่ใช่ผลผ่าน
เกณฑ์กฎวันที่ 24 ตุลาคม 2569 คือ PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 สำหรับ CVE-2026-109618 และ CVE-2026-109619 ตรวจประกาศผู้ผลิตและเลือก release ที่ยังสนับสนุน
สำรองฐานข้อมูล โค้ด และ configuration ด้วยเครื่องมือสำรองที่องค์กรใช้ ทดสอบกู้คืน และกำหนดช่วงบำรุงรักษา สคริปต์ไม่ได้สำรองฐานข้อมูลหรือแอปทั้งหมดให้

Linux — ขั้นตอนที่ 4: สร้าง baseline จากระบบที่เชื่อถือได้
เลือกเฉพาะโฟลเดอร์ที่มีอยู่จริงและปกติไม่เปลี่ยน เช่น source code และ configuration ตัวอย่างนี้ต้องเปลี่ยนพาธให้ตรงระบบ:
    sudo python3 /opt/phpguard/phpguard.py baseline --paths /var/www/html /etc/php /etc/nginx --output /var/lib/phpguard/baseline-before.json
ถ้าใช้ Apache หรือไม่มี /etc/nginx ให้เปลี่ยนเป็นพาธที่มีอยู่จริง การอ่านไม่ครบจะทำให้สร้าง baseline ไม่สำเร็จ
เก็บ baseline นอกพาธที่เฝ้าระวังและสำเนานอกเครื่อง หลีกเลี่ยง cache/session/log ที่เปลี่ยนตลอด หากเลือก upload directory ต้องแยกแยะไฟล์ใหม่ที่เกิดจากงานปกติด้วย
Baseline ไม่ใช่ backup และการตรง baseline ไม่ได้ยืนยันว่าเครื่องไม่เคยถูกบุกรุก

Linux — ขั้นตอนที่ 5: สร้างแผน hardening
เลือก php.ini ที่เว็บไซต์ใช้จริง ตัวอย่าง PHP 8.3 FPM:
    sudo python3 /opt/phpguard/phpguard.py plan --ini /etc/php/8.3/fpm/php.ini --output /var/lib/phpguard/plan.json
    sudo less /var/lib/phpguard/plan.json
แผนจะปรับ expose_php=Off, display_errors=Off, display_startup_errors=Off และ log_errors=On เท่านั้น ตรวจปลายทาง error log ว่าเขียนได้และมี log rotation
plan/apply แสดง overrides เมื่อพบไฟล์ INI ที่อาจตั้งค่าทับใน conf.d หรือ PHP_INI_SCAN_DIR; หาก apply รายงาน configuration_written_but_overridden ให้ตรวจรายการและใช้ verify ยืนยันค่า effective อีกครั้ง รายการนี้เป็นการเตือนจากพาธที่ตรวจได้ ไม่ยืนยันลำดับโหลดทั้งหมดของทุกระบบ
plan ยังไม่แก้ไฟล์ PHP และไม่ติดตั้งแพตช์ ตรวจพาธให้ถูกก่อนขั้นตอน apply
หากพบ symlink, per-host/path INI หรือรูปแบบไฟล์ที่ไม่รองรับ ให้ตรวจแก้ด้วยวิธีของระบบ ไม่บังคับข้ามข้อจำกัด

Linux — ขั้นตอนที่ 6: ใช้แผนและตรวจ configuration
หลังตรวจแผนและพร้อมช่วงบำรุงรักษา:
    sudo python3 /opt/phpguard/phpguard.py apply --plan /var/lib/phpguard/plan.json --backup-dir /var/lib/phpguard/backups --confirm
เมื่อมีการแก้ไข ผลจะระบุพาธ receipt.json ให้เก็บไว้เพื่อย้อนกลับ โปรแกรมตรวจ hash และสำรอง INI ก่อนเขียน แต่ไม่ restart บริการ; หากค่าเหมือนเดิมจะแสดง no_change โดยไม่สร้าง backup เพิ่ม
หากแจ้ง File or plan changed ให้ตรวจไฟล์ล่าสุดและสร้างแผนใหม่ ห้ามแก้ hash ในแผนเพื่อบังคับใช้
ตรวจ syntax ด้วย executable ที่ระบบใช้จริง ตัวอย่างกรณีมี PHP 8.3 FPM:
    sudo /usr/sbin/php-fpm8.3 -t
หากไม่มี binary นี้ให้ใช้ชื่อและวิธีตรวจ configuration ของระบบจริง เมื่อตรวจผ่านแล้วจึง restart เฉพาะบริการที่เกี่ยวข้องตามแผนบำรุงรักษา
Hardening ไม่ได้แก้ PHP2Shell ต้องติดตั้งแพตช์ผ่านผู้จำหน่ายหรือ repository ที่ระบบรองรับ พร้อมอัปเดต extensions ให้เข้ากันและทดสอบบน staging ก่อน

Linux — ขั้นตอนที่ 7: ตรวจหลังแก้ไข
    sudo python3 /opt/phpguard/phpguard.py verify --output /var/lib/phpguard/audit-after.json
เปรียบเทียบกับ audit-before.json คำสั่ง verify อ่านค่า effective จาก PHP/php-fpm -i และเทียบ INI 4 ค่า: exit 0 ทุก runtime ตรง, exit 1 มีค่าที่ไม่ตรง, exit 2 เก็บข้อมูลไม่ครบ; ยังต้องตรวจ override ต่อเว็บไซต์/pool และทดสอบแอปจริง
ตรวจ PHP runtime ทุกเว็บไซต์/pool และทุก replica ผ่านช่องทางภายใน ตรวจค่าที่อาจ override จาก conf.d, pool หรือ .user.ini ห้ามเปิด phpinfo สู่สาธารณะ
ทดสอบ HTTP/HTTPS, login, session, upload, ฐานข้อมูล และงานตามเวลา ตรวจ error log และ HTTP 5xx
เมื่อยอมรับการเปลี่ยนแปลงแล้ว สร้าง baseline ใหม่ชื่อ baseline.json สำหรับงานเฝ้าระวัง โดยใช้ --paths ชุดเดิมและเก็บ baseline-before.json ไว้เปรียบเทียบ

Linux — ขั้นตอนที่ 8: เปิดเฝ้าระวัง
ตรวจครั้งเดียวก่อน:
    sudo python3 /opt/phpguard/phpguard.py check --baseline /var/lib/phpguard/baseline.json --output /var/lib/phpguard/check.json
    echo $?
Exit 0: ไม่เปลี่ยนจาก baseline; 1: พบเปลี่ยนแปลง; 2: ผิดพลาดหรือข้อมูลไม่ครบ
เฝ้าระวังใน Terminal:
    sudo python3 /opt/phpguard/phpguard.py watch --baseline /var/lib/phpguard/baseline.json --output /var/lib/phpguard/latest-check.json --interval 300
กด Ctrl+C เพื่อหยุด หรือใช้ systemd จากโฟลเดอร์ที่แตกแพ็ก:
    sudo install -m 0644 phpguard-watch.service /etc/systemd/system/phpguard-watch.service
    sudo systemctl daemon-reload
    sudo systemctl enable --now phpguard-watch.service
    sudo systemctl status phpguard-watch.service
    sudo journalctl -u phpguard-watch.service -n 50
unit ตั้ง ProtectHome=read-only จึงอ่านเว็บใต้ /home ได้ แต่เขียนไม่ได้ ใช้ latest-check.json ดูผลรอบล่าสุดและ journal ดูเหตุการณ์ก่อนหน้า
หยุดบริการ:
    sudo systemctl disable --now phpguard-watch.service
การตรวจเป็นรอบอาจพลาดไฟล์ที่ถูกสร้างแล้วลบระหว่างรอบ ยังไม่มีการตรวจ process แบบ real-time

Linux — ย้อนกลับเมื่อ configuration มีปัญหา
ใช้ receipt ที่ได้จาก apply โดยเปลี่ยนชื่อรายการเป็นพาธจริง:
    sudo python3 /opt/phpguard/phpguard.py rollback --receipt /var/lib/phpguard/backups/ชื่อรายการ/receipt.json --confirm
ตรวจ configuration และ restart บริการที่เกี่ยวข้องตามคู่มือระบบอีกครั้ง หากไฟล์เปลี่ยนหลัง apply หรือ backup เสียหาย สคริปต์จะปฏิเสธ rollback
คำสั่งนี้กู้คืนเฉพาะ INI ไม่ย้อนแพ็กเกจหรือฐานข้อมูล หากย้อนสู่ PHP รุ่นเสี่ยงให้จำกัดการเข้าถึงจนมีรุ่นแก้ไขที่ใช้ได้

Windows — ขั้นตอนที่ 1: ตรวจไฟล์และเตรียมเครื่อง
ดาวน์โหลด ZIP และ SHA-256 เปิด PowerShell ในโฟลเดอร์ดาวน์โหลด:
    Get-FileHash .\ipradr-phpguard-pack-v1.1.0.zip -Algorithm SHA256
เทียบค่า hash กับไฟล์ .sha256 หากตรงจึงแตกไฟล์ด้วย Extract All แล้วเปิด PowerShell ในโฟลเดอร์ phpguard
    py -3 --version
ใช้ Python 3.9 ขึ้นไป หากไม่มี py launcher ใช้ python แทน ตั้ง NTFS ACL ของโฟลเดอร์รายงานเฉพาะผู้ดูแล

Windows — ขั้นตอนที่ 2: ตรวจ PHP ทุกชุดที่เว็บไซต์ใช้
ตัวอย่างพาธต้องเปลี่ยนให้ตรงเครื่อง:
    py -3 .\phpguard-pack.py --php-bin 'C:\PHP\php.exe' --output '.\audit-windows-before.json'
หากมีหลายชุดให้เพิ่ม --php-bin 'C:\พาธอีกชุด\php.exe' ในคำสั่งเดียวกัน
เปิด JSON ตรวจ collection_status, assessment และหลักฐานคำสั่ง หาก incomplete โปรแกรมออกด้วย exit code 2 ให้ตรวจ path/สิทธิ์/สถานะ container แล้วใช้ชื่อรายงานใหม่รันซ้ำ; complete หมายถึงเก็บข้อมูลครบ ไม่ได้แปลว่าปลอดภัย
ตรวจ IIS Handler Mappings/FastCGI หรือ Apache configuration ว่าชี้ binary ไหน php.exe บน PATH อาจต่างจาก php-cgi.exe ที่เว็บใช้

Windows — ขั้นตอนที่ 3: สำรองและเปลี่ยน PHP รุ่นแก้ไข
สำรองเว็บไซต์ ฐานข้อมูล php.ini และ configuration ของ IIS/Apache พร้อมทดสอบกู้คืน
เลือก PHP build จากผู้ผลิตที่ตรง architecture, Thread Safety, runtime dependencies และ extensions ทดสอบ staging ก่อน
ติดตั้งรุ่นใหม่ในโฟลเดอร์แยก เปลี่ยน handler/FastCGI path ตามคู่มือผู้ผลิต แล้ว recycle เฉพาะ application pool หรือ process ที่เกี่ยวข้องในช่วงบำรุงรักษา
หากใช้ชุดโฮสติ้ง/XAMPP/WAMP ให้ใช้กระบวนการอัปเดตที่ผู้จำหน่ายรองรับ ไม่ทับ binary แบบเดาสุ่ม
แพ็ก v1.1.0 ไม่มี apply/rollback สำหรับ Windows ห้ามนำ Linux phpguard.py มาใช้แทน

Windows — ขั้นตอนที่ 4: ตรวจผล
รัน phpguard-pack.py อีกครั้งด้วยพาธรุ่นใหม่และ --output '.\audit-windows-after.json'
ตรวจ runtime ของเว็บไซต์จริงและทุก application pool ทดสอบ login/session/upload/ฐานข้อมูลและ error log
ปรับ NTFS ACL ให้บัญชีเว็บเขียนเฉพาะที่จำเป็น และปิดการรัน PHP ใน upload directory ตามการตั้งค่าของเว็บเซิร์ฟเวอร์ โดยทดสอบผลกระทบก่อน
เก็บรายงานก่อน–หลังและหลักฐานแพตช์ โปรแกรมยังไม่ตรวจ ACL หรือ event log ของ Windows ให้อัตโนมัติ

Docker — ขั้นตอนที่ 1: เลือก container และตรวจ
รันจาก Host ที่มี Docker CLI และสิทธิ์เข้าถึง daemon:
    docker ps --format '{{.Names}}'
    python3 phpguard-pack.py --container YOUR_CONTAINER --output audit-docker-before.json
แทน YOUR_CONTAINER ด้วยชื่อจริง บน Windows ใช้ py -3 แทน python3
ถ้า PHP ไม่อยู่ใน PATH ให้เพิ่ม --container-php /พาธจริง/php
container ต้องกำลังทำงาน ตัวตรวจใช้ docker exec เพื่อรัน PHP -v และ --ini เก็บเฉพาะ metadata ที่เลือก ไม่เก็บ Env ทั้งชุด

Docker — ขั้นตอนที่ 2: ปรับ image และทดสอบ
ตรวจ Dockerfile, Compose และ volumes ให้ทราบที่มาของ PHP, INI และโค้ด สำรองข้อมูล persistent volumes ด้วยวิธีของแอป โดยเฉพาะฐานข้อมูล
เปลี่ยน base image หรือแพ็กเกจใน Dockerfile เป็นรุ่นแก้ไข หาก pin digest ต้องเปลี่ยน digest ด้วย
ใส่การปรับ configuration ไว้ใน source/configuration management เพื่อคงอยู่หลังสร้าง container ใหม่
ตัวอย่างคำสั่ง build จากโฟลเดอร์ Dockerfile:
    docker build --pull -t myapp:patched-test .
    docker run --rm --entrypoint php myapp:patched-test -v
แทนชื่อ image/tag ด้วยค่าที่องค์กรใช้ ตัวอย่าง entrypoint ใช้ได้เมื่อมี executable ชื่อ php
ทดสอบแอปและ extensions บน staging ก่อน deploy

Docker — ขั้นตอนที่ 3: Deploy และตรวจครบทุก instance
เปลี่ยน image ใน Compose หรือระบบ deploy ที่องค์กรใช้อยู่ จากนั้นทยอยเปลี่ยนบริการตามแผนบำรุงรักษา ตรวจ readiness/healthcheck
อย่าลบ volume ฐานข้อมูลเพื่อเปลี่ยน PHP image และอย่าแก้เฉพาะไฟล์ใน container ที่กำลังรันแล้วถือว่าแก้ต้นทางแล้ว
รันตัวตรวจอีกครั้งกับ container ใหม่ โดยใช้ --output audit-docker-after.json ตรวจ image ID และเวอร์ชัน PHP ทุก replica แล้วทดสอบเว็บจริง
เก็บ image digest, configuration และผลทดสอบเพื่ออ้างอิง rollback
Guard v1.1.0 ยังไม่ build/deploy หรือ rollback container อัตโนมัติ และยังไม่มี Kubernetes/Podman adapter

แก้ปัญหาที่พบบ่อย
ไม่พบ PHP: ระบุ --php-bin ให้ถูก หรือ --container-php สำหรับ Docker และตรวจว่า executable เรียกได้
File exists: ตัวตรวจข้ามแพลตฟอร์มไม่ทับรายงาน ให้ใช้ชื่อผลลัพธ์ใหม่
Permission denied: ตรวจสิทธิ์โฟลเดอร์และบัญชีที่รัน ไม่เปลี่ยนเป็น chmod 777
Baseline incomplete: ตรวจ errors ว่ามีพาธหาย อ่านไม่ได้ หรือไฟล์เปลี่ยนระหว่าง hash แล้วแก้สาเหตุก่อนสร้างใหม่
พบไฟล์เปลี่ยนจำนวนมาก: ตรวจการ deploy/cache/upload ตามปกติก่อน ไม่ลบไฟล์โดยอัตโนมัติ
ค่า INI ไม่เปลี่ยนบนเว็บ: ตรวจ runtime จริง override และ worker เก่าที่ต้องเริ่มใหม่
สงสัยบุกรุก: เก็บ log/หลักฐาน แยกระบบตามกระบวนการตอบสนองเหตุการณ์ และตรวจสิ่งตกค้าง การลงแพตช์อย่างเดียวไม่ลบสิ่งที่ผู้โจมตีทิ้งไว้

เกณฑ์ปิดงาน
มีรายการ PHP ที่เว็บไซต์ใช้งานจริงครบทุกจุด มีหลักฐานแพตช์ผู้ผลิต มีข้อมูลสำรองที่กู้คืนได้ ทดสอบฟังก์ชันสำคัญผ่าน และมีผู้รับผิดชอบติดตาม log/ผลตรวจ
รุ่น 1.1.0 ผ่านชุดทดสอบ regression 52 กรณีเมื่อรวม Linux และ Windows พร้อมทดสอบ PHP จริงบน Windows 6 กรณี, Linux 19 กรณี, PHP-FPM 2 กรณี, systemd 2 กรณี และ Docker 6 กรณี รายละเอียดและขอบเขตอยู่ใน TEST-STATUS.txt; ยังต้องทดสอบ runtime ของเว็บไซต์และแอปจริงก่อนใช้งาน

อ่านผลตรวจรุ่น 1.1.0
collection_status=complete: เก็บหลักฐาน CLI ที่ร้องขอได้ครบ ต้องอ่าน assessment แยกต่างหาก
collection_status=incomplete หรือ exit code 2: เก็บข้อมูลไม่ครบ/มีข้อผิดพลาด ไม่ใช่ผลผ่าน
at_or_above_upstream_fix: รุ่น stable ถึงเกณฑ์ upstream ของสองประกาศที่ระบุ ไม่ใช่การตรวจทุก CVE
prerelease_manual_review: รุ่น RC/alpha/beta/dev ต้องตรวจเพิ่มเติม
vendor_build_manual_review: build มี suffix ผู้จำหน่าย ต้องตรวจหลักฐานแพตช์
version_match_vendor_patch_unverified: หมายเลขต่ำกว่าเกณฑ์ ให้ตรวจแพตช์ผู้จำหน่าย/backport
outside_reviewed_branches: สาขาอยู่นอกกฎที่ทบทวน ต้องประเมินแยก
Linux audit และ portable auditor: exit 0 เก็บข้อมูลครบ; exit 2 ไม่ครบหรือผิดพลาด; Linux verify: exit 0 ค่า INI ครบและตรง, exit 1 มีค่าที่ไม่ตรง, exit 2 เก็บข้อมูลไม่ครบ
Linux check: exit 0 ตรง baseline; exit 1 มีการเปลี่ยนแปลง; exit 2 ตรวจไม่ครบหรือผิดพลาด
บน Windows ใช้ $LASTEXITCODE ดูผลคำสั่ง และเก็บรายงานในโฟลเดอร์ NTFS ที่จำกัดสิทธิ์เอง

อัปเกรดจาก v1
แตก ZIP ใหม่ในโฟลเดอร์แยกและตรวจ checksum ก่อนใช้
เก็บ phpguard_common.py ข้าง phpguard.py และ phpguard-pack.py เสมอ
Linux ที่คัดลอกไป /opt/phpguard ต้องติดตั้งโมดูลร่วมตามขั้นตอนที่ 2
หากมี watch ที่ใช้งานอยู่ ให้อัปเดตไฟล์ครบชุดก่อนเริ่มบริการเฝ้าระวังใหม่ตามขั้นตอนที่ 8
สร้าง plan ใหม่ด้วยรุ่น 1.1.0 และทบทวนก่อน apply; baseline/receipt เดิมที่ถูกต้องยังอ่านได้
portable report เป็น schema 2; Docker metadata เป็นค่า JSON ที่มีชนิดข้อมูลชัดเจน