การโจมตีแบบ Self-DDOS ของ Twitter
(sfba.social/@sysop408)- ในช่วงที่ฟีดหน้า Home ของ Twitter ล่มเกือบตลอดช่วงเช้าวันนั้น พบว่าเว็บไคลเอนต์ยังคงส่งคำขอเนื้อหาซ้ำอย่างต่อเนื่อง จนดูเหมือนว่า กำลังก่อ DDOS ใส่ตัวเอง
- แม้หน้าจอจะโหลดไม่ขึ้น การลองใหม่ก็ไม่หยุด และในวิดีโอแรกมีข้อผิดพลาด rate limited กับแถบเลื่อนที่สั่นไปมา
- วิดีโอที่สองแสดงให้เห็นว่า ระหว่างพยายามดึงเนื้อหาที่ไม่มาถึง Twitter ส่งคำขอไปหาตัวเอง ประมาณ 10 คำขอต่อวินาที
- สาเหตุที่ถูกชี้อาจมาจาก ข้อจำกัดการอ่านสำหรับผู้ใช้ที่ไม่ได้ล็อกอิน ซึ่งเพิ่งถูกนำมาใช้ และอาจสร้างเงื่อนไขที่ไม่คาดคิด
- ในวิดีโอต่อมา คอนโซลเครือข่ายของ Firefox ก็แสดงให้เห็นว่าคำขอยังคงไหลเข้ามาอย่างต่อเนื่อง และถูกตีความว่าเป็นสถานการณ์ Self-DDOS ที่เบราว์เซอร์ของผู้ใช้ส่งคำขอซ้ำไปยัง Twitter
คำขอซ้ำที่พบในเว็บไคลเอนต์ของ Twitter
- ฟีดหน้า Home ของ Twitter ล่มเกือบตลอดช่วงเช้าวันนั้น และแม้จะอยู่ในสภาพที่ไม่มีอะไรโหลดขึ้นมา เว็บไซต์ก็ยังไม่หยุดลองส่งคำขอใหม่
- วิดีโอแรกแสดงข้อความผิดพลาดว่าผู้ใช้อยู่ในสถานะ rate limited และภาพแถบเลื่อนด้านขวาที่สั่นไปมา
- วิดีโอที่สองแสดงเหตุผลที่แถบเลื่อนสั่น โดยเห็นว่า Twitter พยายามดึงเนื้อหาและส่งคำขอไปหาตัวเอง ประมาณ 10 คำขอต่อวินาที
- การเปลี่ยนแปลงที่กันไม่ให้ผู้ใช้ที่ไม่ได้ล็อกอินอ่าน Twitter ถูกชี้ว่าเป็นฉากหลังที่ทำให้เนื้อหาไม่มาถึง
การตรวจสอบเพิ่มเติมและไฟล์แนบ
- โพสต์ติดตามผลแสดงเพิ่มเติมผ่านหน้าจอคอนโซลเครือข่ายของ Firefox ว่าคำขอเครือข่ายยังคงเกิดขึ้นอย่างต่อเนื่อง
- มีการตีความว่าโค้ดที่ปล่อยขึ้นใช้งานก่อให้เกิด ภาวะแข่งขัน (race condition) ส่งผลให้ผู้ใช้กลายเป็นผู้ส่งคำขอในลักษณะ DDOS ไปยัง Twitter
- ผู้โพสต์ระบุว่าในตอนแรกได้ปิดการเชื่อมต่อไปแล้ว แต่หลังจากนั้น Twitter ยังทำให้เกิดสถานการณ์ที่ชักนำให้ส่งคำขอต่อเนื่องอยู่พักหนึ่ง
- ไฟล์แนบ:
2 ความคิดเห็น
Twitter โจมตีตัวเองด้วย DDOS
ความคิดเห็นใน Hacker News
จากประสบการณ์ส่วนตัวที่เจ็บปวดมาก แทบไม่มีอะไรบั่นทอนคนได้เท่ากับการถูกบังคับให้ทำสิ่งที่รู้อยู่เต็มอกว่าเป็นความคิดที่เลวร้ายสุดๆ
โดยเฉพาะเมื่อพยายามบอกคนที่กดดันให้ทำสวนทางกับวิจารณญาณที่ดีที่สุดของเราแล้วไม่สำเร็จ และยิ่งแย่เข้าไปอีกเมื่อภายหลังคนคนนั้นกลับโวยวายว่าไม่เคยขอแบบนั้น ทั้งที่มีหลักฐานเป็นลายลักษณ์อักษรอยู่แล้ว
ไม่รู้ว่าคนที่ทำงานอยู่ใน Twitter ตอนนี้เคยเตือนหรือไม่ว่ามาตรการล่าสุดอาจก่อผลข้างเคียงใหญ่แบบนี้ได้ แต่พอดูวิธีบริหารของผู้นำแล้วก็ไม่ได้น่าแปลกใจเลย
ฉันเกลียดมากกับสิ่งที่ Twitter กลายเป็นไปในช่วงหลายเดือนที่ผ่านมา และต่อให้ก่อนถูกเทกโอเวอร์ฉันก็ไม่ได้ชอบมันนัก เพราะฟอร์แมตสั้นๆ ทำให้รายละเอียดและนัยหายไป อีกทั้งบทความก็มักอ้างอิงแค่ทวีตไม่กี่อันที่ฝังง่าย แต่ก็ยังสงสารคนที่ต้องทำงานภายใต้ผู้บริหารแบบนั้นจริงๆ
ถ้าให้เดา Elon คงพูดว่า “เว็บช้าเกินไป” แล้ววิศวกรก็เห็นว่าคำขอ home feed ช้า แต่ไม่เข้าใจโครงสร้าง ไม่มีเครื่องมือ profiling และถูกกดดันให้แก้ภายในเส้นตายที่ไม่สมจริง
เพราะงั้นสิ่งเดียวที่แทบจะพอทำได้ก็คงเป็นการยิงคำขอแบบขนานหลายชุด แล้วหวังว่าสักอันจะตอบเร็ว
พอเคยทำงานในวงการเกม ก็เลยเข้าใจว่าทำไมเกมที่ใช้ทั้งเงินและเวลามหาศาลถึงยังออกมาแบบที่แม้แต่ฟังก์ชันพื้นฐานก็ยังพัง
แรงกดดันด้านตารางเวลาแบบสุดโต่งนี้กลับสร้างบึงโคลนขนาดมหึมาที่แก้หนึ่งอย่างแล้วพังสิบอย่าง สุดท้ายความคืบหน้าก็หยุดชะงัก
นี่คือการจัดการข้อผิดพลาดพื้นฐานที่ควรมีมาตั้งแต่หลายปีก่อนแล้ว
จะเป็น 403 หรืออะไรก็ตาม การตอบกลับที่บล็อกทวีตไม่ควรทำให้เกิดการ retry แบบไม่สิ้นสุดในช่วงเวลาสั้นๆ เด็ดขาด
ฉันสร้างเครื่องมือไว้จัดการ ticket ช่องโหว่ของทีม แต่ use case แรกกลับเป็นการลบ ticket ช่องโหว่ทั้งหมดทั้งที่ฉันคัดค้าน
คนที่ลงมือทำสนใจทำให้เอกสารดูดีบนกระดาษมากกว่าปรับปรุงความปลอดภัยจริงๆ
คือรู้มานานแล้ว เสนอซ้ำแล้วซ้ำอีก แต่ไม่เคยได้รับอนุญาตให้ลองด้วยซ้ำ กลับถูกกันออกไปและถูกมองเป็น “คนนั้น”
ฉันเคยเจอกับแนวทางด้านเทคนิคและธุรกิจที่ “วิธีเดิม” ยังพอประคองไปได้ somehow แต่ค่อยๆ ฆ่าบริษัทลงช้าๆ
แต่ถ้าหัวหน้าระดับบนรับผิดชอบอย่างชัดเจนต่อสิ่งที่ตัดสินใจว่ามีความเสี่ยงแต่จำเป็น อย่างน้อยพอเกิดปัญหาก็ยังมีพื้นที่ให้รับมือได้ดีกว่า และนักพัฒนาก็ไม่ต้องมาแบกรับคำเหน็บแนมย้อนหลังมากเท่าเดิม
แน่นอนว่าเรื่องแบบนี้ด่ามันง่ายกว่าเยอะ
ต้องดูด้วยว่าครั้งนี้เกิดขึ้นในช่วงวันหยุดยาวสุดสัปดาห์
Elon ดัน release ใหญ่เข้าไป ทำให้วิศวกรต้องเข้าออฟฟิศและวน patch หลายรอบในช่วง 12 ชั่วโมงที่ผ่านมา
เป็นห่วงโปรแกรมเมอร์จริงๆ
ที่น่าตกใจกว่านั้นคือทุกวันนี้งานวิศวกรรมของ Twitter ดูเป็นการแก้ขัดเฉพาะหน้าขนาดไหน
พวกเขาไม่ทุ่มแรงไปกับการขุดลึกลงใน codebase แต่เลือกแต่การแก้ที่ง่ายและสั้นที่สุด เลยเกิดปัญหา
ณ จุดนี้ทั้งเงื่อนไขการจ้างงานและความคาดหวังจากหัวหน้าก็ชัดเจนมากแล้ว
ไม่ว่าพวกเขาจะยังอยู่ต่อด้วยเหตุผลอะไร ก็ยากจะเห็นใจคนที่ยังยืนหยัดอยู่ต่อไปเรื่อยๆ
เป็นไปได้น้อยมากที่บั๊กนี้จะเป็นสาเหตุ
ตัวตัวจำกัดอัตราฝั่งเซิร์ฟเวอร์มีต้นทุนต่ำ และบั๊กฝั่ง frontend จะถูก trigger เฉพาะตอนที่การจำกัดอัตราทำงานเท่านั้น
ในระบบที่ฉันดูแลเองก็เคยเห็นบั๊กคล้ายกัน เพราะไลบรารีเครือข่ายชอบ retry request แบบค่าปริยายโดยแทบไม่มีการจำกัดที่เหมาะสม
แต่ retry พวกนั้นไม่เคยทำให้ตัวจำกัดอัตราทำงานหนักเกินไป
ถ้าไปยิง API ที่ทำงานแพงจริงๆ ก่อนค่อยคืน error ก็จะน่ารำคาญขึ้นอีกหน่อย แต่นั่นก็เป็นเหตุผลว่าทำไม public endpoint ทั้งหมดถึงต้องมี rate limit
webapp น่าจะเป็นสัดส่วนทราฟฟิกที่เล็กที่สุดของ Twitter และแอป native ก็น่าจะไม่มีปัญหานี้
มันอาจเป็นไปได้ว่าการบล็อกการเข้าถึงแบบไม่ล็อกอินก่อให้เกิดDDoS แล้วทำให้ตัวชี้วัดบางอย่างพุ่งขึ้นมหาศาล จากนั้น Elon ก็สรุปว่าเป็นการ scraping ที่เพิ่มขึ้น ก่อนจะลงโทษ scraper ด้วยการจำกัดวันละ 600 ทวีต
ดูเหมือนว่า quota ของฉันจะรีเซ็ตแล้วหรือไม่ก็นโยบายเปลี่ยนไป ตอนนี้เข้าเว็บได้อีกครั้ง
ผมเห็นด้วยว่าบั๊กนี้ไม่น่าใช่สาเหตุรากของทั้งหมด
แต่ผมก็ไม่เชื่อเรื่องที่ Musk ใช้ขายเป็นเหตุผลในการปิดเว็บแทบทั้งไซต์เหมือนกัน
ทั้งสองอย่างอาจจริงพร้อมกันก็ได้ และมันทำให้คนยังต้องคิดหาสาเหตุที่เป็นไปได้อื่นๆ ต่อไป ซึ่งเป็นการเสียเวลาโดยสมบูรณ์ แต่ก็เหมือนเหยื่อล่อทางจิตประหลาดๆ
หนังสือ "Nothing is true and everything is possible" พูดถึงวิธีที่ Putin ใช้ข้อมูลเท็จเพื่อควบคุมมวลชนและกำจัดการเมืองแบบประชาธิปไตย ซึ่งให้ความรู้สึกว่าเอามาใช้กับกรณีนี้ได้เหมือนกัน
แฟนๆ ของ Musk ก็คงท่องซ้ำทุกอย่างที่เขาอยากให้พูด แต่คนส่วนใหญ่ก็น่าจะรู้ว่านี่เป็นแค่เรื่องเหลวไหลเพื่อผลประโยชน์ของตัวเอง
และคนที่พยายามหาต้นตอของปัญหาก็จะไหลไปติดกับเรื่องเล่าที่ฟังดูเข้าท่าแบบบั๊กนี้ได้ง่าย ทั้งที่ไม่มีข้อมูลรองรับเลยสักนิด
ถ้าอยากเห็นเส้นทางความเป็นไปได้ของอนาคตสหรัฐฯ ผมแนะนำหนังสือเล่มนี้อย่างมาก
https://en.wikipedia.org/wiki/Nothing_Is_True_and_Everything...
ผมเคยเห็นและพยายามบรรเทากรณีถดถอยที่ retry แบบนี้ถาโถม backend จนเซิร์ฟเวอร์ตามไม่ทันแม้แต่จะปฏิเสธคำขอมาแล้ว
สถานการณ์แย่ลงมากเพราะมีการ retry จากหลายชั้นของ upstream caller จนคำขอบางส่วนหมดเวลาไปใน TCP buffer/queue แทบจะก่อนถึงขั้นถูกแอปพลิเคชันประมวลผลด้วยซ้ำ
ไม่รู้ว่า backend หน้าแรกของ Twitter มีขนาดใกล้เคียงแบบนั้นหรือเปล่า
เป็นสถานการณ์ที่น่าสนใจ
จากสกรีนช็อตดูเหมือนว่ามี
GET /TweetDetailจำนวนมหาศาลถูกสร้างขึ้น และอย่างที่เห็น 429 ก็น่าจะไปทริกเกอร์การจำกัดอัตราไว้บางอย่างถ้านี่เป็นผลจากการตัดสินใจล่าสุดที่บังคับให้ทุกการเรียก API ต้องยืนยันตัวตน ผู้ร้ายตัวจริงก็อาจเป็น API gateway หรือองค์ประกอบลักษณะคล้ายกันที่อยู่ชั้นล่างลงไป
อีกอย่าง พฤติกรรมนี้ดูเหมือนจะไม่หยุด ซึ่งไม่ใช่พฤติกรรมที่คาดว่าจะเห็นจากการ retry แบบ exponential backoff
ไม่ได้จะอ้างว่าตัวเองเป็นวิศวกรที่เก่งกว่าคนที่ทำงานอยู่ที่ Twitter แต่ต่อให้ไม่เอาปัจจัยเรื่อง Musk มาคิด การได้เห็นอาการแบบนี้ในระบบจริงก็ยังน่าสนใจอยู่ดี
ผมเห็นมาหลายครั้งเกินไปแล้วว่าคนตัดสินใจให้ความสำคัญกับการตอบสนองคำขอของผู้ใช้ด้วย latency ต่ำ จนเลือกใช้ random backoff แบบคงที่แทน exponential backoff
เคยเห็นทั้งในการประชุมออกแบบและในเอกสารหลายครั้ง ที่มีการตัดสินใจอย่างชัดเจนว่าจะไม่ใช้ exponential backoff ทั้งที่เข้าใจ trade-off ระหว่าง overload กับการกู้คืนระบบดีอยู่แล้ว
การเปลี่ยนแปลงฝั่ง backend คือ บังคับยืนยันตัวตน + จำกัดอัตรา อาจถูก deploy โดยที่ยังทดสอบ frontend กับ backend ร่วมกันไม่เพียงพอ
ฟังดูเป็นผู้ต้องสงสัยที่เป็นไปได้ทีเดียว
อาจเป็นไปได้ว่าอินสแตนซ์ของ Twitter กำลังถูกบังคับปิดอยู่
Platformer รายงานเมื่อวันที่ 10 มิถุนายนว่า “Twitter ปฏิเสธที่จะจ่ายค่าบริการ Google cloud ก่อนวันต่อสัญญา 30 มิถุนายน”
และยังบอกด้วยว่า “สัญญา Google Cloud ของ Twitter ดำเนินมาตั้งแต่ปี 2018”
https://www.engadget.com/twitter-has-supposedly-started-payi...
อ้อ เหมือนจะอธิบายความโกลาหลทั้งหมดนี้ได้เลย
น่าจะกำลัง พยายามย้ายออกจาก GCP อยู่ แต่คงไม่ใช่กรณีที่จู่ๆ ก็เสียการเข้าถึง GCP เพราะปฏิเสธการจ่ายเงิน
อันนี้เป็นบทความเมื่อสัปดาห์ก่อน
ทั้งหมดโฮสต์เอง
Gcloud ใช้สนับสนุนแค่งาน batch และ data analytics เท่านั้น
เป็นทฤษฎีที่น่าสนใจ แต่ DDoS เกิดขึ้นก่อนการตัดสินใจปิดการเข้าถึงแบบไม่ระบุตัวตน
ที่จริงแล้ว การตัดสินใจนั้นเกิดขึ้นเพื่อบรรเทา DDoS ที่กำลังดำเนินอยู่[0][1]
เพราะฉะนั้น logic การ retry ของเว็บ frontend ที่น่าสงสัยอาจทำให้สถานการณ์แย่ลงได้ แต่ไม่ใช่สาเหตุราก
[0] https://twitter.com/elonmusk/status/1674865731136020505
“นี่เป็นมาตรการฉุกเฉินชั่วคราว การปล้นข้อมูลรุนแรงมากจนทำให้คุณภาพการให้บริการแก่ผู้ใช้ทั่วไปลดลง!”
[1] https://twitter.com/elonmusk/status/1674942336583757825
“จะยกเลิกในเร็วๆ นี้ ตามที่โพสต์ก่อนหน้านี้บอกไว้ จำเป็นต้องมีมาตรการที่เด็ดขาดและทันที เพราะมีการ scraping ข้อมูลในระดับรุนแรงมาก”
“แทบทุกบริษัทที่ทำ AI ไม่ว่าจะเป็นสตาร์ทอัปหรือบางส่วนของบริษัทที่ใหญ่ที่สุดในโลก ต่างกำลัง scrape ข้อมูลกันในปริมาณมหาศาล”
“การต้องรีบเพิ่มเซิร์ฟเวอร์จำนวนมากเพียงเพื่อช่วยการประเมินมูลค่าที่ไร้สาระของ AI startup บางแห่ง เป็นเรื่องที่น่าหงุดหงิดมาก”
มันแทบแน่นอนอยู่แล้วว่าน่าจะมีคลังทวีตขนาดมหาศาลของทุกอย่างก่อนวันที่กำหนดที่ลอยอยู่ที่ไหนสักแห่งให้พวกสตาร์ทอัปเหล่านั้นใช้
มีใครรู้ไหมว่าก่อนการเปลี่ยนเป็นล็อกอินเท่านั้น มีคำขอแบบนี้อยู่แล้วหรือเปล่า?
ถ้างาน scraping ขนาดมหึมานั่นจริงๆ แล้วเป็น บั๊ก JavaScript ของพวกเขาเองก็คงตลกมาก
ถ้าการไหลเข้าของ “ทราฟฟิก scraping” ส่วนใหญ่เป็นความผิดของ Twitter เอง ผมก็จะไม่แปลกใจเลย
เป็นผลลัพธ์ที่โง่แต่ก็เดาได้ไม่ยาก
น่าจะมีคำขอหลายสิบรายการถูกยิงออกไปภายในไม่กี่วินาทีก่อนจะชน rate limit
บั๊กเล็กๆ แบบนี้จำนวนมากรวมกันก็อาจดูเหมือน DDoS หรือการ scraping ได้
มันอาจไม่ใช่บั๊กก็ได้
Elon บอกว่าจำกัดจำนวนทวีตที่เห็นต่อวันไว้ที่ 600 ทวีต ซึ่งเป็นข้อจำกัดที่บ้ามาก
คนส่วนใหญ่แค่เลื่อนดู 5 นาทีก็น่าจะเกินแล้ว
ตอนที่ Tweetbot แสดงว่าฟีดผมมีเกิน 500 รายการ จำได้ว่าแค่การนั่งรถราง 20 นาทีไม่กี่เที่ยวก็มีเรื่องไร้สาระให้อ่านมากพอแล้ว
ผมไม่สงสัยเลยว่า Twitter เห็นทราฟฟิกเพิ่มขึ้นมหาศาลในช่วงหลัง แต่ก็ค่อนข้างมั่นใจว่าส่วนใหญ่เป็น ปัญหาที่ Twitter สร้างขึ้นเอง
Elon แค่ปล่อยไว้เฉย ๆ ก็น่าจะพอแล้ว แต่เอ้อ จริงสิ มีเงิน 44 พันล้านดอลลาร์ นี่นา
Parag Agrawal กับทีมของเขารู้แน่ชัดว่าพวกเขากำลังทำอะไรอยู่
ตรงกับคำพูดที่ว่าคนโง่กับเงินมักแยกจากกันในไม่ช้า
หลังจาก Elon ถูกศาล Delaware บังคับให้ซื้อ Twitter เขาก็ไปหาพวกเผด็จการที่มีเงิน แล้วรับเงิน 44 พันล้านดอลลาร์ จากพวกเขาเพื่อมาเผา Twitter ให้พังแทนพวกนั้น
ถ้าไม่มี Twitter ก็จะไม่มี Arab Spring, ไม่มีอัปเดตภัยพิบัติแบบเรียลไทม์ และไม่จำเป็นต้องตัดอินเทอร์เน็ตเพื่อขัดขวางไม่ให้เสียงคัดค้านแพร่กระจาย
ไม่ได้มีความหมายมากนัก แต่ การจำกัดความเร็ว กำลังถูกผ่อนกลับอีกครั้ง
6k/600/300 → 8k/800/400(ราวเที่ยง) → 10k/1k/500(ราวบ่าย 3)
อ้างอิงจาก https://twitter.com/elonmusk/status/1675214274627530754 และรีพลายของเขาเอง
ขึ้นว่า “Something went wrong”
ภายใต้กฎใหม่ที่ให้เฉพาะคนล็อกอินเท่านั้น ถึงเว็บยังไม่ล่มก็คงอ่านไม่ได้อยู่ดี
ตอนนี้ลิงก์ Twitter กลายเป็น ลิงก์ปนเปื้อน ไปแล้ว จนแทบไม่มีประโยชน์
เป็นละครสัตว์เต็มรูปแบบจริง ๆ