Header ที่ส่งกลับมา

cf-edge-cache: cache,platform=wordpress
x-litespeed-cache: hit
cf-cache-status: HIT

ลองดูว่าต้องมี 3 ค่านี้ส่งกลับมาที่ Client นะครับ วิธีการเช็ค Header ง่ายๆ ก็ใช้ Command line : curl

curl -Iv https://cloudhost.in.th

สำหรับการทดสอบกับ OpenLiteSpeed จะไม่พ่น cf-edge-cache ออกมาครับ ซึ่งก็คาดว่าจะรองรับเฉพาะเวอร์ชั่น LiteSpeed Enterprise เท่านั้น

สำหรับใครที่อยากจะเซตแบบนี้ CloudHost.in.th มีบริการเซตให้ฟรี รองรับ 1 Domain เท่านั้น ดูบริการ Cloud Server สำหรับ WordPress Hosting ได้ที่ลิงก์ด้านล่างนี้

• Cloud VPS Hosting (ประเทศไทย) รองรับ Package Cloud VPS 02 – ดูข้อมูลเพิ่มเติมได้ที่ลิงก์ https://cloudhost.in.th/service/cloud-vps-hosting
• Cloud Server ต่างประเทศ รองรับ Package Cloud Inter 02 – ดูข้อมูลเพิ่มเติมได้ที่ลิงก์ https://cloudhost.in.th/service/cloud-inter

1. Cloudflare CDN – จะเป็นการให้บริการ CDN ที่จะมาคั่นระหว่าง Client <=> Cloudflare <=> Server ซึ่ง Traffic ทั้งหมดจะต้องวิ่งผ่าน Cloudflare จะไม่ได้วิ่งไปที่ Server ตรงๆ เพราะฉะนั้น วิธีการนี้จะสามารถซ่อน IP Address ของ Server ได้
2. Cloudflare DNS – จะเป็นการใช้บริการเฉพาะ DNS Query เท่านั้น Traffic ทั้งหมดจะวิ่งไปหา Server ตรงๆ

การซ่อน IP address ของ Server จึงสามารถทำได้ตามข้อที่ 1 นั่นเอง หากยังไม่มี Account ก็สามารถลงทะเบียนได้ฟรีๆ โดยลำดับขั้นตอนการตั้งค่าจะประมาณนี้ครับ

1. ลงทะเบียน Cloudflare ให้เรียบร้อย
2. เพิ่มโดเมนลงระบบ ทำตามขั้นตอนไปเรื่อยๆ
3. ในขั้นตอนการเซต DNS หากเคยใช้บริการ DNS Server หรือว่ามีประวัติการตั้งค่า DNS จากที่เดิมอยู่แล้ว ทางระบบ Cloudflare จะทำการ Query และดึงข้อมูลมาใส่ให้
4. ตรวจสอบความเรียบร้อยของ DNS Record ที่ทาง Cloudflare ดึงมาใช้
5. รูปเมฆสีส้ม จะหมายถึง Cloudflare CDN และรูปเมฆสีเทา จะหมายถึง Cloudflare DNS Only
6. ตั้งค่าในส่วนที่ต้องการ หากต้องการซ่อน IP Address Server ทั้งหมด แนะนำให้ตั้งค่าเป็นเมฆส้มทั้งหมดนะครับ

ทำไมต้อง DNSSEC

โดยหลักๆเลยก็คือ เรื่องของความปลอดภัย เพื่อยืนยันว่าเราจะเชื่อมต่อไปยัง Server ที่ถูกต้อง ไม่ได้เชื่อมต่อไปยัง Server ของ Hacker แล้วกรอกข้อมูล Login ของเราไปให้แฮกเกอร์ เป็นต้น

ถ้าโดเมนที่รองรับถูกเปลี่ยนเส้นทาง และหากมีการเซต DNSSEC ไว้ โดเมนนั้นๆจะเข้าไม่ได้เลยครับ

จะใช้ DNSSEC ได้อย่างไร

เนื่องจาก DNSSEC เกี่ยวข้องกับระบบ Domain Name ซึ่งจะเป็นในส่วนของฝั่ง Server และ Client ที่เป็นส่วนของผู้ใช้งาน เพราะฉะนั้น การที่จะรองรับการใช้งาน DNSSEC ได้นั้น จะต้องรองรับทั้ง 2 ฝั่ง ซึ่งปัจจุบันนี้ Domain Name นามสกุลต่างๆนั้นเกือบจะทั้งหมด รองรับการตั้งค่า DNSSEC อยู่แล้ว รวมถึงฝั่งของ Client ก็เช่นกัน เบราเซอร์รุ่นใหม่ๆ ก็รองรับการใช้งาน DNSSEC ด้วยเช่นกัน

