เช็กลิสต์ความปลอดภัยเว็บไซต์ WordPress

เว็บไซต์ WordPress ส่วนใหญ่ที่ถูกเจาะไม่ได้โดนเพราะช่องโหว่ในตัว WordPress Core แต่เกิดจากปลั๊กอินหรือธีมที่ไม่อัปเดต รหัสผ่านที่เดาง่าย และสิทธิ์ไฟล์ที่เปิดกว้างเกินไป ข่าวดีคือเรื่องเหล่านี้ป้องกันได้ด้วยการตั้งค่าพื้นฐานไม่กี่อย่าง

บทความนี้เป็นเช็กลิสต์ที่ไล่ทำได้ทีละข้อ แบ่งเป็นระดับบัญชีผู้ใช้ ระดับไฟล์ ระดับเว็บเซิร์ฟเวอร์ และการสำรองข้อมูล ข้อไหนมีบทความแยกอธิบายละเอียดแล้วจะใส่ลิงก์ไว้ให้

สิ่งที่ต้องเตรียม

• บัญชี Administrator ของ WordPress
• สิทธิ์เข้าถึงไฟล์เว็บไซต์ผ่าน SSH, SFTP หรือ File Manager ของ Plesk/DirectAdmin
• หากใช้ SSH แนะนำให้ติดตั้ง WP-CLI ไว้ ดู จัดการ WordPress ด้วย WP-CLI
• ไฟล์สำรองของเว็บไซต์และฐานข้อมูลก่อนเริ่มแก้ไขใด ๆ

หมายเหตุ: ก่อนแก้ไฟล์ wp-config.php, .htaccess หรือค่า Nginx ให้สำรองไฟล์เดิมไว้เสมอ ความผิดพลาดเพียงตัวอักษรเดียวในไฟล์เหล่านี้ทำให้เว็บล่มได้ทันที

หมวดที่ 1: อัปเดตและลดสิ่งที่ไม่ใช้

• อัปเดต WordPress Core, ปลั๊กอิน และธีม สม่ำเสมอ ที่หน้า Plugins สามารถคลิก Enable auto-updates ต่อปลั๊กอินที่ไว้ใจได้
• ลบปลั๊กอินและธีมที่ไม่ใช้ ไม่ใช่แค่ปิด (Deactivate) เพราะไฟล์ที่ยังอยู่บนเซิร์ฟเวอร์ยังถูกเรียกตรงได้ เก็บธีมสำรองไว้ 1 ตัว เช่นธีมมาตรฐาน Twenty Twenty-Four หรือรุ่นใหม่กว่า
• ใช้ PHP รุ่นที่ยังได้รับการสนับสนุน PHP ที่หมดอายุการสนับสนุนจะไม่ได้รับแพตช์ความปลอดภัย
• ไม่ติดตั้งปลั๊กอินหรือธีมเถื่อน (Nulled) ซึ่งมักฝังโค้ดอันตรายไว้

ตรวจสอบรายการที่ต้องอัปเดตด้วย WP-CLI

wp core check-update
wp plugin list --update=available
wp theme list --update=available

หากไม่มีอะไรต้องอัปเดต คำสั่งแรกจะแสดง Success: WordPress is at the latest version.

หมวดที่ 2: บัญชีผู้ใช้และการเข้าสู่ระบบ

• ไม่ใช้ชื่อผู้ใช้ admin และใช้รหัสผ่านยาวอย่างน้อย 12 ตัวอักษร เก็บในโปรแกรมจัดการรหัสผ่าน
• เปิด Two-Factor Authentication ให้ทุกบัญชีที่เป็น Administrator และ Editor ดู เปิด Two-Factor Authentication สำหรับหน้า Login WordPress
• ให้สิทธิ์น้อยที่สุดที่ทำงานได้ ผู้เขียนบทความใช้บทบาท Author หรือ Editor ไม่จำเป็นต้องเป็น Administrator
• ลบบัญชีที่ไม่ใช้แล้ว เช่น บัญชีของผู้รับจ้างทำเว็บที่จบงานแล้ว
• จำกัดการเดารหัสผ่าน ด้วยปลั๊กอินจำกัดจำนวนครั้งการ Login ผิด หรือป้องกันที่ระดับเว็บเซิร์ฟเวอร์ ดู ป้องกันหน้า Admin ด้วย Basic Auth และ Rate Limit บน Nginx หรือ ตั้งรหัสผ่านป้องกันโฟลเดอร์บน Plesk

