เสริมความปลอดภัยเว็บไซต์ standalone: ไฟร์วอลล์ จำกัดการเข้าสู่ระบบ สิทธิ์ไฟล์ และสแกนมัลแวร์
หนึ่ง ไฟร์วอลล์: เพิ่ม WAF ใน security group ของคลาวด์ ปิดพอร์ตที่ไม่จำเป็นก่อน
หลายคนคิดว่าไฟร์วอลล์คือซอฟต์แวร์ที่ติดตั้งในเซิร์ฟเวอร์ แต่จริงๆ แล้วสำหรับเว็บไซต์ standalone บนคลาวด์โฮสต์ ด่านแรกคือ security group ของผู้ให้บริการคลาวด์ การที่ security group เปิดพอร์ต 3306, 6379, 9000 ไว้ทั้งหมดคือความเสี่ยงสูงสุด ฐานข้อมูลและ Redis เปิดสู่อินเทอร์เน็ตโดยตรง สแกนเนอร์ bruteforce เข้าไปได้ในไม่กี่นาที วิธีที่ถูกต้องคือ security group อนุญาตเฉพาะ 80 และ 443 ส่วนพอร์ต 22 จำกัดเฉพาะ IP ทางออกคงที่ของบริษัท
ด่านที่สองคือ WAF (Web Application Firewall) เวอร์ชันฟรีของ Cloudflare ก็เพียงพอแล้ว ตรวจจับ SQL injection, XSS และสแกนเนอร์ทั่วไปโดยอัตโนมัติ อย่าตั้งกฎ WAF เข้มเกินไป ไม่งั้นจะบล็อกผู้เข้าชมปกติออกไป ตอนเปิดให้เลือกโหมดบันทึกอย่างเดียวก่อน 3 วัน ดูว่าอัตราแจ้งเตือนผิดพลาดต่ำกว่า 1% แล้วค่อยเปลี่ยนเป็นโหมดบล็อก
| พอร์ต/บริการ | สถานะเริ่มต้น | สถานะหลังเสริมความปลอดภัย | เหตุผล |
|---|---|---|---|
| 80/443 | เปิด 0.0.0.0/0 | เปิด 0.0.0.0/0 | ต้องเข้าถึงได้จากอินเทอร์เน็ต |
| 22 SSH | เปิด 0.0.0.0/0 | จำกัด IP คงที่ของบริษัท เปลี่ยนเป็นล็อกอินด้วยคีย์ | จุดที่ถูก bruteforce รหัสผ่านหนักที่สุด |
| 3306 MySQL | มักถูกเปิดโดยไม่ตั้งใจ | อนุญาตเฉพาะ 127.0.0.1 ในเครื่อง | ห้ามเปิดสู่อินเทอร์เน็ตเด็ดขาด |
| 6379 Redis | มักถูกเปิดโดยไม่ตั้งใจ | อนุญาตเฉพาะในเครื่อง ตั้งรหัสผ่าน | ถ้าไม่มีการยืนยันตัวตนจะถูกเขียน public key |
| 9000 PHP-FPM | local socket | ใช้ local socket ต่อไป ไม่เปิด TCP | ไม่ต้องเข้าถึงจากอินเทอร์เน็ต |
| 8888/แผงควบคุม BT Panel | มักถูกเปิดเผย | จำกัด IP + เปลี่ยนพอร์ตเริ่มต้น | แผงควบคุมเป็นเป้าหมายโจมตีบ่อย |
ตัวอย่างสถานการณ์: เว็บ WordPress ที่ใช้แผงควบคุม BT Panel ตอนเปิดใหม่ security group เปิดทั้งหมด สามวันต่อมา CPU เซิร์ฟเวอร์พุ่งไป 100% เข้าไปดูพบว่าพอร์ต 3306 ถูก bruteforce จาก IP ต่างประเทศ log ของ MySQL เต็มไปด้วยบันทึกการเชื่อมต่อล้มเหลว เปลี่ยนเป็น security group เปิดเฉพาะ 80/443 และพอร์ต 22 ที่จำกัด IP บริษัท CPU ลดกลับมา 5% ทันที อุบัติเหตุนี้ป้องกันได้ใน 10 นาที แต่คนส่วนใหญ่ตอนเปิดเว็บไม่ดู security group เลย
วิธีตั้งกฎ WAF เหมือนกับ การป้องกันสแปมในฟอร์มสอบถาม คือใช้ตรรกะเดียวกัน: บันทึกและสังเกตก่อน แล้วค่อยบล็อก อย่าปิดกั้นคำขอที่น่าสงสัยทั้งหมดตั้งแต่แรก
2. จำกัดการเข้าสู่ระบบ: ตัดช่องทาง brute force
wp-admin ของ WordPress คือประตูแรกที่เว็บไซต์ถูกแฮก ผู้ใช้เริ่มต้น admin รหัสผ่านง่าย หน้า login เข้าถึงได้จากทุกที่ สแกนเนอร์ไล่ dictionary ได้ภายในไม่กี่ชั่วโมง สวนทางกับที่คิด: ติดตั้งปลั๊กอินจำกัดการเข้าสู่ระบบได้ผลกว่าซื้อผลิตภัณฑ์สแกนความปลอดภัยใด ๆ เพราะการ brute force ส่วนใหญ่ไปไม่ถึงขั้นโจมตีช่องโหว่ ติดที่หน้า login ก็ถูกสกัดไว้แล้ว
ชุดจำกัดการเข้าสู่ระบบ 3 อย่าง: ผิด 5 ครั้งล็อก 30 นาที เปลี่ยน path login เริ่มต้น (/wp-admin เป็นสตริงสุ่ม) บังคับ 2FA รหัสผ่านยาวไม่น้อยกว่า 16 ตัวอักษร สร้างด้วยโปรแกรมจัดการรหัสผ่าน อย่าใช้คำผสมตัวเลข SSH ก็เช่นกัน ปิดการ login ด้วยรหัสผ่าน ใช้เฉพาะคีย์
| รายการตั้งค่า | ค่าตั้งต้น | ค่าที่ตั้ง | เครื่องมือ/วิธีทำ |
|---|---|---|---|
| ล็อกเมื่อ login ผิด | ไม่จำกัด | ผิด 5 ครั้งล็อก 30 นาที | Wordfence หรือ fail2ban ที่ตั้งเอง |
| path login | /wp-admin | สตริงสุ่ม เช่น /login-7f3k | ปลั๊กอิน WPS Hide Login |
| การยืนยันตัวตนสองชั้น | ไม่มี | บังคับ TOTP 2FA | Wordfence หรือ Two Factor |
| ความยาวรหัสผ่าน | 6 ตัวอักษร | ≥16 ตัวอักษรแบบสุ่ม | สร้างด้วยโปรแกรมจัดการรหัสผ่าน |
| การยืนยันตัวตน SSH | login ด้วยรหัสผ่าน | ใช้เฉพาะคีย์ ปิดรหัสผ่าน | แก้ sshd_config เป็น PasswordAuthentication no |
| ผู้ใช้ฐานข้อมูล | root เชื่อมต่อจากระยะไกล | ผู้ใช้เฉพาะ จำกัดเฉพาะเครื่องนี้ | สร้างบัญชีแยกใน MySQL |
ตัวอย่างสถานการณ์: เว็บ SaaS ที่ออกตลาดต่างประเทศ หน้า login หลังบ้านอยู่ที่ /secret-admin เปิด 2FA ผิด 5 ครั้งล็อก 30 นาที ดู log แล้วพบว่ามีความพยายาม login จาก IP ต่างประเทศราว 2,000 ครั้งต่อสัปดาห์ ถูกกันไว้ทั้งหมด ไม่สำเร็จแม้แต่ครั้งเดียว ถ้าไม่จำกัด ความพยายามเหล่านี้เมื่อคิดจากความแข็งแรงของรหัสผ่านเฉลี่ย โอกาสที่ credential stuffing จะสำเร็จภายใน 3 เดือนสูงกว่า 30%
แนวคิดการเลือกปลั๊กอินและ tech stack โดยรวม ดูที่ปลั๊กอินที่พัฒนเอง 4 ตัวใน crater tech stack。
3. สิทธิ์ไฟล์: ทำให้ไฟล์อันตรายที่ถูกอัปโหลดรันไม่ได้
สิทธิ์ไฟล์เป็นชั้นที่หลายคนมองข้าม หลัง WordPress ถูกแฮก ผู้โจมตีมักอัปโหลด PHP webshell ไปที่ wp-content/uploads ถ้าโฟลเดอร์ uploads อนุญาตให้รัน PHP webshell นั้นก็ควบคุมทั้งเว็บได้ทันที ถ้าโฟลเดอร์ uploads ห้ามรัน PHP ผู้โจมตีอัปโหลดไปก็รันไม่ได้ ทำได้แค่มองตาปริบ ๆ
สิทธิ์มาตรฐานคือ: โฟลเดอร์ 755 ไฟล์ 644 wp-config.php เปลี่ยนเป็น 400 (เฉพาะเจ้าของอ่านได้) อย่าขี้เกียจตั้งเป็น 777 ทั้งหมด นั่นเท่ากับแขวนกุญแจไว้ที่ประตู โฟลเดอร์ uploads ให้เพิ่มกฎใน config ของ nginx ห้ามรันไฟล์ .php, .phtml, .php5 เป็นต้น
| เส้นทาง | สิทธิ์ | เจ้าของ | คำอธิบาย |
|---|---|---|---|
| โฟลเดอร์รากของเว็บไซต์ | 755 | www-data:www-data | อย่าตั้ง 777 |
| wp-config.php | 400 | root | โปรเซสเว็บอ่านไม่ได้ |
| wp-content/themes | 755 | www-data | อัปเดตอัตโนมัติต้องมีสิทธิ์เขียน |
| wp-content/uploads | 755 | www-data | ห้ามรัน PHP |
| wp-content/plugins | 755 | www-data | อัปเดตปลั๊กอินต้องเขียนได้ |
| โฟลเดอร์ .git | อย่าเปิดเผยบนเว็บ | — | ถ้าเปิดเผยจะรั่วซอร์สโค้ด |
อีกสาเหตุที่พบบ่อยคือการวางไฟล์สำรองฐานข้อมูลไว้ในโฟลเดอร์เว็บโดยตรง ปลั๊กอินสำรองข้อมูลหลายตัวตั้งค่าเริ่มต้นให้เก็บไฟล์ .sql.gz ไว้ที่ wp-content/backup/ ผู้โจมตีสแกนเจอก็ดาวน์โหลดได้ทันทีและได้ข้อมูลทั้งเว็บไป วิธีที่ถูกต้องคือเก็บไฟล์สำรองไว้นอก web root หรืออัปโหลดไปยัง object storage อัตโนมัติหลังสำรองเสร็จแล้วลบสำเนาในเครื่องทิ้ง ดูแนวทางสำรองข้อมูลได้ที่การสำรองและกู้คืนเว็บไซต์。
4. การสแกนที่เป็นอันตรายและการแพตช์: สัปดาห์ละครั้ง แพตช์ภายใน 7 วัน
การสแกนหาการบุกรุกไม่ใช่รอให้ถูกแฮ็กก่อนแล้วค่อยทำ ให้รันการเทียบ hash ไฟล์หลักสัปดาห์ละครั้ง ถ้า hash ของไฟล์หลัก WordPress ไม่ตรงกับเวอร์ชันที่รู้จัก แปลว่าถูกแก้ไข ต้องอัปเดตปลั๊กอินและธีมให้เสร็จภายใน 7 วัน เพราะช่องโหว่ที่เปิดเผยต่อสาธารณะใช้เวลาเฉลี่ย 14 วันก่อนถูกสแกนเนอร์อัตโนมัติโจมตี แพตช์ภายใน 7 วันก็เลี่ยงการโจมตีส่วนใหญ่ได้
เครื่องมือสแกนมีสามประเภท: ปลั๊กอินอย่าง Wordfence สแกนหา signature ของ webshell ที่รู้จัก, ClamAV สแกนไวรัสระดับเซิร์ฟเวอร์, และการวิเคราะห์ log เซิร์ฟเวอร์ช่วยจับรูปแบบการเข้าถึงที่ผิดปกติ ใช้ทั้งสามอย่างร่วมกัน อย่าหวังว่าเครื่องมือเดียวจะครอบคลุมทุกอย่าง ดูแนวคิดการวิเคราะห์ log ของ AI crawler ได้ที่การวิเคราะห์ log ของ AI crawler วิธีวิเคราะห์ log แบบเดียวกันนี้ใช้ตรวจจับสแกนเนอร์ที่เป็นอันตรายได้ด้วย
| รายการตรวจสอบ | ความถี่ | เครื่องมือ | การจัดการความผิดปกติ |
|---|---|---|---|
| เทียบ hash ไฟล์หลัก | ทุกสัปดาห์ | Wordfence core integrity | พบความต่าง ให้กู้คืนจากเวอร์ชันที่สะอาด |
| อัปเดตปลั๊กอินและธีม | ทุกวันจันทร์ | หลังบ้าน WP + log | ต้องอัปเดตให้เสร็จภายใน 7 วัน |
| สแกน webshell | ทุกสัปดาห์ | ClamAV หรือ Wordfence | กักกันและลบไฟล์ที่เป็นอันตราย |
| ประวัติการเข้าสู่ระบบที่น่าสงสัย | ทุกวัน | log ของ fail2ban | แบน IP ผู้โจมตีอัตโนมัติ |
| ไฟล์ที่แก้ไขล่าสุดในโฟลเดอร์เว็บ | ทุกสัปดาห์ | find -mtime -7 | มีการแก้ไขที่ไม่คาดคิดให้ตรวจสอบทันที |
| การเขียนฐานข้อมูลที่ผิดปกติ | ทุกสัปดาห์ | เนื้อหา base64 ใน wp_posts | ล้างโค้ด eval ที่ซ่อนอยู่ |
ข้อเตือนที่ขัดกับสัญชาตญาณ: หลังถูกแฮ็กอย่ารีบล้างแบบออนไลน์ ปัญหาที่ใหญ่ที่สุดของการล้างแบบออนไลน์คือ webshell และ cron ที่ซ่อนในฐานข้อมูลคุณตรวจไม่ทั่ว อีกสองสัปดาห์ก็กลับมาอีก ขั้นตอนที่ถูกต้องคือ: ตัดการให้บริการภายนอกของเว็บ, กู้คืนจากไฟล์สำรองที่สะอาดล่าสุด, เปลี่ยนรหัสผ่านและคีย์ทั้งหมด, ตรวจ cron และสิ่งที่ตกค้างในฐานข้อมูล, แล้วค่อยเปิดเว็บใหม่ ดูขั้นตอนทั้งหมดหลังถูกแฮ็กได้ที่การกู้คืนและทำ index ใหม่หลังเว็บถูกแฮก。
ดูรายการตรวจสอบประจำวันได้ที่งาน 6 อย่างที่ต้องทำทุกเดือนในช่วงดูแลเว็บไซต์ แล้วใส่การเสริมความปลอดภัยเข้าไปเป็นกิจวัตร วิธีตั้งค่าเกณฑ์แจ้งเตือนดูได้ที่การมอนิเตอร์และแจ้งเตือนเว็บไซต์。
FAQ คำถามที่พบบ่อย
เว็บไซต์ถูกแฮ็ก ควรทำอะไรก่อนเป็นอันดับแรก?
ควรซื้อ WAF แบบเสียเงินไหม Cloudflare เวอร์ชันฟรีพอหรือเปล่า?
ปลั๊กอิน WordPress ควรอัปเดตบ่อยแค่ไหน แล้วอัปเดตอัตโนมัติปลอดภัยไหม?
ตั้งสิทธิ์ไฟล์ wp-config.php และโฟลเดอร์ uploads อย่างไร?
ควรเปลี่ยนพอร์ต SSH จากค่าเริ่มต้น 22 ไหม แล้วยังใช้ล็อกอินด้วยรหัสผ่านได้หรือไม่?
จะรู้ได้อย่างไรว่าเว็บถูกฝังมัลแวร์ มีสัญญาณเตือนล่วงหน้าไหม?
ทิ้งท้าย
เรื่องความปลอดภัยของเว็บไซต์ สิ่งที่แพงที่สุดไม่ใช่เครื่องมือ แต่คือความคิดที่ว่า “คงไม่เป็นไรหรอก” เว็บไซต์ของคุณไม่ใช่ธนาคาร แต่เป็นช่องทางรับลูกค้าของคุณ ถ้าถูกฝังมัลแวร์หรือล่มไป เสียหายคือลีดลูกค้าจริง ๆ การป้องกัน 4 ชั้นไม่จำเป็นต้องทำครบในทีเดียว แต่ต้องทำตามลำดับ: ปิดพอร์ตก่อน จำกัดการล็อกอินต่อ ตั้งสิทธิ์ไฟล์ แล้วค่อยสแกน สามขั้นแรกทำเสร็จได้ในบ่ายเดียว คุ้มค่าที่สุด
ลงมือ 3 ขั้น: หนึ่ง เข้า Security Group ของคลาวด์ ปิดพอร์ต 3306, 6379, 8888 ที่ไม่ควรเปิดสู่อินเทอร์เน็ต จำกัด SSH ให้เข้าได้แค่ IP บริษัท สอง เปลี่ยน path ของ wp-admin เปิด 2FA ล็อกเมื่อล็อกอินผิด 5 ครั้ง เปลี่ยน SSH เป็นล็อกอินด้วยคีย์ สาม ตั้งเวลาทุกสัปดาห์รัน hash ไฟล์หลักและอัปเดตปลั๊กอิน ทำสามขั้นนี้เสร็จ คุณกันการโจมตีทั่วไปได้แล้ว 80%
ประโยคที่จำง่าย ๆ: เว็บไซต์ถูกแฮกไม่ค่อยเกิดจากแฮกเกอร์ระดับสูง ส่วนใหญ่เกิดจากรหัสผ่านอ่อน ปลั๊กอินไม่อัปเดต และไฟล์สำรองฐานข้อมูลที่เปิดเผย ปิดสามช่องทางนี้ให้สนิท ดีกว่าซื้อผลิตภัณฑ์ความปลอดภัยตัวไหนก็ตาม