3 คะแนน โดย GN⁺ 2024-04-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในช่วงที่ยังไม่มีรอบเวร on-call อย่างเป็นทางการ แมวปลุกคนที่กำลังหลับตอนตี 3 ทำให้ตรวจพบ AWS CloudWatch alert และปัญหาเว็บไซต์ล่มได้ทันที
  • หลังจากมีการแจ้งเตือน unhealthy targets ของโหลดบาลานเซอร์ เว็บไซต์ก็เปิดไม่ได้ และพบคำขอจำนวนมากจาก IP จำนวนมากที่เชื่อมโยงกับหลายประเทศ
  • เนื่องจากผลิตภัณฑ์ให้บริการเฉพาะผู้ใช้ในสหรัฐฯ ทราฟฟิกจากต่างประเทศจึงผิดปกติ และจากสถานการณ์น่าจะเป็น การโจมตี DDoS
  • การบล็อก IP ทีละรายการบนเซิร์ฟเวอร์อาจไม่มีประสิทธิภาพ แต่ด้วยกฎบล็อกตามประเทศของ AWS WAF ที่ตั้งค่าไว้แล้ว จึงบล็อกคำขอได้หลายแสนรายการในเวลาประมาณ 1 ชั่วโมง
  • ในช่วงเริ่มการโจมตี กล่องเมลฝ่ายสนับสนุนลูกค้าได้รับอีเมลข่มขู่ว่าได้หยุดเว็บไซต์ด้วยช่องโหว่ของ Apache และเรียกเงิน 5,000 ดอลลาร์เป็น Bitcoin ซึ่งบริษัทไม่ได้ตอบกลับ

เหตุขัดข้องที่ปรากฏตอนตี 3

  • ตอนนั้นสตาร์ทอัพยังไม่มี รอบเวร on-call อย่างเป็นทางการ และดำเนินงานด้วยวิธีที่ทีมช่วยกันเฝ้าดูการแจ้งเตือนฉุกเฉิน
  • ราวตี 3 แมวเลียทำความสะอาดเส้นผมจนทำให้ตื่น พอหยิบโทรศัพท์มาดูก็พบว่ามีการแจ้งเตือนจาก AWS CloudWatch เมื่อไม่กี่นาทีก่อน
  • สาเหตุของการแจ้งเตือนคือ unhealthy targets ของโหลดบาลานเซอร์ และเว็บไซต์ก็โหลดไม่ขึ้นจริง ๆ
  • บนแดชบอร์ดมอนิเตอร์ริ่งเห็น คำขอจำนวนมหาศาล ที่เข้ามาจาก IP address จำนวนมากซึ่งเชื่อมโยงกับหลายประเทศ
  • เนื่องจากผลิตภัณฑ์ให้บริการเฉพาะผู้ใช้ในสหรัฐฯ ทราฟฟิกจากต่างประเทศจึงต่างจากปกติ และจากสถานการณ์จึงประเมินว่าเป็น การโจมตี DDoS

รับมือคำขอถล่มด้วย AWS WAF

  • วิธีรับมือแรกที่นึกถึงคือการบล็อก IP address ในระดับเซิร์ฟเวอร์ แต่หากผู้โจมตีใช้ IP ต้นทางได้มากขึ้น ก็อาจยุ่งยากและมีประสิทธิภาพจำกัด
  • จึงใช้ AWS Web Application Firewall ที่ตั้งค่าไว้แล้ว เพิ่ม กฎบล็อกคำขอจากประเทศอื่น เพื่อรับมือเหตุขัดข้องแบบทันที
  • หลังจากกฎมีผล คำขอหลายแสนรายการ ถูกบล็อกภายในเวลาประมาณ 1 ชั่วโมง และเว็บไซต์ก็เริ่มกลับมาทำงาน
  • เมื่อคำขอที่ถาโถมเข้ามาหยุดลง เหตุขัดข้องเฉพาะหน้าก็ได้รับการแก้ไข