ดูรายชื่อ Administrator ทั้งหมดเพื่อหาบัญชีแปลกปลอม

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

หากพบบัญชีที่ไม่รู้จัก ให้ถือว่าเว็บอาจถูกเจาะแล้ว และทำตาม เว็บ WordPress โดนแฮก: ขั้นตอนตรวจสอบและกู้คืน

หมวดที่ 3: ตั้งค่าใน wp-config.php

เพิ่มบรรทัดต่อไปนี้ใน wp-config.php ก่อนบรรทัด /* That's all, stop editing! Happy publishing. */

// ปิดตัวแก้ไขไฟล์ธีมและปลั๊กอินในหลังบ้าน
define( 'DISALLOW_FILE_EDIT', true );

// บังคับหลังบ้านใช้ HTTPS
define( 'FORCE_SSL_ADMIN', true );

// ไม่แสดง Error บนหน้าเว็บ
define( 'WP_DEBUG', false );

DISALLOW_FILE_EDIT สำคัญมาก เพราะหากผู้ไม่หวังดีได้บัญชี Administrator ไป เมนูแก้ไขไฟล์ธีม (Theme File Editor) คือช่องทางวางโค้ดอันตรายที่ง่ายที่สุด

หากสงสัยว่ารหัสผ่านหรือ Cookie รั่ว ให้เปลี่ยน Security Keys (Salts) ใหม่ ผู้ใช้ทุกคนจะถูกบังคับออกจากระบบ

wp config shuffle-salts

หรือเปิด https://api.wordpress.org/secret-key/1.1/salt/ แล้วนำค่าที่ได้ไปแทนบรรทัด AUTH_KEY ถึง NONCE_SALT เดิมใน wp-config.php

หมวดที่ 4: สิทธิ์ไฟล์และความเป็นเจ้าของ

ค่าที่แนะนำบนเซิร์ฟเวอร์ Linux คือโฟลเดอร์ 755 ไฟล์ 644 และ wp-config.php เป็น 640 หรือ 600 ไม่ควรมีไฟล์ใดเป็น 777 ตัวอย่างนี้ถือว่าเว็บอยู่ที่ /var/www/example.com และเจ้าของไฟล์คือผู้ใช้ www-data ของ Ubuntu (บน AlmaLinux/Rocky มักเป็น nginx หรือ apache และบน Plesk/DirectAdmin จะเป็นผู้ใช้ของโดเมนนั้น)

cd /var/www/example.com
sudo find . -type d -exec chmod 755 {} \;
sudo find . -type f -exec chmod 644 {} \;
sudo chmod 640 wp-config.php
sudo chown -R www-data:www-data .

บน Plesk และ DirectAdmin ห้ามเปลี่ยนเจ้าของไฟล์เป็น www-data เพราะแต่ละโดเมนรันด้วยผู้ใช้ของตัวเอง ให้ปรับเฉพาะ chmod เท่านั้น อ่านเพิ่มเติมที่ ทำความเข้าใจสิทธิ์ไฟล์บน Linux ด้วย chmod และ chown

หมวดที่ 5: ป้องกันที่ระดับเว็บเซิร์ฟเวอร์

ห้ามรันไฟล์ PHP ในโฟลเดอร์ uploads

โฟลเดอร์ wp-content/uploads ควรมีแค่รูปและไฟล์เอกสาร หากมีไฟล์ PHP อยู่ในนั้นแทบทุกกรณีคือ Backdoor บน Apache หรือ LiteSpeed ให้สร้างไฟล์ wp-content/uploads/.htaccess

<FilesMatch "\.(php|phtml|phar)$">
    Require all denied
</FilesMatch>

บน Nginx ให้เพิ่มใน Server Block โดยวางไว้ ก่อน location ~ \.php$ เพราะ Nginx ใช้ Regex Location ตัวแรกที่ตรง

