คำแนะนำขั้นสุดท้ายเกี่ยวกับ XMLRPC สำหรับ WordPress (+ วิธีปิดการใช้งาน)

การรักษาความปลอดภัยของเว็บไซต์เป็นสิ่งที่ยากจะแก้ไขด้วยวิธีที่ ถูกต้อง โดยเฉพาะกับปัญหาด้านความปลอดภัยที่เกี่ยวข้องกับ XML-RPC – ซึ่งมักใช้ในการโจมตีไซต์ WordPress มีข้อมูลมากมายบนอินเทอร์เน็ตที่ให้บริการโซลูชั่นทุกประเภท แต่ข้อใดถูกต้อง บทความนี้จะอธิบายวิธีการ วิธีแก้ปัญหา และอะไรคือทางออกที่ดีที่สุด มาดำน้ำกันเถอะ!

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

แม้แต่นักพัฒนาที่มีประสบการณ์บางคนก็ยังไม่เข้าใจ XMLRPC และภัยคุกคามด้านความปลอดภัยที่เกี่ยวข้องอย่างเต็มที่ มีความเป็นไปได้ค่อนข้างมากที่ไซต์/ไซต์ที่คุณจัดการมีไฟล์ XMLRPC ที่ใช้งานอยู่ซึ่งต้องการการดูแลทันที แต่คุณสามารถดำเนินการตามแผนปฏิบัติการที่มีประสิทธิภาพได้ก็ต่อเมื่อรู้ว่า XMLRPC ดำเนินการอย่างไร และวิธีใดดีที่สุดในการจัดการไฟล์อย่างปลอดภัย

แม้ว่า WordPress จะมี REST API ของตัวเองแล้ว แต่ไฟล์ xmlrpc.php ยังคงปรากฏอยู่ในคอร์และเปิดใช้งานโดยค่าเริ่มต้น โดยจะเปิดเผยไซต์ WordPress ต่อการโจมตีทางไซเบอร์ต่างๆ ในบทความนี้ เราจะเรียนรู้การใช้งานไฟล์นี้ ช่องโหว่ที่เกี่ยวข้อง และวิธีจัดการกับไฟล์นี้โดยไม่ทำให้ความปลอดภัยของเว็บไซต์ของคุณตกอยู่ในความเสี่ยง

ไฟล์ xmlrpc.php คืออะไร?

ในรูปแบบที่ง่ายที่สุด XML-RPC (การเรียกขั้นตอนระยะไกล) ถูกสร้างขึ้นสำหรับการสื่อสารข้ามแพลตฟอร์ม โปรโตคอลนี้ใช้ในการเรียกโพรซีเดอร์โดยใช้ HTTP เป็นการขนส่งและ XML เป็นตัวเข้ารหัส ไคลเอ็นต์ทำการเรียกเหล่านี้โดยส่งคำขอ HTTP ไปยังเซิร์ฟเวอร์และรับการตอบกลับ HTTP XML-RPC เรียกใช้ฟังก์ชันผ่านคำขอ HTTP จากนั้นฟังก์ชันเหล่านี้จะดำเนินการบางอย่างและส่งการตอบกลับแบบกำหนดค่าตายตัว

มาเปรียบเทียบสิ่งนี้กับการเรียก REST API เพื่อทำความเข้าใจแนวคิดอย่างเต็มที่

REST ใช้พารามิเตอร์ URL เพื่อระบุทรัพยากรในขณะที่ RPC ใช้พารามิเตอร์แบบสอบถามเพื่อจัดหาเป็นอาร์กิวเมนต์ของฟังก์ชัน

WordPress ใช้ XMLRPC เพื่อให้ผู้ใช้สามารถโต้ตอบกับไซต์ของตนได้จากระยะไกล มันยังคงใช้มันเพื่อขับเคลื่อนแอพมือถือและเพื่อรองรับปลั๊กอินเช่น JetPack, WooCommerce ฯลฯ การใช้ไฟล์ xmlrpc.php มีข้อเสีย แต่การปิดการใช้งานนั้นเป็นทางออกเดียวที่ใช้งานได้อย่างสมบูรณ์หรือไม่? ในการตอบคำถามนั้น เราต้องดูช่องโหว่ที่เกี่ยวข้องกับช่องโหว่นั้นก่อน และวิธีแก้ไขที่หลีกเลี่ยงได้มีอะไรบ้าง

