Có thể. Nếu nhiều website chạy dưới cùng một Unix user và filesystem cho phép user đó đọc/ghi vào thư mục của các site còn lại, compromise ở một site có thể mở rộng blast radius sang site khác. Đây không phải “WordPress tự lây” mà là hệ quả của shared execution identity + shared write permission. Nếu entry point ban đầu là file PHP trong vùng writable, xem thêm quy trình điều tra PHP trong wp-content/uploads trên aaPanel.
PHP-FPM hỗ trợ nhiều pool chạy với các Unix user/group khác nhau. Tài liệu PHP nêu rõ mỗi pool có thể có UID/GID riêng và directive user là Unix user của FPM process. Điều này cho phép tách execution identity giữa các website thay vì để tất cả PHP chạy cùng một user. PHP-FPM manual.
Lây nhiễm giữa site cùng Unix user xảy ra như thế nào?
Hãy giả sử Site A và Site B đều được PHP-FPM chạy dưới user webuser. Nếu attacker đạt được code execution trên Site A, code đó thường kế thừa quyền của process PHP-FPM. Nếu webuser có quyền ghi vào file của Site B, attacker có thể tác động tới Site B trong phạm vi các quyền đó.
Chuỗi rủi ro thường là:
Site A có vulnerability → attacker đạt code execution → PHP chạy với Unix user dùng chung → user đó có quyền đọc/ghi sibling site → Site B bị thay đổi file hoặc lộ secret → compromise lan rộng.
Điểm quan trọng là same server chưa đủ để kết luận có cross-site write. Phải kiểm tra Unix identity và permission thực tế.
Cùng server nhưng khác Unix user có an toàn tuyệt đối không?
Không. Tách Unix user là một boundary quan trọng nhưng không phải boundary duy nhất. Cross-site compromise vẫn có thể xảy ra qua:
- group permission hoặc ACL cho phép ghi chéo;
- shared writable directory;
- database credential dùng chung;
- control panel hoặc deployment credential dùng chung;
- backup/shared storage có quyền quá rộng;
- container volume mount chồng lấn;
- process chạy với privilege cao hơn mong đợi;
- kernel/server compromise vượt qua application-level isolation.
Do đó “mỗi site một Unix user” là giảm blast radius, không phải bảo đảm tuyệt đối.
Dấu hiệu nào cho thấy nhiều website đang dùng chung execution identity?
- nhiều virtual host trỏ tới cùng PHP-FPM pool;
- FPM pool của nhiều domain cùng khai báo một
user/group; - file của nhiều website có cùng owner;
- runtime process PHP của nhiều domain chạy cùng UID;
- control panel tạo nhiều domain trong cùng account và không tách system user;
- các site có thể ghi file vào thư mục sibling mà không cần sudo hoặc privilege khác.
PHP manual cho phép nhiều pool có UID/GID khác nhau; đây là nền tảng để thiết kế isolation theo site hoặc theo trust boundary. PHP-FPM pool configuration.
Nếu một site bị hack, làm sao biết các site khác có nằm trong blast radius?
1. Map execution identity
Xác định mỗi website đang chạy PHP bằng Unix user/group nào. Đừng chỉ nhìn owner của document root; runtime identity mới quyết định code PHP có thể làm gì.
2. Map filesystem permissions
Kiểm tra owner, group, mode và ACL của document root, upload, cache, temp, backup và config files. Mục tiêu là trả lời: process của Site A có thể đọc hoặc ghi file nào của Site B?
3. Kiểm tra secret exposure
Nếu Site A có thể đọc wp-config.php của Site B, attacker có thể lấy database credential và secret khác ngay cả khi không ghi được file. Vì vậy blast radius không chỉ là write access.
4. So file timeline giữa các site
Tìm file mới/thay đổi trong cùng khoảng thời gian incident ở Site A. Nếu nhiều site xuất hiện artifact giống nhau, cùng timestamp pattern hoặc cùng payload family, cross-site propagation trở nên đáng nghi hơn.
5. Kiểm tra process và scheduled persistence
Rà cron, systemd user unit, panel task, WordPress cron và các process chạy dưới shared user. Persistence ở cấp user/server có thể ảnh hưởng nhiều site dù entry point ban đầu chỉ nằm ở một site.
Ví dụ permission nào làm tăng blast radius?
Rủi ro cao khi nhiều website:
- cùng owner và owner có write permission trên toàn bộ document root;
- cùng group với group-write trên nhiều thư mục;
- dùng ACL cấp write cho cùng runtime user;
- đặt backup, temp hoặc deployment artifacts ở thư mục dùng chung và writable;
- dùng cùng credential để quản trị database hoặc control panel.
Ngược lại, blast radius giảm khi mỗi site có execution identity riêng, ownership rõ, write path tối thiểu và secret không dùng chung.
PHP-FPM pool isolation nên thiết kế thế nào?
Một pattern phổ biến là mỗi trust boundary có pool riêng:
- Site A → pool A → Unix user A;
- Site B → pool B → Unix user B;
- socket riêng và permission phù hợp;
- document root của A không writable bởi user B và ngược lại;
- chỉ các thư mục thật sự cần ghi mới writable;
- secret/database credential tách biệt khi khả thi.
SecureWebOps đã phân tích phần cấu hình chi tiết tại PHP-FPM Security: cô lập và giới hạn PHP trên Web Server. Bài hiện tại tập trung vào blast radius sau compromise, không thay thế bài hardening đó.
Nếu dùng aaPanel/cPanel/Plesk thì có mặc định tách user không?
Không nên suy luận từ tên control panel. Cách account, subscription, domain và PHP handler được ánh xạ sang system user phụ thuộc cấu hình, edition và cách server được triển khai. Cần kiểm chứng runtime identity và permission thực tế trên server.
Một panel có thể hỗ trợ isolation tốt nhưng administrator vẫn có thể cấu hình nhiều site dưới cùng account hoặc cấp permission rộng. Ngược lại, một server không dùng panel vẫn có thể tách site tốt bằng FPM pool, Unix user, ACL/MAC policy và filesystem layout.
Incident response khi phát hiện nhiều site cùng Unix user
- Không giới hạn scope ở site đầu tiên. Mở rộng triage tới tất cả site mà shared user có thể đọc/ghi.
- Snapshot evidence. Lưu file metadata, log, process, cron và config cần thiết trước cleanup.
- Contain entry point. Patch/disable vulnerable component và chặn exploit path.
- Kiểm tra sibling sites. File integrity, admin accounts, plugin/theme changes, cron, MU-plugin, drop-in và secret access.
- Rotate credential theo scope. Nếu shared user đọc được config của nhiều site, xem các credential đó là potentially exposed.
- Tách execution identity. Sau incident, thiết kế lại user/pool/permission để giảm recurrence.
- Read-back isolation. Xác minh runtime user, ownership và khả năng cross-write sau thay đổi.
Nếu incident bắt đầu từ file upload/webshell, xem thêm Webshell qua File Upload và PHP Execution. Nếu nghi permission/FPM là nguyên nhân mở rộng compromise, tham khảo Website bị compromise do PHP-FPM và File Permission sai. Với sự cố có nhiều artifact hoặc nhiều site cùng bị ảnh hưởng, nên dựng lại chuỗi sự kiện theo Root Cause Analysis sau Security Incident.
Cách validate sau khi tách site
Không chỉ kiểm tra config file. Validation phải chứng minh boundary hoạt động:
- runtime process của từng site chạy đúng UID/GID dự kiến;
- socket/pool mapping đúng virtual host;
- Site A không ghi được document root/write path của Site B;
- Site A không đọc được secret của Site B nếu không cần thiết;
- upload/cache vẫn hoạt động ở site tương ứng;
- deploy/update/backup workflow không bị phá vỡ;
- log và monitoring vẫn định danh đúng site/pool.
Kết luận
Nếu nhiều website chạy dưới cùng Unix user, một compromise có thể lan sang site khác khi quyền của shared user cho phép đọc hoặc ghi chéo. Đây là vấn đề isolation và blast radius, không phải đặc tính riêng của WordPress. Cách xử lý đúng là map runtime identity, kiểm tra permission/secret exposure, mở rộng incident scope và tách trust boundary bằng PHP-FPM pool, Unix user và quyền filesystem phù hợp.