อีเมลข่มขู่ที่มาถึงทันทีหลังการโจมตี

  • เช้าวันนั้น ได้ตรวจสอบอีเมลที่เข้ามาในกล่องเมลฝ่ายสนับสนุนลูกค้าในช่วงเริ่มการโจมตี
    • ผู้ส่งอ้างว่าพบช่องโหว่ของเว็บไซต์และทำให้ Apache แครช แต่บริษัทไม่ได้ใช้ Apache
    • อ้างว่าได้หยุดทราฟฟิกทั้งหมดของเว็บไซต์และสามารถคงไว้ได้หลายเดือน พร้อมเรียกร้องให้ส่งเงิน 5,000 ดอลลาร์เป็น Bitcoin แล้วจะให้ “solution file”
    • บริษัทไม่ได้ตอบกลับ
  • เนื่องจากตอนกลางคืนโทรศัพท์อยู่ใน โหมดห้ามรบกวน คำอธิบายที่ว่าการสั่นหรือเสียงแจ้งเตือนจาก AWS ทำให้แมวตื่นก่อนจึงไม่ถูกต้อง
  • เจ้าตัวคิดว่าแมวน่าจะ somehow รับรู้ได้ว่ามีเรื่องที่รอถึงเช้าไม่ได้ และมองว่าเป็นวิธีปลุกที่น่าหงุดหงิดน้อยกว่าเสียงปลุกของ PagerDuty มาก