แฮกเกอร์ที่ชั่วร้ายสามารถอยู่กับไฟล์ xmlrpc.php ได้อย่างไร?

การใช้ XMLRPC แฮกเกอร์ใช้ประโยชน์จาก Remote Procedure Calls (RPC) และเรียกใช้ฟังก์ชันเพื่อดึงข้อมูลที่ต้องการ ในไซต์ WordPress ส่วนใหญ่ ไฟล์ xmlrpc.php สามารถตรวจสอบย้อนกลับได้ง่าย และเพียงแค่ส่งข้อมูล XML โดยพลการ แฮกเกอร์จะควบคุมไซต์เพื่อเรียกใช้โค้ดที่พวกเขาเตรียมไว้เพื่อดำเนินการโจมตีบางประเภท

เพื่อทำความเข้าใจว่า WordPress XMLRPC ถูกบุกรุกอย่างไร มาดูการโจมตีทางไซเบอร์ที่ได้รับความนิยมมากที่สุดที่เกี่ยวข้องกัน

Bruteforce Attack

ในการโจมตี Bruteforce แฮ็กเกอร์พยายามเดาชื่อผู้ใช้และรหัสผ่านที่ถูกต้องโดยพยายามเข้าสู่ระบบหลายครั้ง น่าเสียดายที่ไซต์ WordPress จำนวนมากใช้รหัสผ่านผู้ดูแลระบบที่ไม่รัดกุมหรือไม่มีชั้นความปลอดภัยที่เพิ่มเข้ามาเพื่อหยุดผู้โจมตี ไซต์เหล่านั้นถูกบุกรุกได้ง่ายด้วยการโจมตีประเภทนี้

คนอื่นใช้รหัสผ่านที่รัดกุมและมีกลไกความปลอดภัยเช่น reCaptcha และการบล็อก IP อัตโนมัติที่มีผลกับการโจมตีแบบเดรัจฉาน แต่ถ้าแฮ็กเกอร์ตัดสินใจใช้ XMLRPC เธอไม่จำเป็นต้องเข้าถึงผู้ดูแลระบบ WordPress ด้วยซ้ำ

เครื่องมือทั่วไปจาก Kali Linux WPSCAN ใช้เพื่อระบุชื่อผู้ใช้ทั้งหมด และเมื่อเสร็จแล้ว แฮกเกอร์จะบังคับให้รหัสผ่านโดยใช้ไฟล์ xmlrpc.php โดยส่งคำขอ HTTP ต่อไปนี้ไปยังไซต์เหยื่อ

POST /xmlrpc.php HTTP/1.1
User-Agent: Fiddler
Host: www.example.com
Content-Length: 164

<methodCall>
<methodName>wp.getUsersBlogs</methodName>
<params>
<param><value>admin</value></param>
<param><value>pass</value></param>
</params>
</methodCall>

ในตัวอย่างข้างต้น แฮ็กเกอร์สามารถส่งรูปแบบต่างๆ ได้หลายพันรูปแบบ จนกว่าเขาจะเรียกรหัสผ่านที่ถูกต้อง

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

HTTP/1.1 200 OK
Server: nginx
Date: Sun, 26 May 2019 13:30:17 GMT
Content-Type: text/xml; charset=UTF-8
Connection: keep-alive
X-Powered-By: PHP/7.1.21
Cache-Control: private, must-revalidate
Expires: Sun, 02 Jun 2019 13:30:17 GMT
Content-Length: 403

<?xml version="1.0" encoding="UTF-8"?>
<methodResponse>
<fault>
<value>
<struct>
<member>
<name>faultCode</name>
<value><int>403</int></value>
</member>
<member>
<name>faultString</name>
<value><string>Incorrect username or password.</string></value>
</member>
</struct>
</value>
</fault>
</methodResponse>