ทดสอบ DNSSEC ฝั่ง Domain Name

วิธีการเช็คโดเมนของเรารองรับ DNSSEC ไหม สามารถเช็คได้ที่ลิงก์ https://dnsviz.net ครับ กรอกชื่อโดเมนที่ต้องการ > คลิกที่ Analyze > Continue แล้วเราจะได้ Chain DNS มาครับ ซึ่ง Chain ที่มีความปลอดภัย จะต้องไม่มีลูกศรสีดำ ระหว่าง Chain นะครับ

เพิ่มเติม: สามารถทดสอบได้อีกเว็บ https://dnssec-analyzer.verisignlabs.com/ เป็นเว็บเพิ่มเติม ดูง่ายดี

การเปิดใช้งาน DNSSEC ที่ฝั่ง Domain Name

วิธีการที่แสนจะง่ายที่สุด สำหรับโดเมนที่เป็น General Top-Level Domain (gTLD) เช่น .com, .net, .org เป็นต้น ที่ผมค้นพบก็คือ ใช้บริการ DNS ของ Cloudflare DNS Server เพียงแค่เราชี้ Name Server ไปหา Cloudflare โดเมนของเราก็จะได้รับการเข้ารหัส DNS เป็นที่เรียบร้อย อันเนื่องมาจาก Cloudflare DNS นั้นรองรับ DNSSEC อยู่แล้วนั่นเอง

แต่สำหรับโดเมนที่เป็น Country-Code Top-Level Domain (ccLTD) ยกตัวอย่างประเทศไทย เช่น .in.th, .co.th, .at.th เป็นต้น การเข้ารหัส DNSSEC จะเริ่มจาก .th => .in.th => yourname.in.th ซึ่งจะมี Chain เพิ่มขึ้นมาอีก 1 Chain นั่นเอง ในกรณีโดเมนของประเทศไทย ที่ทาง THNIC เป็นผู้ดูแลนั้น ณ ขณะนี้ก็รองรับการทำ DNSSEC เป็นที่เรียบร้อยแล้ว แต่การใช้งาน Cloudflared DNS Server เพียงอย่างเดียว จะทำให้ DNSSEC ไม่สมบูรณ์ ตามภาพตัวอย่างด้านล่างนี้

วิธีการเปิดใช้งาน DNSSEC สำหรับโดเมน .th ใช้บริการร่วมกับ Cloudflared DNS Server

ให้เราไปที่ Cloudflare.com > Your Domain > เมนู DNS > DNSSEC > คลิกที่ Enable DNSSEC จากนั้นทาง Cloudflare จะให้ข้อมูล Key ต่างๆ โดย Key ที่ต้องนำมากรอกคือ Key Tag, Algorithm, Digest Type และ Digest ให้เรานำเอาไปกรอกที่ระบบจัดการโดเมนกับทางผู้ให้บริการที่เราใช้บริการอยู่ หากไม่ทราบ แนะนำให้ติดต่อกับผู้ให้บริการจดโดเมน แจ้งขอเปิดใช้งาน DNSSEC นะครับ และเมื่อเราตั้งค่าเสร็จเรียบร้อย จะต้องรอให้ DNS Update ใช้เวลาประมาณ 1 Hour ตามที่ทาง Cloudflare แจ้งไว้ หลังจากเสร็จสมบูรณ์แล้ว ที่ฝั่งของ Cloudflare จะได้ตามรูปครับ

หลังจากทุกอย่างเรียบร้อย เราก็ลองมาตรวจสอบ DNS Chain อีกครั้ง ผลที่ได้ตามรูปครับ สังเกตว่าจะไม่มีลูกศรสีดำเหมือนก่อนหน้านี้แล้วครับ เป็นอันเสร็จสิ้นในส่วนของโดเมน หรือส่วนของผู้ดูแลระบบนะครับ

ทดสอบ DNSSEC ฝั่ง Client

เราสามารถตรวจสอบอุปกรณ์ของเราว่ารองรับ DNSSEC หรือไม่? ได้ที่ลิงก์ https://dnssec.vs.uni-due.de โดยเข้าเว็บแล้วกด Start Test

การเปิดใช้งาน DNSSEC ที่ฝั่ง Client

สำหรับฝั่ง Client ผมแนะนำให้ใช้ DNS ของ Cloudflare DNS Client หรือ Google DNS Client ซึ่งรองรับการใช้งาน DNSSEC อยู่แล้ว

Cloudflare DNS

Cloudflare DNS IPv4