1 ความคิดเห็น

 
GN⁺ 2024-04-15
ความเห็นจาก Hacker News
  • อย่างที่เป็นกันเสมอ ภัยคุกคามจาก คนวงใน มักถูกมองข้ามได้ง่าย อีเมลข่มขู่ที่ไวยากรณ์น่าสงสัย? เรียกค่าไถ่เป็น Bitcoin? เคยคิดไหมว่าจริง ๆ แล้วผู้อยู่เบื้องหลังการโจมตีอาจเป็นแมว?

    • ที่แท้สายโทรมาจากในบ้านนี่เอง!
    • เหมือนเอา “Bite” ไปใส่ใน Bitcoin เลย
    • ใช่ แมวขึ้นชื่อเรื่องใช้ไวยากรณ์ไม่เป็นอยู่แล้ว
  • ที่ Kansas แทบไม่มีแผ่นดินไหวเลย แต่แผ่นดินไหวครั้งแรกและครั้งเดียวที่ฉันเคยรู้สึกยังจำได้จนถึงทุกวันนี้
    ฉันกำลังหลับลึกอยู่ แล้วแมวพันธุ์ Siamese ก็มาตบหน้าฉันด้วยเท้าจนตื่น จากนั้นมันไปนั่งที่ปลายเตียงแล้วคำรามอย่างก้าวร้าวผิดปกติ
    ไม่ถึง 30 วินาทีหลังจากนั้นก็เริ่มสั่น ฉันไม่รู้ว่ามันรู้ได้ยังไง แต่น่าทึ่งมาก มันจากไปในปี 2020 แล้ว และฉันก็ยังคิดถึงมันอยู่

    • เป็นที่รู้กันว่าแมวและสุนัขสามารถ ตรวจจับแผ่นดินไหว ได้ก่อนที่มนุษย์จะรู้สึก
      ตอนแผ่นดินไหวล่าสุดที่ NYC ก็มีคลิปสุนัขหอนก่อนที่คนจะรู้สึกถึงแรงสั่นสะเทือนด้วย ฉันว่าเป็นเรื่องที่พบได้ค่อนข้างบ่อย
    • เสียใจด้วยนะ แต่ก็เป็นความทรงจำดี ๆ เกี่ยวกับแมวตัวนั้น
      ตอนฉันเจอแผ่นดินไหวขนาด 7.4 ที่ Taipei เมื่อไม่กี่สัปดาห์ก่อน สิ่งเดียวที่ฉันคิดคือฉันต้องกลับไปหาสุนัขตามที่สัญญาไว้ ก่อนฉันออกจากบ้านมันดูไม่สบายใจ แต่ไม่รู้ว่ามันจับได้ว่าฉันกำลังจะออกไป หรือจับได้ถึงแผ่นดินไหวที่ฉันกำลังจะเจอ
    • อธิบายได้ว่ามันรู้ได้ยังไง
      ในหินมีคลื่นอยู่สองชนิดคือ คลื่น P และคลื่น S คลื่น P เป็นคลื่นความดันจึงเดินทางได้เร็วกว่า ส่วนคลื่น S สั่นซ้ายขวาและช้ากว่าเล็กน้อย มีโอกาสสูงที่แมวจะตื่นเพราะได้ยินเสียงฟู่ของคลื่น P ซึ่งมาถึงก่อนแผ่นดินไหวที่คนรู้สึกได้เล็กน้อย
      เรื่องที่ว่ามีคลื่นสองชนิดและคลื่น P มาถึงก่อน ดูได้ที่ https://manoa.hawaii.edu/exploringourfluidearth/physical/oce...
  • มือถืออาจตั้งเงียบอยู่ แต่หน้าจออาจยังกะพริบไม่หยุด ของฉันก็ทำแบบนั้นในโหมดนั้นเหมือนกัน
    ที่งานแรกของฉันมีคนหนึ่งที่คอยรู้ล่วงหน้าจาก แดชบอร์ดมอนิเตอริง ว่าระบบกำลังจะล่ม ทั้งที่เจ้าตัวเองก็อธิบายไม่ได้หรือไม่เข้าใจด้วยซ้ำว่ากำลังดูอะไรอยู่ และคนอื่นก็ทำตามไม่ได้ แต่ถ้าเขาบอกว่ามีอะไรแปลก ๆ ส่วนใหญ่ไม่นานก็จะมีแจ้งเตือนมา

    • ถ้าให้คนดูข้อมูลที่ไหลผ่านนานพอ เขาจะ ปรับเข้ากับแพตเทิร์น เอง มนุษย์ถูกสร้างมาให้มองหารูปแบบ และไม่จำเป็นต้องอธิบายได้อย่างมีสติเสมอไป บางจุดสัญญาณมันก็แค่รู้สึกว่า “ไม่ใช่”
    • คนแบบนั้นเรียกว่า คานารี แล้วก็เอาไปไว้ลึก ๆ ในเหมือง
    • ดูเหมือนว่าสัญญาณบางอย่างจะข้ามส่วนของสมองที่จัดการกับข้อเท็จจริงชัดเจนไป
      ฉันเคยอ่านเรื่องของผู้ควบคุมงานก่อสร้างคนหนึ่งที่เก่งผิดปกติในการหาท่อที่อยู่ใต้ดินหรือในผนัง จนคนงานนับถือมาก ตอนแรกเขาเองก็เริ่มเชื่อว่าเป็นพลังพิเศษ แต่สุดท้ายสรุปว่าน่าจะเป็นการเรียนรู้รูปแบบทั่วไปและเบาะแสที่ไม่ตรงไปตรงมาซึ่งโผล่มาให้เห็นเป็นครั้งคราวโดยไม่รู้ตัว เช่น มองช่องระบายอากาศบนผนังตึกแล้วเดาได้ว่าใต้ดินน่าจะมีท่อน้ำเสีย
    • ตอนฉันเล่น Cyberpunk 2077 เวอร์ชันช่วงเปิดตัวแรก ๆ บน PS4 ก็เป็นแบบนั้นเหมือนกัน
      ฉันเริ่มจับจุดได้ค่อนข้างแม่นว่า “เกมนี้กำลังจะเด้งแล้ว ต้องเซฟ” พอเซฟแล้วเล่นต่ออีก 10 วินาทีก็เด้งจริง ๆ จนทุกวันนี้ก็ยังไม่รู้ว่ารู้ได้ยังไง
  • 5,000 ดอลลาร์ นี่ก็จำนวนแบบเจ้าชายเหมือนกันนะ ในปี 2016 บริษัทของเราก็เคยโดนเรียกแบบนั้น
    เราโดน DDoS และตัดสินใจจะเมินมัน แต่ก็ไปหาซื้อ BTC ติดไว้เผื่อจำเป็น หลังจากนั้นเราต้องลงระบบป้องกัน DDoS เยอะมากจนเสียเงินมากกว่า 5,000 ดอลลาร์ไปอีกมาก แต่การไม่จ่ายเงินให้พวกขู่กรรโชกก็คุ้มค่า

    • ราว 20 ปีก่อน ตอนอยู่ในทีมผู้ดูแลระบบ ฉันดันกลายเป็นคนที่ต้องรับมือการโจมตี DDoS ไปโดยปริยาย มีอีเมลข่มขู่ส่งมาอยู่ประมาณ 2 สัปดาห์
      1. ไม่จ่าย 50,000 ดอลลาร์จะโดนโจมตี — ไม่เกิดอะไรขึ้น
      2. ไม่จ่าย 25,000 ดอลลาร์ก็เตรียมตัวได้เลย — เซิร์ฟเวอร์มีโหลดเพิ่มขึ้นนิดหน่อยแต่ไม่ร้ายแรง
      3. ไม่จ่าย 10,000 ดอลลาร์ก็เจอดี — มีการโจมตีหนักที่กระทบบริการอย่างมาก
      4. 5,000 ดอลลาร์ ตอนนี้โกรธจริงแล้ว — รอบนี้เล่นจนทั้ง Tier2 ISP และดาต้าเซ็นเตอร์ใน London ล่มไปทั้งวัน ผู้ให้บริการรายอื่นที่ peer กันอยู่ที่ London Internet Exchange ต้อง blackhole ทราฟฟิกฝั่งผู้ให้บริการของเรา และสุดท้าย IP ของเราตัวหนึ่งก็ถูก blackhole อยู่นานพอสมควร เราต้องรีบหาบริการบรรเทา DDoS, ดาต้าเซ็นเตอร์ใหม่ และเซิร์ฟเวอร์ใหม่
        เราไม่ตอบอีเมลฉบับไหนเลย พวกผู้โจมตีก็โง่พอสมควรเพราะเล่นแต่เว็บเซิร์ฟเวอร์ที่อยู่ในที่ที่คอนเนกชันดี
        ส่วนบริการที่ทำเงินจริงอยู่ที่ Caribbean และมีแค่ T1 1.5Mbps กับแบ็กอัปผ่านดาวเทียม 0.5Mbps เท่านั้น ที่นั่นอัดให้ล่มได้ง่ายกว่าและนานกว่ามาก ซึ่งถ้าโดนจริงจะเสียรายได้ประมาณ 1 ล้านดอลลาร์ต่อชั่วโมง
    • ปัญหาของการจ่าย เงินขู่กรรโชกหรือค่าไถ่ คือมันจูงใจให้คนร้ายกลับมาทำอีก
      การจ่าย 5,000 ดอลลาร์ให้อาชญากรคนหนึ่งอาจดูถูกกว่าสร้างระบบป้องกัน แต่ถ้าคุณมีระบบป้องกันแล้ว โอกาสที่จะโดนในอนาคตก็น่าจะลดลง และอย่างที่บอก แค่ไม่จ่ายเงินให้อาชญากรก็มีคุณค่าในตัวมันเองแล้ว
  • สำหรับประโยคที่ว่า “ฉันไม่ได้ตอบกลับ แต่พอย้อนคิดแล้ว การแหย่กลับน่าจะสนุกดี” นั้น การไม่ตอบ คือคำตอบเดียวที่ได้ผล
    ถ้าไปแหย่กลับ คุณอาจยิ่งเด่นขึ้นมาและกลายเป็นเป้าของการโจมตีอื่น ๆ แล้วจะได้อะไรขึ้นมา?

    • ใช่ ฉันรู้ว่ามันอาจเรียกปัญหาใหญ่กว่าเดิมมา
      แต่แค่จินตนาการก็สนุกดี โดยเฉพาะหลังจากดูวิดีโอนี้ที่ลิงก์ไว้ในบทความ: https://www.youtube.com/watch?v=dWzz3NeDz3E
  • เมื่อก่อนคนในครอบครัวฉันเคยรู้ว่าน้ำรั่วจากเครื่องล้างจานเพราะ การแจ้งเตือนจากแมว
    สรุปคือแมวอาจพยายามช่วย หรือไม่ก็กำลังพยายามฆ่า อยู่สองอย่างนี้แหละ

    • ในนิยาย Anansi Boys ของ Neil Gaiman ก็มีเกร็ดคล้าย ๆ กัน
      มีคนคนหนึ่งนอนกลางแจ้งแล้วตื่นเพราะเสียงอีกา จากนั้นก็พบว่ามีสัตว์ตระกูลแมวตัวใหญ่ น่าจะเป็นเสือ กำลังย่องเข้ามา
      ตัวละครหนึ่งมองว่าอีกาพยายามเตือนคนนั้น แต่อีกตัวละครมองว่านกกำลังบอกตำแหน่งของคนนอนให้เสือ เพื่อจะได้มากินเศษซากหลังมื้ออาหาร
    • “พยายามช่วยหรือพยายามฆ่า” งั้นก็เป็น แมวของ Schrödinger แบบกลับด้านเลย
  • พอบอกว่า “ไวยากรณ์แย่มาก” ก็ให้ความรู้สึกเหมือนยุคก่อน ChatGPT เลย
    แต่ถ้าพูดจริงจังกว่านั้น วันหนึ่งจะมีวิธีหยุดการโจมตีแบบ DDoS ได้ถาวรไหม? ภัยคุกคามทุกแบบก็แย่ทั้งนั้น แต่ DDoS ดูเหมือนเป็นประเภทการโจมตีที่ง่อยที่สุด ต้องการทักษะหรือความรู้เฉพาะทางไม่มาก แค่รันสคริปต์ หรือไม่ก็จ่ายเงินให้คนอื่นทำเป็นบริการแทนได้เลย

    • มันไม่ได้ง่ายแค่ระดับ “รันสคริปต์ตัวเดียวก็พอ”
      ที่อยู่ IP และถ้าเป็น IPv6 ก็รวมถึง subnet เป็นทรัพยากรที่ผู้ใช้ทั่วไปมีจำกัด และแบนด์วิดท์ก็เช่นกัน การโจมตีแบบ amplification ส่วนใหญ่ต้องอาศัย IP spoofing ซึ่งในการเชื่อมต่อทั่วไปมักทำไม่ได้
      ถ้าเป็นการโจมตีแบบกินปริมาณ ใครมีแบนด์วิดท์มากกว่าก็ชนะ ฝั่งผู้โจมตีใช้ amplification ได้ในจุดนี้ ส่วนถ้าเป็นการโจมตีแบบสร้างภาระหรือระดับ application layer ก็แก้ได้ด้วยการบล็อก IP ของผู้โจมตีที่ระดับไฟร์วอลล์ กรณีนี้มี WAF/Cloudfront อยู่แล้ว จึงน่าจะใกล้เคียงกับการโจมตีระดับ application layer มากกว่าจะเป็นการโจมตีด้านปริมาณล้วน ๆ
      การหา IP ของผู้โจมตีที่จะบล็อก คือปัญหาของการคิดต้นทุนตาม source IP ให้แม่นยำ แล้วก็คิดผลประโยชน์จากกิจกรรมของผู้ใช้จริงตาม source IP ให้แม่นยำเช่นกัน จากนั้นจึงบล็อก IP หรือช่วง IP ที่ต้นทุนสูงกว่าผลประโยชน์อย่างมาก
      มันไม่ได้ง่ายอย่างที่พูด ต้นทุนอาจมาได้หลายรูปแบบ เช่น การเชื่อมต่อที่เปิดค้างไว้กินหน่วยความจำ, TLS handshake, request ที่เว็บเซิร์ฟเวอร์ต้องเสียค่า parse สูง, request ที่ไปกระตุ้นให้เกิด database query ราคาแพง, แบนด์วิดท์ I/O เป็นต้น เพราะอย่างนั้นคนส่วนใหญ่จึงวาง Cloudflare หรือแบบในที่นี้คือ Cloudfront ไว้ด้านหน้า แล้วแก้เฉพาะหน้าด้วยกฎแบบ manual อย่างในกรณีนี้
    • Cloudflare ช่วยกันได้ดีพอสมควร ถ้ายอมรับต้นทุนด้านความรวมศูนย์ได้บ้าง
      ถ้ามีวิธีทำให้ตัว protocol ทน DDoS ได้ตั้งแต่ระดับนั้นก็คงเจ๋งดี แต่ก็ไม่แน่ใจว่าทำได้แค่ไหน
    • application-layer DDoS ปกติป้องกันด้วยแนวคิดว่า อย่าไปทำงานราคาแพงให้ไคลเอนต์ที่ยังไม่ได้ทำงานอะไรที่มีต้นทุนมาก่อน ฟังดูง่ายแต่ในทางปฏิบัติบางทีก็ยาก
      แล้วก็มี DDoS แบบกินปริมาณ ซึ่งกันได้ถ้าคุณมีแบนด์วิดท์มากกว่าทุกฝ่ายรวมกัน แต่ทำได้ยากพอสมควร และตัวคุณเองก็อาจกลายเป็นผู้โจมตีที่เป็นไปได้ด้วย
      นวัตกรรมตรงนี้คือการกระจาย traffic filter ผ่าน BGP ส่วน null routing ก็คือผลิตภัณฑ์ขั้นต่ำที่ใช้งานได้ประมาณว่า IP นี้กำลังโดนโจมตี ทิ้งทราฟฟิกที่ไปทางนั้นให้เร็วที่สุดเท่าที่จะทำได้ ผมยังเคยเห็นระบบที่ละเอียดกว่านั้น เช่น ทิ้ง UDP, ทิ้ง fragmented packet, ทิ้ง packet ขาเข้า/ขาออกของพอร์ต UDP/TCP บางพอร์ต
      ระบบพวกนี้ส่วนใหญ่ออกแบบมาไม่ให้ route พิเศษแพร่ข้ามไปไกลกว่าคู่ peer โดยตรง แต่บางกรณีก็อาจอยากให้มันแพร่ต่อไป
    • เพราะหัวข้อนี้เลยอ่าน ChatGPT เป็น CatGPT ไปแล้ว และตอนนี้เอาออกจากหัวไม่ได้เลย
    • ถ้าเครือข่ายกระจายศูนย์มากกว่านี้และเป็นแบบ แบนด์วิดท์ต่ำ กว่าเดิม อาจจะทำได้ก็ได้
      ถ้าลูกค้าส่วนใหญ่อยู่ใน Mexico แล้ว Canada เป็นฝ่ายยิง DDoS จนลิงก์ระหว่างผมกับ Canada เต็ม ก็อาจไม่ใช่ปัญหาใหญ่นัก ตราบใดที่เราเตอร์ฝั่งผู้ใช้ใน Mexico ไม่พากันเข้ามาช่วยแบกรับคอขวดฝั่ง Canada นั้น
  • ตอนแรกนึกว่าคุณเอาเครื่องให้อาหารแมวไปต่อกับระบบแจ้งเตือน
    แต่ยังไงก็น่ารักดี แมวชื่ออะไรเหรอ?

    • ระหว่างเขียนโพสต์นี้ ผมก็นึกว่าถ้ามีหมาที่ฝึกมาดี ก็อาจต่อ บริการมอนิเตอร์ เข้ากับอุปกรณ์ที่ส่งเสียงบางอย่างได้ แล้วให้หมาที่ได้ยินเสียงนั้นไปบอกคนอีกที
      มันชื่อ Bamboo ครับ น่าเสียดายที่จากไปเพราะมะเร็ง หนึ่งในอย่างแรก ๆ ที่มันทำหลังรับมาเลี้ยงคือพยายามกินต้นไผ่ในกระถางของผม เลยตั้งชื่อนั้น
    • ขำดีที่ลูกค้ารายแรกของบริษัทรู้ว่าเครือข่ายของ Optus ผู้ให้บริการโทรคมนาคมออสเตรเลียล่ม ก็ด้วยวิธีนี้แหละ
      เครื่องให้อาหารแมวไร้สายต้องพึ่งอินเทอร์เน็ต แต่พออาหารไม่ออก แมวก็เดินไปประท้วงกับแอดมิน
    • ขอเสนอ Danielle จาก Purrvice
  • ทำให้นึกถึงหนังสือเล่มนี้: Dogs that Know When their Owners are Coming Home https://www.sheldrake.org/books-by-rupert-sheldrake/dogs-tha...

  • การกัน DDoS ด้วย token bucket มันง่ายเกินไป จนปกติช่วงที่แมวต้องมาปลุกผมมีแค่ตอน Discord ของผมโดนถล่มเท่านั้น

    • ไม่เคยได้ยินมาก่อนเลยไปค้นดู: https://en.wikipedia.org/wiki/Token_bucket
      ดูเหมือนจะใกล้เคียงกับการทิ้ง packet ที่ทำให้เกิดโหลดมากเกินไปตั้งแต่ฝั่งไฟร์วอลล์หรือ ingress ก่อนที่มันจะไปถึง application server
    • ก็จริงสำหรับ DDoS บางประเภทเท่านั้น ;)
      ถ้าเป็นการโจมตีที่มีปริมาณคำขอเชื่อมต่อหรือจำนวน IP ที่ไม่ซ้ำกันมากพอ ก็ยังทำให้บริการโอเวอร์โหลดได้อยู่ดี
      ปกติ token bucket เป็นแค่ส่วนหนึ่งของ กลยุทธ์ด้านความทนทาน โดยรวม ไม่ใช่วิธีวิเศษที่แก้ปัญหา denial of service ได้ทุกแบบ