มีใครอธิบายได้ไหมว่า Cloudflare ข่มขู่ Canonical อย่างไร
(flyingpenguin.com)- บริการเว็บสาธารณะของ Canonical หยุดชะงักราว 20 ชั่วโมงตั้งแต่ 30 เมษายน 2026 เวลา 16:33 UTC และปลายทางคลังแพ็กเกจ Ubuntu ก็เริ่มมีปัญหาตามมาในภายหลัง
- กลุ่มที่อ้างความรับผิดชอบต่อการโจมตี ซึ่งมีแนวโน้มฝักใฝ่อิหร่าน ระบุว่าใช้บริการ DDoS แบบเสียเงินชื่อ Beamed และ Beamed ก็โฆษณาความสามารถในการหลบเลี่ยง Cloudflare และหมุนเวียน IP จากเครือข่ายที่อยู่อาศัย
- โดเมนของ Beamed และโครงสร้างพื้นฐานด้านการจดทะเบียน/การเราต์ที่เกี่ยวข้อง เชื่อมโยงไปยังบันทึกของ Cloudflare AS13335, Immaterialism, AS39287 และ Materialism s.r.l.
- การโอนย้าย AS39287 และการต่ออายุใบรับรอง apex ของ archive.ubuntu.com และ security.ubuntu.com ของ Canonical เกิดขึ้นภายในช่วง 24 ชั่วโมงเดียวกันในวันที่ 27 กุมภาพันธ์ 2026
- ระหว่างการโจมตี Canonical ย้ายเฉพาะ security.ubuntu.com และ archive.ubuntu.com ไปอยู่หลัง Cloudflare เท่านั้น ทำให้จากบันทึกสาธารณะดูเหมือนว่าไม่ใช่ค่าไถ่ที่ถูกจ่าย แต่เป็นค่าสมาชิกรายบริการที่ถูกย้ายแทน
เหตุขัดข้องของ Canonical และการย้ายไปใช้ Cloudflare
- เมื่อ 30 เมษายน 2026 เวลา 16:33:37 UTC ระบบมอนิเตอร์ของ Canonical แสดงให้เห็นว่า blog.ubuntu.com เป็น Service Down และภายในราว 10 นาที บริการเว็บสาธารณะอย่าง ubuntu.com, API คำแนะนำด้านความปลอดภัย, พอร์ทัลนักพัฒนา, เว็บไซต์องค์กร และแพลตฟอร์มการศึกษา ก็ล่มตามกัน
- เหตุขัดข้องกินเวลา ประมาณ 20 ชั่วโมง และถูกบันทึกว่า Service Restored เมื่อ 1 พฤษภาคม 2026 เวลา 12:44 UTC
- กลุ่มที่อ้างว่าเป็นผู้ก่อเหตุ ระบุว่าตนคือ Islamic Cyber Resistance in Iraq หรือ 313 Team ซึ่งเป็นกลุ่มแนวฝักใฝ่อิหร่าน และยอมรับว่าใช้บริการแบบเสียเงิน
- เครื่องมือโจมตีที่ถูกระบุคือ Beamed ซึ่งเป็นบริการเชิงพาณิชย์สำหรับโจมตีแบบปฏิเสธการให้บริการ จำหน่ายผ่านหลาย TLD โดย beamed.su ใช้เป็นเว็บไซต์การตลาด/บล็อก และ beamed.st ใช้เป็นพอร์ทัลล็อกอินลูกค้า
- บทความบล็อกของ Beamed ในเดือนเมษายน 2026 โฆษณาการ “หลบเลี่ยง Cloudflare” โดยเสนอ 3 เทคนิค รวมถึง การหมุนเวียน IP จากเครือข่ายที่อยู่อาศัย และการ “endpoint hunting” แบบแมนนวลเพื่อหาเซิร์ฟเวอร์ต้นทาง
- หนึ่งสัปดาห์หลังการโจมตี beamed.su และ beamed.st ยังออนไลน์อยู่ และทั้งคู่ยังแปลงชื่อโดเมนไปยังที่อยู่ของ Cloudflare AS13335
- ปลายทางคลังแพ็กเกจสองแห่งของ Canonical คือ security.ubuntu.com และ archive.ubuntu.com ก็เปลี่ยนไปใช้ที่อยู่ของ Cloudflare AS13335 ในเวลาต่อมาเช่นกัน
Beamed และโครงสร้างพื้นฐานด้านการจดทะเบียน/การเราต์
- โดเมนฝั่งผู้ใช้งานของ Beamed ถูกจดทะเบียนผ่านผู้รับจดทะเบียนชื่อ Immaterialism Limited ซึ่งขายบริการจดโดเมนแบบค่าธรรมเนียมคงที่และ JSON API
- Immateriali.sm ถูกพร็อกซีผ่าน เนมเซิร์ฟเวอร์ของ Cloudflare คือ tani.ns.cloudflare.com และ trey.ns.cloudflare.com
- Immaterialism Limited จดทะเบียนกับ Companies House ของสหราชอาณาจักรใน เลขทะเบียนบริษัท 15738452 และก่อตั้งเมื่อ 24 พฤษภาคม 2024
- ตอนก่อตั้ง กรรมการคือ Nicole Priscila Fernandez Chaves จากคอสตาริกา และใช้ที่อยู่แบบตู้ไปรษณีย์รวมบนถนน Great Portland Street ในลอนดอน
- เมื่อ 11 เมษายน 2025 Fernandez Chaves ลาออกจากตำแหน่งกรรมการ แต่ยังคง ผลประโยชน์ทางเศรษฐกิจเกิน 75% และ Naomi Susan Colvin ซึ่งพำนักในสหราชอาณาจักร ได้รับแต่งตั้งเป็นกรรมการคนใหม่ที่ที่อยู่เดียวกัน
การโอนย้าย AS39287 เมื่อ 27 กุมภาพันธ์ 2026
- เมื่อ 26 กุมภาพันธ์ 2026 Immaterialism Limited ยื่นการเปลี่ยนแปลงสองรายการต่อ Companies House ในวันเดียวกัน
- เปลี่ยนที่ตั้งสำนักงานจดทะเบียนจาก 85 Great Portland Street เป็น 167-169 Great Portland Street
- เปลี่ยนรายละเอียดของ Fernandez Chaves ในฐานะ person with significant control
- วันถัดมา 27 กุมภาพันธ์ 2026 โครงสร้างพื้นฐานการเราต์ ที่ประกาศพื้นที่ IP ของ Beamed และบริการที่เกี่ยวข้อง ได้ย้ายเขตอำนาจกำกับดูแล
- ระบบอัตโนมัติที่ประกาศพื้นที่แอดเดรสของ Materialism คือ AS39287 และ RIPE จัดสรรหมายเลข AS นี้เมื่อ 24 มกราคม 2006
- อัตลักษณ์ด้านการเราต์ของ AS39287 ยังคงเดิม แต่บันทึกผู้ดำเนินการที่จดทะเบียนและประเทศถูกเปลี่ยนไปสองครั้ง
-
ยุคของ Privactually Ltd และ FLATTR-AS
- ราวปี 2017 ถึงราวปี 2020 AS39287 อยู่ภายใต้บริษัทไซปรัส Privactually Ltd และดำเนินงานในชื่อ FLATTR-AS
- Flattr เชื่อมโยงกับโครงการไมโครเพย์เมนต์ของ Peter Sunde Kolmosoppi หนึ่งในผู้ร่วมก่อตั้ง The Pirate Bay
- ภายใต้การจดทะเบียนนั้น ช่องทางติดต่อ abuse ของ prefix คือ abuse@shelter.st
-
ยุคของ ab stract ltd
- ตั้งแต่ปี 2020 ถึง 2026 หมายเลข AS เดิมนี้ถูกโอนใหม่ให้กับบริษัทฟินแลนด์ ab stract ltd ที่ตั้งอยู่ที่ Urho Kekkosen katu 4-6E, เฮลซิงกิ
- ออบเจ็กต์ maintainer ในบันทึก RIPE คือ BKP-MNT และบุคคลที่ปรากฏในบันทึกคือ Peter Kolmisoppi ผู้ร่วมก่อตั้ง The Pirate Bay อีกคนหนึ่ง
- เนมเซิร์ฟเวอร์ authoritative ของโดเมนผู้ดำเนินการ abstract.fi คือ Njalla ทั้งสามตัว: njalla.fo, njalla.no และ njalla.in
- Njalla คือบริการพร็อกซีโดเมนแบบ privacy-as-a-service ที่ Peter Sunde สร้างขึ้น และดำเนินงานผ่าน 1337 Services LLC ในเซนต์คิตส์และเนวิส
-
การโอนใหม่ไปยัง Materialism s.r.l.
- เมื่อ 27 กุมภาพันธ์ 2026 เวลา 12:11:48 UTC RIPE บันทึกการโอนใหม่ครั้งที่สาม และ AS39287 กลายเป็นทรัพย์สินของ Materialism s.r.l. ที่ตั้งอยู่บน Bulevardul Metalurgiei, บูคาเรสต์ ประเทศโรมาเนีย
- การโอนใหม่นี้ครอบคลุม 45.158.116.0/22, 2001:67c:2354::/48, 2a02:6f8::/32 โดย IPv6 prefix ตัวสุดท้ายถูกจัดสรรครั้งแรกตั้งแต่เดือนสิงหาคม 2008 ภายใต้ระบอบก่อนหน้า
- ตลอดช่วงเปลี่ยนผ่านทั้งสามรอบ การตั้งค่า peering ยังคงเดิม และ AS39287 ยังคง import/export กับ AS42708(Telia), AS37560(GTT), AS12552(GlobalConnect), AS34244(Voxility), AS54990 ด้วยโครงแบบเดิม
- เส้นทางเดิมยังออกไปยัง upstream network เดิม และสิ่งที่เปลี่ยนในบันทึกสาธารณะมีเพียงชื่อผู้ดำเนินการที่มองเห็นได้
- ในรายชื่อผู้รับจดทะเบียนโดเมนที่ IANA รับรองนั้น ฐานลูกค้าของ Immateriali.sm มี 1337 Services LLC ซึ่งเป็นนิติบุคคลธุรกรรมเบื้องหลัง Njalla รวมอยู่ด้วย
การหมุนเวียนใบรับรองของ Canonical ที่เกิดขึ้นวันเดียวกัน
- บันทึก certificate transparency ของปลายทางคลังแพ็กเกจของ Canonical แสดงหลายรายการภายใน ช่วง 24 ชั่วโมง เดียวกับที่เกิดการโอนย้ายการเราต์
- เมื่อ 27 กุมภาพันธ์ 2026 เวลา 06:14:03 UTC Let’s Encrypt ออกใบรับรอง apex ใหม่ให้ archive.ubuntu.com
- วันเดียวกัน เวลา 19:13:35 UTC Let’s Encrypt ออกใบรับรอง apex ใหม่ให้ security.ubuntu.com
- ในบันทึก certificate transparency ปี 2026 ของ security.ubuntu.com ก่อนรายการนี้มีเพียงใบรับรองมิเรอร์รายภูมิภาค และไม่ปรากฏ ใบรับรอง apex ที่เก่ากว่านี้ใน log ที่มองเห็นได้
- วันเดียวกัน เวลา 22:14:03 UTC มีการออกใบรับรองใหม่ให้ clouds.archive.ubuntu.com
- ใน 9 วันถัดมา รูปแบบเดียวกันนี้เกิดซ้ำกับ azure.archive.ubuntu.com, wildcard-gce.archive.ubuntu.com, wildcard-ec2.archive.ubuntu.com
- ใบรับรองใหม่แต่ละใบถูกออกให้กับ hostname แบบ apex ไม่ใช่มิเรอร์รายภูมิภาค
- ใบรับรองต้นทางที่ใช้ได้สำหรับ hostname แบบ apex ถือเป็นเงื่อนไขเบื้องต้นในการนำ hostname เหล่านั้นไปวางไว้หลังเครือข่ายส่งมอบคอนเทนต์
- การเกิดพร้อมกันของการโอนย้ายการเราต์และการหมุนเวียนใบรับรองของ Canonical ในวันที่ 27 กุมภาพันธ์ 2026 ไม่สามารถอธิบายได้จากบันทึกสาธารณะเพียงอย่างเดียว
ไทม์ไลน์การโจมตี
- ไทม์ไลน์นี้อิงจากบันทึกเหตุขัดข้องระดับนาทีบนหน้า status.canonical.com ของ Canonical ซึ่งถูกรักษาไว้เป็นสแนปช็อตใน Ubuntu Discourse thread 81470 เมื่อราว 22:52 UTC ของวันที่ 30 เมษายน
-
10 นาทีแรก: บริการเว็บสาธารณะล่มในวงกว้าง
- 16:33:37: blog.ubuntu.com ถูกแสดงเป็น Down ครั้งแรก และบันทึกเป็น Incident Start Time
- 16:34:10: canonical.com Down
- 16:34:45: academy.canonical.com Down
- 16:35:15: developer.ubuntu.com Down
- 16:35:22: maas.io Down
- 16:36:09: jaas.ai Down, Ubuntu Security API(CVEs) Down
- 16:37:13: Ubuntu Security API(Notices) Down
- 16:41:57: assets.ubuntu.com Down
- 16:43:25: ubuntu.com Down
- ฟีดคำแนะนำด้านความปลอดภัยล่มภายใน 3 นาทีแรก หลังเริ่มเหตุการณ์ และ apex ฝั่งการตลาดล่มภายใน 10 นาที
- ณ จุดนี้ โฮสต์ที่ยังไม่ถูกโจมตีคือ security.ubuntu.com และ archive.ubuntu.com ซึ่งเป็นปลายทางคลังแพ็กเกจที่สามารถทำให้
apt updateล้มเหลวในทุกการติดตั้ง Ubuntu ได้
-
อีก 3 ชั่วโมงต่อมา ปลายทางคลังแพ็กเกจถูกโจมตี
- 19:34:38: security.ubuntu.com ถูกแสดงเป็น Down ครั้งแรก
- 19:40:01: archive.ubuntu.com Down
- ปลายทางคลังแพ็กเกจเริ่มมีปัญหาหลังเริ่มการโจมตีไปประมาณ 3 ชั่วโมง
- ตั้งแต่ 19:40 UTC และต่อเนื่องอีก 70 นาที ปลายทางคลังแพ็กเกจทั้งสองสลับสถานะระหว่าง Down และ Operational บนบอร์ดสถานะ
- บันทึกสถานะในช่วงนั้นบันทึกการสลับ Down/Operational ของ security.ubuntu.com 5 ครั้ง และของ archive.ubuntu.com 4 ครั้ง
- รูปแบบนี้สอดคล้องกับการพยายามบรรเทาที่ต้นทาง เช่น rate limiting, regional filtering หรือ traffic scrubbing แต่ไม่สำเร็จภายใต้ภาระต่อเนื่องขนาด 3.5 Tbps ตามที่มีการประกาศ
-
เสถียรหลัง 20:50 UTC
- 20:50:29: archive.ubuntu.com Operational
- 20:51:13: security.ubuntu.com Operational
- หลังจากช่วงห่างกัน 44 วินาที นี้ ในสแนปช็อตที่ถูกจับต่อเนื่องจนถึง 22:52 UTC โฮสต์ทั้งสองไม่กลับไปเป็น Down อีก
- อาการ flapping หยุดลง และปลายทางทั้งสองกลับมาเสถียรพร้อมกันโดยห่างกันไม่ถึง 1 นาที เมื่อผ่านไป 4 ชั่วโมง 17 นาที หลังเริ่มโจมตี
- ในขณะเขียนนี้ security.ubuntu.com และ archive.ubuntu.com แปลงชื่อได้เป็น 104.20.28.246 และ 172.66.152.176 ซึ่งเป็นที่อยู่ที่ Cloudflare ดำเนินงานบน AS13335
- โฮสต์อื่นที่ได้รับผลกระทบ เช่น ubuntu.com, canonical.com, launchpad.net, snapcraft.io, login.ubuntu.com ยังแปลงชื่อไปยังช่วง AS41231 ของ Canonical ที่ 185.125.189.x และ 185.125.190.x
- เนมเซิร์ฟเวอร์ authoritative ของ ubuntu.com ยังคงเป็น ns1.canonical.com, ns2.canonical.com, ns3.canonical.com
การย้ายไปใช้ Cloudflare แบบเลือกเฉพาะจุด
- Canonical ย้ายเฉพาะ A record ของ security.ubuntu.com และ archive.ubuntu.com ซึ่งเป็นสองเป้าหมายที่ผู้โจมตีเล็งใช้เพื่อปฏิเสธการเข้าถึงคลังแพ็กเกจ ไปยัง Cloudflare
- บริการที่เหลือยังคงอยู่บนโครงสร้างพื้นฐานของ Canonical เอง และทนรับการโจมตีต่อไปภายใต้มาตรการบรรเทาเดิม
- โฮสต์ที่ไม่ใช่คลังแพ็กเกจยังคง flapping ไปจนสุดสแนปช็อต แล้วจึงฟื้นตัวจากการผสมกันของ upstream filtering กับการบรรเทาหรือการยุติการโจมตี
- การยอมรับต่อสาธารณะครั้งแรกของ Canonical ถูกโพสต์เมื่อ 1 พฤษภาคม เวลา 07:13 UTC ซึ่งเป็นเวลา 10 ชั่วโมงหลังจาก ปลายทางคลังแพ็กเกจกลับมาเสถียรหลัง Cloudflare
- การกู้คืนเต็มรูปแบบของทุกองค์ประกอบได้รับการยืนยันเมื่อ 1 พฤษภาคม เวลา 12:44 UTC หรือประมาณ 20 ชั่วโมงหลัง เริ่มการโจมตี
โครงสร้างที่ชวนให้ถกเถียงว่าเป็น “การข่มขู่” หรือไม่
- บนเส้นทางที่ตรวจสอบได้จากสาธารณะ ไม่มีการจ่ายค่าไถ่ ถูกย้ายออกไป
- กระแสคริปโตขนาดที่สอดคล้องกับเหตุการณ์นี้ก็ไม่ปรากฏในบันทึกสาธารณะ
- ไม่มีการเผยแพร่จดหมายเรียกร้อง และหากมีการเจรจาก็น่าจะเกิดขึ้นแบบไม่เปิดเผย
- สิ่งที่เห็นว่าเคลื่อนย้ายในบันทึกสาธารณะคือ ค่าสมาชิกรายบริการ
- ปลายทางที่มีมูลค่าสูงสุดสองจุดของ Canonical คือปลายทางคลังแพ็กเกจที่สามารถทำให้การอัปเดตความปลอดภัยอัตโนมัติล้มเหลวทั่วโลก ถูกเปลี่ยนไปเป็นความสัมพันธ์ด้านบริการกับ Cloudflare
- ขณะเดียวกัน ลูกค้าปัจจุบันรายอื่นของ Cloudflare ก็มี ผู้ให้บริการ booter ที่กำลังถูกใช้โจมตี Canonical รวมอยู่ด้วย
- เมื่อ Beamed ยังถูกจ้างใช้ได้ต่อไป และระยะเวลาที่โครงสร้างพื้นฐานของ Canonical หยุดชะงักทำหน้าที่ราวกับเป็นเส้นตาย จึงตีความได้ว่าเกิดธุรกรรมขึ้นโดยไม่จำเป็นต้องมีการเรียกร้องต่อสาธารณะแยกต่างหาก
- ผู้คุ้มกันจึงได้รายได้จากทั้งสองด้าน ขณะที่ในแต่ละขณะก็ยังคงอยู่ในกรอบความเป็นกลางต่อเนื้อหาและถ้อยคำของข้อกำหนดการให้บริการ
การเปรียบเทียบกับการผูกขาดเครือข่ายสื่อสารผลแข่งม้า
- ในทศวรรษ 1930 General News Bureau ของ Moses Annenberg ขายผลการแข่งขันม้าอย่างรวดเร็วให้กับ bookmaker ทั่วสหรัฐฯ
- bookmaker ที่สมัครใช้บริการอยู่รอด ส่วนผู้ที่ไม่สมัครถูกเปรียบเทียบว่าเสียความสามารถในการตั้งอัตราต่อรอง เพราะคู่แข่งที่สมัครใช้งานได้เปรียบ
- รายได้ของ Annenberg พึ่งพา การผูกขาด การยืนยันผลแข่งม้า และการผูกขาดนี้ทำให้ bookmaker นอกระบบต้องพึ่งพาสายส่งข่าวของเขาเพื่อดำเนินกิจการ
- รัฐบาลกลางสหรัฐฯ ทำลายการผูกขาดนี้ด้วย การฟ้องร้องด้านภาษี ในปี 1939 และ wire service ที่ตามมาถูกกวาดล้างต่อไปจนถึงทศวรรษ 1940
- รายงานปี 1942 ที่เกี่ยวข้องกับ Mayor LaGuardia ระบุว่ามีการจับกุม 9 คนจากการกวาดล้าง “wire service มูลค่า 1 ล้านดอลลาร์ต่อปี” ที่ให้บริการนักพนันม้าและ poolroom bookmaker ในนิวยอร์ก นิวเจอร์ซีย์ Westchester และ Nassau County
- นำไปสู่ข้อวิจารณ์ว่า ตลาดการป้องกัน DDoS ในปัจจุบันอยู่ในตำแหน่งคล้ายกันเมื่อมองจากความสัมพันธ์กับตลาด booter
- รายได้ของ Cloudflare ขึ้นอยู่กับการอยู่ในจุดที่สามารถรับรองได้ว่าบริการต่าง ๆ เข้าถึงได้บนอินเทอร์เน็ตสาธารณะ และเมื่อบริษัทเดียวกันยังเป็นผู้ให้บริการโฮสต์แก่ booter ด้วย บทบาททั้งด้านภัยคุกคามและการป้องกันก็ถูกรวมเข้าเป็นกระแสรายได้เดียวกัน
ร่องรอยที่เหลืออยู่ในบันทึกสาธารณะ
- ร่องรอยของเหตุการณ์นี้กระจายอยู่ในหลายรีจิสทรีและเอกสารเปิดเผยของบริษัท
- Companies House มีเอกสารบริษัท, ฐานข้อมูล RIPE มีการโอนย้ายการเราต์, log ของ certificate transparency มีวันที่หมุนเวียนใบรับรอง apex และหน้าสถานะของ Canonical มีเวลาที่บันทึกเปลี่ยนแปลง
- ในวันที่ 27 กุมภาพันธ์ 2026 มีการเตรียมการ 3 อย่างเสร็จสิ้นภายในช่วงปฏิทินเดียวกัน
- Materialism s.r.l. เข้าครอบครอง AS39287 และ IPv6 prefix เก่าแก่ที่แนบมาด้วย
- Immaterialism Limited ยื่นเอกสารต่อ Companies House
- ฝั่ง Canonical ต่ออายุใบรับรองต้นทางของ hostname แบบ apex สองตัวที่จะถูกย้ายไปอยู่หลังเครือข่ายส่งมอบคอนเทนต์ในภายหลัง
- ช่วงเวลา 4 ชั่วโมง นับจากเริ่มโจมตีจนถึงเมื่อที่อยู่ Cloudflare ปรากฏกับ hostname คลังแพ็กเกจของ Canonical สามารถตีความได้ว่าเป็นช่วงที่การตัดสินใจซื้อถูกเคลื่อนย้าย
- เมื่อ 30 เมษายน 2026 เวลา 20:50:29 UTC ความสัมพันธ์ลูกค้าใหม่จึงปรากฏให้เห็นได้ในที่สาธารณะ
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เท่าที่ฉันเข้าใจ คำกล่าวที่ว่า เช่ากำลังโจมตีจาก Cloudflare นั้นไม่แม่นยำ
เป็นความจริงที่กลุ่มนั้นโฮสต์เว็บไซต์ไว้หลัง Cloudflare แต่ฉันไม่เคยเห็นการอ้างว่าโครงสร้างพื้นฐานของ Cloudflare ถูกใช้ในการโจมตีเอง
ทั้งบทความดูเหมือนจะพูดปนกันระหว่างการโฮสต์เว็บไซต์แนะนำที่ผู้โจมตีเป็นคนดูแล กับการโฮสต์การโจมตีจริง
ไม่ว่าจะเป็นเว็บไซต์หรือโครงสร้างพื้นฐานควบคุม ล้วนเป็นเป้าหมายการโจมตี
การป้องกัน DDoS มีบริษัทอย่าง Akamai ให้บริการ ราคาต้องติดต่อสอบถาม ใช้ได้เฉพาะองค์กรใหญ่ และสมัครแบบไม่เปิดเผยตัวตนไม่ได้เด็ดขาด
Cloudflare เปลี่ยนอุตสาหกรรมนี้ด้วยการให้การป้องกัน DDoS ฟรีกับทุกคน รวมถึงบริการ DDoS-for-hire ทำให้เมื่อพวกเขาไม่สามารถไล่อีกฝ่ายให้ออฟไลน์ได้อีก อุตสาหกรรม DDoS จึงเติบโตอย่างจริงจัง
ดูเหมือนจะไม่ใช่แค่ทราฟฟิกที่ถูกพร็อกซีด้วย อย่างน้อยก็ไม่มีเฮดเดอร์
CF-Connecting-Ipไม่รู้ว่าใช้กับการโจมตีนี้หรือไม่ แต่ถูกใช้ในบางการโจมตี
ถึงอย่างนั้น Cloudflare ก็ยังน่ารำคาญน้อยกว่าผู้ให้บริการโครงสร้างพื้นฐานรายอื่นเกือบทั้งหมดมาก
และฉันก็ไม่แน่ใจว่าตรรกะนี้สมเหตุสมผลแค่ไหน
มี เซิร์ฟเวอร์สั่งการและควบคุม มากมายที่โฮสต์บน AWS และก็มีเหยื่อของ AWS จำนวนมาก แต่คงยากจะบอกว่า AWS ต้องรับผิดหรือกำลังข่มขู่ใคร คำตอบโดยมากก็คงไม่ใช่
ทุกคนคงเลือกเว็บไซต์ได้สักไม่กี่แห่งที่คิดว่าไม่ควรใช้บริการโฮสต์ของ Cloudflare
ปัญหาคือรายการนั้นของแต่ละคนไม่เหมือนกัน
Cloudflare ควรต้อง โฮสต์อะไรก็ได้ จนกว่าจะได้รับคำสั่งที่ชอบด้วยกฎหมาย
ถ้าเริ่มตัดสินว่าเนื้อหาของเว็บไซต์ “เหมาะสม” หรือไม่ด้วยเกณฑ์กำกวมบางอย่าง ผู้คนก็มีเหตุผลเต็มที่ที่จะโกรธมาก
คำกล่าวว่า เช่ากำลังโจมตีจาก Cloudflare ต้องมีหลักฐานรองรับ และเท่าที่ฉันรู้ ผู้โจมตีไม่ได้ใช้โครงสร้างพื้นฐานของ Cloudflare กับการโจมตีจริง
บรรยากาศโดยรวมของบทความนี้กับบทความที่เกี่ยวกับ Google ต่างกันมากจนฉันค่อนข้างงง
ฉันไม่แน่ใจว่า Cloudflare เป็นผู้เล่นที่มุ่งร้ายหรือไม่ แต่คิดว่าทุกคนควรปฏิบัติต่อพวกเขาเหมือนเป็นเช่นนั้น
ถ้าบริการที่โฆษณาระบุชัดว่ามุ่งโจมตี Cloudflare ก็ดูเหมือนจะเป็นการละเมิดข้อกำหนดตามสามัญสำนึกอยู่แล้ว
ข้อกำหนดของ Cloudflare เองก็ระบุไว้แบบนั้น
https://www.cloudflare.com/en-ca/website-terms/
ใน “7. PROHIBITED USES” ระบุว่าห้ามใช้เว็บไซต์หรือบริการออนไลน์ในลักษณะที่อาจทำลาย ปิดการใช้งาน ทำให้เกินภาระ รบกวน หรือบั่นทอนเซิร์ฟเวอร์ API หรือเครือข่ายที่เชื่อมต่อกับ Cloudflare และห้ามส่งไวรัส เวิร์ม โทรจัน หรือสิ่งทำลายอื่น ๆ รวมถึงห้ามพยายามเข้าถึงโดยไม่ได้รับอนุญาต เช่น การแฮ็กหรือการขุดคริปโต
นอกจากนี้ Cloudflare ยังสงวนสิทธิ์ในการบล็อกเนื้อหาบน Distributed Web Gateway ที่พิจารณาแต่เพียงผู้เดียวว่าเป็นสิ่งผิดกฎหมาย เป็นอันตราย หรือฝ่าฝืนข้อกำหนด ซึ่งรวมถึงการเผยแพร่มัลแวร์ การส่งเสริมฟิชชิง และ การใช้งานเชิงเทคนิคในทางที่ผิด อื่น ๆ
ต่อให้ปิดเว็บไซต์แนะนำของผู้โจมตี เขาก็ย้ายไป GitHub Pages หรือโฮสต์เว็บไซต์สแตติกฟรีอีกมากมายได้
ในสายตาฉัน ไม่มีหลักฐานเลย ว่า Cloudflare เป็นผู้ทำให้การโจมตีจริงเกิดขึ้นได้
ไม่ได้ตัดสินใจจะอยู่นอกเกมทั้งหมด
คำกล่าวที่ว่าไม่แทรกแซงควรอ่านว่าเป็นการยอมรับโดยนัย
เพราะเรารู้ว่าถ้าเป็นผู้ใช้ที่พวกเขาไม่พอใจมากพอ พวกเขาก็ไล่ออกจริง
บทความแนวนี้ดูเหมือนตั้งอยู่บนความเชื่อประหลาดที่ว่า Cloudflare ไม่ตอบสนองต่อรายงานด้านความปลอดภัยหรือคำสั่งทางกฎหมาย
จากประสบการณ์ของฉัน Cloudflare ตอบสนองได้เหมาะสมและค่อนข้างรวดเร็วเมื่อเทียบกับทั้งอุตสาหกรรม
พวกเขาอาจทำเชิงรุกกว่านี้หรือเพิ่มแรงเสียดทานในขั้นตอนสมัครได้ แต่เหตุผลที่ไม่อยากทำตัวเป็น ตำรวจอินเทอร์เน็ต ก็ฟังขึ้น
ฉันไม่คิดว่าการจะโฮสต์เนื้อหาบนอินเทอร์เน็ตควรถูกบังคับให้ส่งบัตรเครดิต เบอร์โทรศัพท์ หรือสำเนาบัตรประชาชน
ถ้าไม่ทำ เกาะอื่นก็จะตัดการเชื่อมต่อกับฝั่งนั้น
การบังคับใช้กฎหมายเป็นทางเลือกสุดท้าย เพราะศาลไม่ได้ทำงานเร็วเท่าความเร็วของอินเทอร์เน็ต และเพราะความเป็นข้ามพรมแดนของอินเทอร์เน็ต ไม่มีใครอยากได้กฎระเบียบจากรัฐที่สั่งลงมาจากข้างบน
Cloudflare ใช้เงินทุนร่วมลงทุนทำของแพงให้ฟรีและซื้อส่วนแบ่งตลาด
ถ้าคุณทำให้ร้านขายของชำทั้งหมดต้องย้ายมาอยู่บนเกาะของคุณ คุณก็สามารถเปิดแหล่งกบดานของอาชญากรรมได้โดยไม่ต้องกลัวว่าจะถูกคนอื่นกีดกัน
ไปถามคนที่ต่อสู้กับบอตเน็ต มัลแวร์ หรือการหลอกลวงออนไลน์ได้
พอเจอ ทางตันของ Cloudflare ก็แทบต้องยอมแพ้
หน่วยงานบังคับใช้กฎหมายคงไม่มารับคดีที่มีคอมพิวเตอร์ติดเชื้อแค่ 7,000 เครื่อง และ Cloudflare ก็ไม่สืบสวนเองเพื่อจัดการด้วย
และในความเป็นจริงฉันก็ไม่ได้ทำแบบนั้น
ฉันให้หลักฐานมากพอที่จะเริ่มการตรวจสอบภายในหรือติดต่อกับลูกค้าที่กระทำผิดได้แล้ว แต่พวกเขาไม่ทำ
ถ้าเป็น stresser สิ่งที่มองเห็นจากภายนอกก็คงมีแค่หน้าเข้าสู่ระบบ
เว็บไซต์พวกนี้ก็ไม่ได้โฆษณาตรง ๆ ต่อสาธารณะว่าตัวเองทำอะไร
Cloudflare วางตำแหน่งตัวเองเป็น โครงสร้างพื้นฐาน
นั่นหมายความว่าพวกเขามองว่าตัวเองไม่ต้องรับผิดชอบต่อเนื้อหาที่ขนส่ง
โดยปกติ ถ้าจะปกป้องระบบของฉันจากระบบแย่ ๆ บนอินเทอร์เน็ต ฉันสามารถบล็อกในระดับ IP ได้
แต่ Cloudflare พร็อกซีทุกอย่างตั้งแต่ระบบที่ดี ระบบที่เลว และทุกอย่างระหว่างนั้นในระดับ IP
ปกติแล้วคุณอาจบล็อกเว็บไซต์ที่องค์กรอาชญากรรมดำเนินการอยู่ในระดับ IP หรือติดต่อ
abuse@ขององค์กรที่โฮสต์เนื้อหาให้ช่วยบล็อกหรือรายงานได้Cloudflare ทำให้ทั้งสองอย่างทำไม่ได้
และเมื่อคุณส่งรายงานการใช้งานในทางที่ผิดไปยัง Cloudflare ก็ไม่มีหลักประกันด้วยซ้ำว่าพวกเขาจะไม่ส่งข้อมูลติดต่อของคุณต่อไปยังฝ่ายที่คุณร้องเรียนตรง ๆ
แม้หลายปีมานี้จะค่อย ๆ ปรับท่าทีให้ดูรับผิดชอบมากขึ้น แต่แก่นยังเหมือนเดิม
ต่อให้คุณอยากส่งรายงาน
abuse@ไปยังระบบที่ซ่อนอยู่หลัง Cloudflare คุณก็ไม่อาจมั่นใจได้เลยว่าพวกเขาจะไม่เพียงแค่ส่งต่อโดยที่คุณไม่รู้ว่าถูกส่งไปให้ใครบทความที่เกี่ยวข้องเมื่อสัปดาห์ที่แล้ว:
“Why is Cloudflare protecting the DDoS'er (beamed.st) attacking Ubuntu servers?”
https://news.ycombinator.com/item?id=48025001
แม้ฉันจะไม่ชอบบทบาทของ CF บนอินเทอร์เน็ตยุคใหม่ แต่บทความนี้ก็ดูเหมือนเป็น ชุดของการคาดเดา ที่พยายามโยงจุดต่าง ๆ เข้าหากันโดยไม่มีหลักฐาน นอกจากความจริงที่ว่าการต่ออายุใบรับรองของ Canonical กับการย้ายบริษัทเกิดขึ้นในวันเดียวกัน
แต่ก็มีประเด็นข้างเคียงที่น่าดูอยู่
ดูเหมือนว่า Njalla จะเพิ่งปรับโครงสร้างองค์กรหรือเปลี่ยนเจ้าของอย่างเงียบ ๆ เมื่อไม่นานนี้[1] และ Njalla กับ immateriali.sm ก็ดูเหมือนจะเป็นนิติบุคคลที่เกี่ยวข้องกัน[2]
https://xn--gckvb8fzb.com/njalla-has-silently-changed-a-word...
https://www.wipo.int/amc/en/domains/decisions/pdf/2026/dio20...
อย่างที่บทความสรุปสั้น ๆ ไว้ Cloudflare ปกป้องผู้โจมตีด้านหน้าให้ฟรี และไปเก็บเงินเหยื่อหากต้องการการเยียวยา
บริการป้องกัน DDoS อาจถูกมองได้ว่าเป็นการเก็บค่าคุ้มครองในโลกดิจิทัล และสร้างแรงจูงใจให้ปล่อยให้ผู้โจมตีโจมตีต่อไป
ทำนองว่า “อินเทอร์เน็ตมันอันตราย ดังนั้นถ้าคุณอยากปกป้องเว็บไซต์จากผู้โจมตีที่ใช้ชั้นฟรีของเรา ก็จ่ายเงินให้เรา”
อย่างน้อยต่อให้ไม่มีการสมรู้ร่วมคิดเชิงรุกหรือการแบ่งรายได้ ก็คงไม่ชัดเจนว่า บริการป้องกัน DDoS ยืนอยู่ข้างไหน
ฉันเห็นด้วยกับข้อวิจารณ์ แต่ Cloudflare ไม่ได้เป็นผู้คิดค้น DDoS
ต่อให้พรุ่งนี้ Cloudflare หายไปด้วยเวทมนตร์ AI crawler ก็จะไม่หยุด
แล้วทางเลือกคืออะไร? คงไม่ใช่โลกที่ถ้าจะท่องอินเทอร์เน็ตต้องอัปโหลดบัตรประชาชนที่รัฐออกให้หรอกนะ?
แต่ถ้าอยากรักษาความไม่เปิดเผยตัวตนสัมพัทธ์และความเป็นสากลของอินเทอร์เน็ตไว้ จะทำแบบนั้นได้อย่างไร?
ผู้คนอาจรวมตัวกันเป็นสหกรณ์เพื่อดูแลการป้องกันได้ แต่การดำเนินการในฐานะหน่วยงานระดับโลกนั้นยากมาก
การป้องกัน DDoS โดยมากอาศัย ความจุส่วนเกินมหาศาล ที่พอจะรับมือได้พร้อมการกรอง จึงต้องลงทุนสูงมาก
Cloudflare โดยทั่วไปเลือกที่จะไม่เซ็นเซอร์เนื้อหาที่คาดว่าไม่ผิดกฎหมายซึ่งวิ่งผ่านระบบของตน แม้จะไม่ใช่ 100% ดังเช่นกรณี The Daily Stormer[1] และไม่เลือกสวมบทเป็นผู้ตัดสินความชอบด้วยกฎหมายเอง
[1]: https://blog.cloudflare.com/why-we-terminated-daily-stormer/
เห็นด้วยอย่างยิ่ง
Cloudflare คุ้มครองพวกมิจฉาชีพในระดับมหาศาลและไม่มีใครใส่ใจ
ร้านค้าออนไลน์ปลอมที่ฉันรายงานไปยัง Cloudflare รวมถึงหน้าฟิชชิงที่อยู่หลัง Cloudflare ไม่ถูกถอดออกเลยสักอัน
ไม่แม้แต่หนึ่งอัน
ถ้าเป็นบริษัทที่หาเงินหลายพันล้านจากการปกป้องผู้คน ก็ต้องจริงจังกับเรื่องแบบนี้
ตัวอย่างเช่น ศาลคดีมูลค่าน้อย ที่บอกว่า “ฉันเสียหาย 20 ดอลลาร์ และต้องการข้อมูลการชำระเงินของลูกค้าที่ให้กับ Cloudflare รวมถึงธนาคารผู้ออกบัตรและเลขที่บัญชี เพื่อระบุตัวผู้ที่ต้องเรียกค่าเสียหาย” ก็ดูเป็นแนวทางที่น่าสนใจทีเดียว
ยังไม่เคยได้ยินว่าใครทำสำเร็จ แต่ถ้ามีใครลองก็อยากเห็นผล
ฉันว่าตอนนี้ดีกว่ามาก
ฉันคิดมาตลอดว่าเหตุที่ Ubuntu ล่ม เป็นเพราะพวกเซิร์ฟเวอร์ ubuntu ทำให้แพตช์ copy.fail ใช้งานไม่ได้ เพื่อให้กลุ่มแฮ็กนั้นใช้ประโยชน์จากเป้าหมายให้ได้มากที่สุดในช่วงเวลานั้น
modprobe(8)ไม่กี่อย่าง# echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf# rmmod algif_aeadอาจมีโปรเซสบางตัวใช้ความสามารถนี้อยู่ (
lsof | grep AF_ALG) แต่เท่าที่ฉันเข้าใจมันไม่ได้ถูกใช้แพร่หลาย ดังนั้นปิดใช้งานบนระบบส่วนใหญ่ก็คงไม่เป็นปัญหาเซิร์ฟเวอร์ apex ทั้งหมดน่าจะถูกตั้งค่าแบบ ความพร้อมใช้งานสูง เพื่อคงการกระจายโหลดไว้ ดังนั้นผู้ใช้ทั่วไปคงไม่รู้สึกอะไรตอนแพตช์ copy.fail
ผู้ใช้ของเราก็ไม่รู้สึกถึงการอัปเดตเลยตอนที่เราแจกจ่ายแพตช์
นั่นไม่ใช่การข่มขู่ แต่ใกล้เคียงกับ การรีดไถ มากกว่า
และ CF ไม่ได้ทำทั้งสองอย่าง
ถ้าใช้ตรรกะแบบนี้ ผู้ผลิตคีย์บอร์ดก็อาจต้องรับผิดชอบต่อการกระทำผิดกฎหมายที่ถูกพิมพ์ด้วยสินค้าของตัวเองได้เหมือนกัน
การให้บริการต่อไปแก่องค์กรที่ถูกใช้เพื่อสนับสนุนกิจกรรมอาชญากรรมเป็นเรื่องที่ต่างกันมาก และการยกเลิกลูกค้าเพราะกิจกรรมผิดกฎหมายก็ไม่ใช่เรื่องน่าถกเถียงด้วยซ้ำ
ถ้าคุณได้รับระเบิดจากพัสดุของ UPS ก็ไม่ใช่ความผิดของ UPS
แต่ถ้ามีคนแจ้ง UPS ว่ามีใครกำลังใช้ UPS ส่งระเบิดให้คนอื่นอยู่ แล้ว UPS ไม่ทำอะไรเลย แถมยังดูเหมือนปกป้องผู้ส่งระเบิด แบบนั้นก็ต้องมีความรับผิดชอบอยู่บ้างไม่ใช่หรือ?
ในสถานการณ์นี้ “ผู้ผลิตคีย์บอร์ด” จะใกล้เคียงกับ ผู้ผลิตเราเตอร์ ที่ Cloudflare ซื้ออุปกรณ์จากพวกเขามากกว่า ไม่ใช่ตัว Cloudflare เอง
ในอุปมานี้ Cloudflare ใกล้เคียงกับผู้รวบรวมหนังสือพิมพ์ที่บรรทุกทั้งสิ่งสกปรกและบทวิเคราะห์ปกติไปพร้อมกัน
ตามปกติคุณก็อาจแค่ไม่อ่านหนังสือพิมพ์สกปรก และปล่อยให้คนที่อยากอ่านตัดสินใจเอง
แต่ในกรณีของ Cloudflare หนังสือพิมพ์กระแสหลักเกือบทั้งหมดเลือกเผยแพร่เนื้อหาผ่าน Cloudflare ดังนั้นเมื่อมีสิ่งมีปัญหาถูกเผยแพร่ไปพร้อมกัน คุณต้องไปเอาเรื่องกับ Cloudflare แทนที่จะเป็นผู้เผยแพร่ต้นทาง
และ Cloudflare ก็อาจส่งต่อข้อมูลของคุณไปให้คนที่ไม่น่าอภิรมย์อย่างยิ่งโดยที่คุณไม่อาจรู้ล่วงหน้า
แล้วเราควรขีดเส้นตรงไหน?