• 1.1.1.1 และ 1.0.0.1
• 1.1.1.2 และ 1.0.0.2 (ป้องกันโดเมนไวรัส)
• 1.1.1.3 และ 1.0.0.3 (ป้องกันโดเมนไวรัส และป้องกันเว็บโป้ เหมาะสำหรับเด็ก)

Cloudflare DNS IPv6

• 2606:4700:4700::1111 และ 2606:4700:4700::1001
• 2606:4700:4700::1112 และ 2606:4700:4700::1002 (ป้องกันโดเมนไวรัส)
• 2606:4700:4700::1113 และ 2606:4700:4700::1003 (ป้องกันโดเมนไวรัส และป้องกันเว็บโป้ เหมาะสำหรับเด็ก)

Google DNS

Google DNS IPv4

• 8.8.8.8 และ 8.8.4.4

Google DNS IPv6

• 2001:4860:4860::8888 และ 2001:4860:4860::8844

ทำไมต้อง Cloudflare + Google

โดยส่วนตัว ผมจะแนะนำ 2 ตัวนี้นะครับ อันเนื่องมาจากความเร็วในการ Reslove DNS และมาตรฐานความปลอดภัยครับ มีความน่าเชื่อถือสูงด้วย

สำหรับการตั้งค่า DNS เราสามารถเลือกใช้โปรแกรม แอพ มาช่วยการตั้งค่าได้ รวมถึง เราสามารถเลือกใช้ทั้ง Cloudflare, Google อย่างละ 1 ตัวก็ได้นะครับ เพราะว่า DNS Setting เราจะสามารถกรอกได้ 2 อัน เพื่อป้องกันอีกตัวล่มนั่นเอง

Brute Force Attack คือ วิธีการ Hack เว็บไซต์ประเภทหนึ่ง ที่ Hacker ก็ชอบใช้ ด้วยวิธีการเขียน Robots เข้ามาที่เว็บไซต์ของเราเพื่อสุ่มรหัสผ่านเข้าสู่ระบบ ในกรณีที่เป็น WordPress ก็คือ สุ่มรหัสผ่านเข้ามายังหน้า /wp-login.php และยังมีอีกช่องทางหนึ่งที่หลายๆคนอาจจะไม่ทราบ นั้นคือ สุ่ม Login ผ่านทาง XMLRPC ที่ลิงก์ /xmlrpc.php ด้วยการใช้ WordPress XML-RPC API ได้ด้วยนะเออ

WordPress Brute Force Attack

สำหรับเว็บไซต์ WordPress ที่ใช้งาน Cloudflare CDN ที่กำหนดให้ Traffic วิ่งผ่าน Cloudflare นั่น เราจะเจอปัญหาดังนี้

1. IP ที่วิ่งเข้ามาที่ Server เป็น IP ของทาง Cloudflare ไม่ใช่ Real-IP ของผู้ใช้งานจริงๆ – แก้ไขได้ด้วยการ Config Server ให้แสดง Real-IP จาก Cloudflare ได้ แต่ต้องมีสิทธิ์เข้าถึง root เพื่อตั้งค่า Web Server (Cloudflare โชว์ IP จริงของผู้ใช้งานใน Nginx)
2. จากข้อที่ 1 เมื่อเราได้ Real IP มาแล้ว วิธีการทั่วๆไปที่เราใช้งานกันก็คือ ติดตั้ง WordPress Plugin ที่มีความสามารถในการ Block IP ที่ทำการเชื่อมต่อเข้ามา Brute Force Attack ซึ่งก็จะมีหลากหลายตัวเลือก จะยังไม่กล่าวถึงในโพสๆนี้
3. ใช้วิธีการป้องกันผ่านทาง Control Panel เช่น DirectAdmin (DA) มีโหมด “Parse service logs for brute force attacks” ซึ่งสามารถ Scan WordPress login log แล้วเอา IP ไป Block ที่ Firewall ได้ และสำหรับคนที่ใช้วิธีนี้ ผมบอกเลยว่าใช้ไม่ได้ครับ ถึงเราจะได้ Rea IP มา Block ก็จริง แต่ว่า Client เค้าเข้าผ่าน Cloudflate IP ซึ่งไม่ได้เข้ามาที่ Server เราตรงๆครับ ผ่าม! (DirectAdmin Firewall)

ปัญหาของ WordPress Plugin และ Server Security