การตอบสนองส่งคืนรหัส HTTP 200 และข้อความว่าชื่อผู้ใช้และรหัสผ่านที่ระบุไม่ถูกต้อง แฮ็กเกอร์ไม่ต้องกังวลเกี่ยวกับ reCaptchas หรือจำกัดความพยายามในการเข้าสู่ระบบผ่านช่องทาง XMLRPC เธอสามารถเรียกใช้รูปแบบต่างๆ ต่อไปได้จนกว่าจะได้รับรหัสผ่านที่ถูกต้อง

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

การโจมตี DDoS

Distributed Denial of Service (DDoS) เป็นหนึ่งในการโจมตีทางไซเบอร์ที่ร้ายแรงที่สุดที่สามารถทำให้เซิร์ฟเวอร์เป็นอัมพาตได้โดยการกดปุ่มดังกล่าวด้วยคำขอที่เกิดขึ้นพร้อมกันนับร้อยนับพัน แฮกเกอร์ใช้คุณสมบัติ pingback ของ WordPress พร้อมกับไฟล์ xmlrpc.php เพื่อดำเนินการโจมตีดังกล่าว

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

ไซต์ WordPress ที่ถูกบุกรุกแล้วหลายแห่งถูกใช้เพื่อดำเนินการตามวิธี pingback.ping เพื่อกำหนดเป้าหมายไปยังเหยื่อรายเดียว คำขอ HTTP GET และ POST ที่ล้นหลามขัดขวางการรับส่งข้อมูลปกติและทำให้เซิร์ฟเวอร์ขัดข้องในที่สุด

ขั้นแรก แฮกเกอร์จะตรวจสอบว่าไฟล์ xmlrpc.php เปิดใช้งานอยู่หรือไม่ โดยส่งคำขอต่อไปนี้

POST /xmlrpc.php HTTP/1.1
Host: withinsecurity.com
Connection: keep-alive
Content-Length: 175

<?xml version="1.0" encoding="utf-8"?>
<methodCall>
<methodName>demo.sayHello</methodName>
<params>
<param>
<value>admin</value>
</param>
</params>
</methodCall>

เมื่อได้รับการยืนยันว่าเปิดใช้งาน XMLRPC บนเว็บไซต์เป้าหมายแล้ว ผู้โจมตีจะเริ่มโจมตีโดยใช้เครือข่ายของไซต์ที่ถูกโจมตีเพื่อส่งคำขอ pingback หลายรายการไปยังไซต์เหยื่อ สามารถทำได้โดยอัตโนมัติจากหลายโฮสต์และใช้เพื่อทำให้เกิดการโจมตี DDoS จำนวนมากบนไซต์เหยื่อ

POST /xmlrpc.php HTTP/1.1
Host: withinsecurity.com
Connection: keep-alive
Content-Length: 293

<methodCall>
<methodName>pingback.ping</methodName>
<params>
<param>
<value><string>http://173.244.58.36/</string></value>
</param>
<param>
<value><string>https://example.com/blog/how-to-make-a-salad</string></value>
</param>
</params>
</methodCall>

การโจมตีพอร์ตข้ามไซต์ (XSPA)

Cross-site Port Attacks (XSPA) เป็นเรื่องปกติมากที่แฮ็กเกอร์จะแทรกสคริปต์ที่เป็นอันตรายเพื่อดึงข้อมูลบนพอร์ต TCP และที่อยู่ IP ในกรณีของ WordPress นั้น XMLRPC จะใช้พร้อมกับกลไก pingback เพื่อเลี่ยงการมาสก์ IP ใดๆ เช่น WAF พื้นฐาน เช่น Cloudflare

ในการโจมตี XSPA แฮ็กเกอร์ใช้วิธี pingback.ping เพื่อ pingback โพสต์บนเว็บไซต์เป้าหมายซึ่งจะส่งที่อยู่ IP ตอบกลับ แฮ็กเกอร์ใช้ดมกลิ่นเพื่อสร้างปลายทางสำหรับส่ง pingback และ URL สดของโพสต์ในบล็อก

แฮกเกอร์ส่งคำขอต่อไปนี้จากเซิร์ฟเวอร์ของเธอ

<methodCall>
<methodName>pingback.ping</methodName>
<params><param>
<value><string>http://<YOUR SERVER >:<port></string></value>
</param><param><value><string>http://<SOME VALID BLOG FROM THE SITE ></string>
</value></param></params>
</methodCall>