location ~* ^/wp-content/uploads/.*\.(php|phtml|phar)$ {
    deny all;
}

ทดสอบค่าและโหลดใหม่

sudo nginx -t
sudo systemctl reload nginx

ปิด XML-RPC หากไม่ใช้

xmlrpc.php ถูกใช้เดารหัสผ่านจำนวนมากในคำขอเดียว หากไม่ได้ใช้แอป WordPress บนมือถือหรือบริการที่ต้องใช้ XML-RPC (เช่น Jetpack บางฟังก์ชัน) ให้ปิดที่เว็บเซิร์ฟเวอร์ บน Nginx

location = /xmlrpc.php {
    deny all;
}

ปิด Directory Listing และเพิ่ม Security Headers

บน Apache ให้มี Options -Indexes ใน .htaccess ส่วน Nginx ปิดอยู่แล้วโดยค่าเริ่มต้น (ตราบใดที่ไม่ได้เปิด autoindex on) ส่วน Security Headers ดูที่ ตั้งค่า HTTP Security Headers ให้เว็บไซต์ และใช้ HTTPS ทั้งเว็บตาม ติดตั้ง SSL ฟรีจาก Let's Encrypt ด้วย Certbot บน Nginx

หมวดที่ 6: สำรองข้อมูล

การสำรองข้อมูลคือด่านสุดท้ายเมื่อทุกอย่างล้มเหลว ให้สำรองทั้งไฟล์และฐานข้อมูล เก็บไว้นอกเซิร์ฟเวอร์เดียวกัน และทดลองกู้คืนจริงอย่างน้อยปีละครั้ง ดู สำรองและกู้คืนฐานข้อมูล MySQL/MariaDB ด้วย mysqldump และ สำรองข้อมูลไปยังเซิร์ฟเวอร์อื่นด้วย rsync และ Cronjob

ตรวจสอบผลลัพธ์

ตรวจว่าไฟล์ Core ของ WordPress ไม่ถูกแก้ไข

wp core verify-checksums
wp plugin verify-checksums --all

ผลที่ดีคือ Success: WordPress installation verifies against checksums. ส่วนปลั๊กอินที่ไม่ได้มาจาก WordPress.org จะตรวจไม่ได้และขึ้นคำเตือน ถือเป็นเรื่องปกติ ทดสอบการบล็อก PHP ใน uploads

curl -I https://example.com/wp-content/uploads/test.php

ผลที่ถูกต้องคือ HTTP/2 403 (หรือ 404 หากไม่มีไฟล์นี้บน Apache) ไม่ควรเป็น 200

ปัญหาที่พบบ่อย

หลังเปลี่ยนสิทธิ์ไฟล์ อัปเดตปลั๊กอินแล้วถูกถามข้อมูล FTP

WordPress เขียนไฟล์ไม่ได้เพราะเจ้าของไฟล์ไม่ตรงกับผู้ใช้ที่ PHP รันอยู่ ตรวจผู้ใช้ของ PHP-FPM Pool แล้ว chown ให้ตรงกัน

หน้าเว็บขึ้น 500 หลังเพิ่ม .htaccess

เซิร์ฟเวอร์อาจไม่อนุญาตคำสั่งบางตัวใน .htaccess ลบไฟล์ที่เพิ่งสร้างออก แล้วดู Error Log ของเว็บไซต์ ความหมายของรหัส Error ดูที่ ทำความเข้าใจ HTTP Error 403, 404, 500, 502, 503 และ 504

ปลั๊กอินบางตัวทำงานผิดปกติหลังบล็อก PHP ใน uploads

ปลั๊กอินที่ออกแบบไม่ดีบางตัวเก็บสคริปต์ไว้ใน uploads ให้พิจารณาเปลี่ยนปลั๊กอิน มากกว่าการยกเลิกการป้องกัน

หากทำตามขั้นตอนแล้วยังติดปัญหา สามารถติดต่อทีมสนับสนุนของ THAI DATA CLOUD ได้ที่ https://thaidata.cloud/contact/