คำถามคือ: ก็ป้องกันได้แล้วใช่ไหม หากผ่านทั้ง 2-3 ข้อข้างต้น? คำตอบคือ ใช่! แต่มันก็เหมือนปัญหาที่รอคอยวันที่จะระเบิดออกมา เพราะเราต้องคำนึงถึง Traffic ที่มันยังคงวิ่งผ่านเข้ามาที่ Server ของเราอยู่ดี ทำให้ Server ทำงานหนักโดยที่ไม่จำเป็น เพราะว่า Server มีการ Process Rule ต่างๆที่ WordPress Plugin ทำงาน ยิ่งโดน Brute Force Attack มากๆ จากหลายๆ IP ปัญหาก็คือ DB บวม (ถ้าเก็บ IP ใน Database),​ ไฟล์ .htaccess บวม (ในกรณี Block IP ผ่านทาง .htaccess) ส่งผลให้เว็บช้าลงเรื่อยๆ พอจะเห็นภาพแล้วใช่ไหมครับ

Cloudflare Brute Force Attack Rule

หลายคนอาจจะสงสัยว่า ก็ใช้ Cloudflare CDN แล้วหนิ Traffic ผ่านทาง Cloudflare แล้ว มันต้องกรอง Traffic ที่โจมตี Brute Force Attack ออกไปสิ! ผมแนะนำให้ลองกลับไปดู Access Log ของท่านด่วนครับ 555++

เพราะฉะนั้น เรามาเข้าเรื่องกันเลยครับ (เกริ่นมาซะเยอะเพื่อให้เห็นภาพชัดๆ) วิธีการตั้งค่า Cloudflare ให้ป้องกัน Brute Force Attack สำหรับ WordPress CMS ให้อยู่หมัด และ Traffic จะถูกกรองออกไปตั้งแต่ Cloudflare โดยที่ไม่เข้ามาถึง Server ของเราเลยครับ และไม่จำเป็นต้องติดตั้ง Plugin ป้องกัน Brute Force Attack แต่อย่างใด ให้ท่านไปที่ Cloudflare > Domain Name ของท่าน > Page Rules > Create Page Rule และตั้งค่าตามตัวอย่างด้านล่างนี้ครับ

แก้ไข1: แก้ไข Rule จาก *xvlnw.com/wp-login.php* => *xvlnw.com/*wp-login.php* แทนนะครับ เนื่องจากมี Log พบว่าสามารถ Brute Force มายัง xvlnw.com//wp-login.php ได้ ซึ่ง Rule ตามรูปยังไม่เข้ากฏ เลยปล่อยผ่านได้นั่นเอง

Rule ที่ผมสร้างขึ้น หมายถึง การบังคับให้ wp-login.php เป็นโหมด “I’am Under Attack” ประมาณว่า เราถูกโจมตีอยู่นะ ทาง Cloudflare จะทำการเปิดระบบความปลอดภัยขึ้นมา 2 แบบ ดังนี้

อธิบาย Rule ที่ผมใช้นี้ ผมจะใส่ * ไว้ทั้งข้างหน้า หมายถึง รวมทั้ง HTTP/HTTPS และรวมทุกๆ Sub Domain ที่ผมจะสร้างขึ้นในอนาคต ก็จะมีผลกับ Rule นี้ และข้างหลัง หมายถึง หากมี Parameter GET อะไรก็ตาม ก็ Bypass ผ่าน Rule นี้ไม่ได้ครับ และสำหรับใครที่ไม่ได้ใช้งาน WordPress XML-RPC API ผมแนะนำให้เพิ่มอีก Rule โดยการใส่ xmlrpc.php แทน wp-login.php นะครับ

เมื่อ Save and Deploy เสร็จ ก็จะได้ตามตัวอย่างเลยครับ จากนั้น วิธีการดู Access Log ที่เราตั้ง Rule ไว้ สามารถดูได้ที่เมนู Firewall > Overview เราจะเห็น Firewall Events สามารถคลิกดูรายละเอียดได้ครับ

เป็นอันเสร็จสิ้นแล้วครับ สำหรับวิธีการนี้ ยังสามารถเอาไปประยุกต์ใช้กับหน้า Login ของ Script ที่เราใช้งานกันอยู่ได้นะครับ และการตั้งค่านี้ ใช้ได้เฉพาะ Cloudflare CDN ถ้าใช้ Cloudflare DNS อย่างเดียว จะใช้งานไม่ได้นะครับ 😉

1. ล็อคอินที่ CloudFlare เลือกโดเมน และไปที่เมนู “Page Rules” จากนั้นคลิกที่ “Create Page Rule”

2. ใส่ URL ของโดเมนเรา และตามด้วย /* ด้านหลัง และเลือก Always Use HTTPS จากนั้นคลิกที่ “Save and Deploy”

3. จากนั้นก็จะได้ตามรูปด้านล่างนี้ เป็นอันเสร็จสิ้น