หากการตอบสนองมี faultCode และมีค่ามากกว่า 0 แสดงว่าพอร์ตเปิดให้คุณเริ่มส่งแพ็กเก็ต HTTP โดยตรง

วิธีการที่ไม่มีประสิทธิภาพในการบล็อกการโจมตี XMLRPC

จนถึงตอนนี้ในบทความ เราพบว่าไฟล์ xmlrpc.php มีแนวโน้มที่จะถูกโจมตีทางไซเบอร์อย่างร้ายแรง เช่น DDoS, Bruteforce และ Cross-site Port Attack ดังนั้นจึงเป็นเรื่องสำคัญที่จะต้องจัดการอย่างเหมาะสมเพื่อป้องกันการโจมตีเหล่านี้ .

โดยการลบ XMLRPC โดยสิ้นเชิง

คุณสามารถลบไฟล์ XMLRPC ที่จะทำให้เซิร์ฟเวอร์ของคุณเริ่มโยนข้อผิดพลาด 404 ให้กับใครก็ตามที่พยายามเข้าถึงไฟล์นั้น ข้อเสียของโซลูชันนี้คือ ไฟล์จะถูกสร้างขึ้นใหม่ทุกครั้งที่คุณอัปเดต WordPress

โดยการปิดการใช้งาน XMLRPC โดยสิ้นเชิง

อีกทางเลือกหนึ่งที่ใช้งานได้ดีกว่าคือการปิดใช้งานไฟล์ xmlrpc.php คุณสามารถทำได้โดยเพียงแค่เพิ่มบล็อกของโค้ดในไฟล์ . .htaccess ของคุณ ตรวจสอบให้แน่ใจว่าคุณทำสิ่งนี้ก่อนที่กฎ . .htaccess ที่ไม่เคยเปลี่ยนแปลงซึ่งเพิ่มโดย WordPress

<Files xmlrpc.php>
order allow,deny
deny from all
</Files>

การดำเนินการนี้จะปิดใช้งานไฟล์ xmlrpc.php สำหรับทุกแอปพลิเคชันหรือบริการที่ใช้งาน คุณสามารถอนุญาตที่อยู่ IP บางอย่างได้ ในกรณีที่คุณยังต้องการเข้าถึงไซต์ WordPress ของคุณผ่าน XMLRPC เพื่อที่คุณจะต้องเพิ่มคำสั่งต่อไปนี้:

<Files xmlrpc.php>
<RequireAny>
Require ip 1.1.1.2
Require ip 2001:db8::/32
</RequireAny>
</Files>

ข้อดี

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

ข้อเสีย

• การปิดใช้งาน XMLRPC จะเหมือนกับการปิดการเข้าถึงระยะไกลสำหรับแอปที่ใช้การเข้าถึงระยะไกลเวอร์ชันนี้ ซึ่งหมายความว่า Jetpack, แอพมือถือ WP หรือโซลูชันอื่นใดที่เชื่อมต่อกับไซต์ WordPress ของคุณผ่าน XMLRPC ไม่สามารถเชื่อมต่อกับไซต์ของคุณได้อีกต่อไป
• รหัสเดิมสำหรับแอปที่กำหนดเองอาจไม่ทำงานเช่นกัน

เหตุใดการติดตั้งปลั๊กอินความปลอดภัยจึงทำร้ายเว็บไซต์ของคุณ

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

ต่อไปนี้คือสาเหตุบางประการที่ทำให้การรักษาความปลอดภัยไซต์ของคุณด้วยปลั๊กอินไม่ใช่ตัวเลือกที่ดีที่สุด

• ปลั๊กอินความปลอดภัยมีผลในระดับแอปพลิเคชันเท่านั้นและไม่ได้ป้องกันเซิร์ฟเวอร์ของคุณจากการถูกโจมตี
• พวกเขาเพิ่มโค้ดที่ไม่จำเป็นบนไซต์ของคุณซึ่งจะลดระดับประสิทธิภาพและเพิ่มเวลาเป็นไบต์แรก (TTFB)
• ปลั๊กอินเหล่านี้บางส่วนทำอันตรายมากกว่าดี และถูกใช้โดยแฮกเกอร์เพื่อสร้างแบ็คดอร์ในเว็บไซต์ของคุณ
• ปลั๊กอินเหล่านี้ต้องการการจัดการบ่อยครั้งที่เพิ่มภาระงานมากขึ้น

