ตรวจ PHP
เตรียมระบบให้พร้อมแก้ไข

เริ่มต้น: อ่านขอบเขตให้ตรงกับงาน

แพ็กนี้ตรวจ 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.0.1.zip.sha256

ผลที่ต้องได้คือ OK หากค่าไม่ตรงให้หยุดและดาวน์โหลดใหม่ ไฟล์ checksum ต้องอยู่โฟลเดอร์เดียวกับ ZIP

แตกไฟล์แล้วเข้าโฟลเดอร์ phpguard:

unzip ipradr-phpguard-pack-v1.0.1.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 -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 หรือ outside_reviewed_branches_manual_review ต้องตรวจเอง ไม่ใช่ผลผ่าน

เกณฑ์กฎวันที่ 23 ตุลาคม 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 ยังไม่แก้ไฟล์ 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

หากผลเป็น configuration_written_but_overridden แปลว่ามีไฟล์ใน conf.d ตั้งค่าเดียวกันทับไว้ (ดูรายการ overrides) ต้องแก้ไฟล์เหล่านั้นด้วย มิฉะนั้นค่าใหม่จะไม่มีผล ผลจะระบุพาธ receipt.json ให้จดเก็บไว้ ใช้ย้อนกลับได้ โปรแกรมตรวจ hash และสำรอง INI ก่อนเขียน แต่ไม่ restart บริการ

หากแจ้ง 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

verify อ่านค่าที่ PHP ใช้งานจริงของทุก php/php-fpm ที่พบ แล้วเทียบกับค่าที่ต้องการ: exit 0 = ตรงทุก runtime, 1 = ยังไม่ตรง (ดู mismatches) เปรียบเทียบกับ audit-before.json ได้เช่นเดิม verify ไม่ใช่ตัวทดสอบธุรกรรมเว็บ

ตรวจ 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.0.1.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 ตรวจ assessment และหลักฐานคำสั่ง หาก unknown ให้แก้ปัญหา path/สิทธิ์แล้วตรวจใหม่

ตรวจ 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 ไม่มี 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 ยังไม่ 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/ผลตรวจ

แพ็กยังเป็นรุ่นทดลอง v1.0.1 ผ่าน unit test 11 ข้อ และทดสอบจริงบน Debian 12 + PHP 8.2 และ Docker แล้ว ยังไม่ได้ทดสอบบน Windows ที่มี PHP และระบบ rpm