จากการประเมินข้างต้น ไม่มีตัวเลือกใดที่เสนอวิธีแก้ปัญหาที่เหมาะสมที่สุดเพื่อจัดการกับปัญหาด้านความปลอดภัย XMLRPC สิ่งนี้นำเราไปสู่โดเมนเร่งความเร็ว บริการที่สร้างขึ้นเพื่อแก้ปัญหาที่เกี่ยวข้องกับความปลอดภัยที่ซับซ้อนและอีกมากมาย มาดูกันว่า Accelerated Domains สามารถแก้ปัญหา XMLRPC ให้คุณได้อย่างไร

โดเมนที่เร่งความเร็วจัดการกับปัญหา XMLRPC สำหรับลูกค้าได้อย่างไร

Accelerated Domains ช่วยแก้ปัญหาด้านประสิทธิภาพ ความปลอดภัย และความสามารถในการปรับขนาดที่ซับซ้อนได้อย่างมีประสิทธิภาพสูงสุด Accelerated Domains นำเสนอการรักษาความปลอดภัยที่มีการจัดการระดับองค์กร ซึ่งจะบล็อกการโจมตีทางไซเบอร์ทุกประเภท รวมถึงประเภทที่เกี่ยวข้องกับ XMLRPC

เครื่องมือรักษาความปลอดภัย อัจฉริยะของ Accelerated Domains ตั้งอยู่ด้านหน้าเซิร์ฟเวอร์และกรองได้เกือบ 40% ของการรับส่งข้อมูล HTTP ทั้งหมด โดยจะตรวจจับแม้กระทั่งการโจมตีทางไซเบอร์ที่ซับซ้อนที่สุดตั้งแต่ช่วงต้นของไทม์ไลน์ผ่านความสามารถในการวิเคราะห์พฤติกรรมอัจฉริยะที่ขับเคลื่อนด้วยการป้อนข้อมูลอย่างต่อเนื่องและความรู้เชิงปฏิบัติและการวิเคราะห์ปริมาณข้อมูลของ Servebolt Accelerated Domains ใช้เวทย์มนตร์โดยไม่ลดประสิทธิภาพของเว็บไซต์ของคุณ แต่อย่างใด อันที่จริงมันเร่งความเร็วได้

Accelerated Domains Proactive Security Engine ปกป้องเว็บไซต์ของคุณโดยอัตโนมัติจากการโจมตี DDoS ด้วยความจุของเครือข่ายที่เกือบ 60 Tbps จึงมีความพร้อมในการต้านทานการโจมตี DDoS ที่ใหญ่ที่สุดบนอินเทอร์เน็ต ในทำนองเดียวกัน มันมีกลไกการป้องกันที่มีประสิทธิภาพต่อการโจมตี Bruteforce ผ่านคุณสมบัติการจำกัดอัตราอัตโนมัติ โดยจะมีการระบุจำนวนคำขอที่สร้างจากแหล่งเดียวและจำกัดเพื่อป้องกันกิจกรรมที่เป็นอันตราย

ข้อดี

• โดเมนที่เร่งความเร็วช่วยลดช่องโหว่ด้านความปลอดภัยส่วนใหญ่ที่เกี่ยวข้องกับ XMLRPC ดังนั้นจึงไม่จำเป็นต้องปิดใช้งาน
• อนุญาตให้ผู้ใช้ใช้ปลั๊กอินต่อไป เช่น Jetpack, แอป WooCommerce และเครื่องมืออื่นๆ ที่ขึ้นอยู่กับไฟล์ xmlrpc.php
• การผสานรวมที่ไม่ยุ่งยากบนโดเมนใดๆ ดังนั้นจึงไม่จำเป็นต้องแก้ไขไฟล์ . .htaccess
• ไม่จำเป็นต้องติดตั้งปลั๊กอินเพิ่มเติม

ข้อเสีย

• มันไม่มี

ความคิดสุดท้าย

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