การบล็อกการเชื่อมต่อจาก AWS มายังบริการ on-premises ของฉัน

 (consulting.m3047.net)
1 คะแนน โดย GN⁺ 2024-09-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • อินเทอร์เน็ตสาธารณะอาจแตกออกเป็น ระบบนิเวศที่แยกส่วน โดยมีผู้ให้บริการคลาวด์รายใหญ่เป็นศูนย์กลาง และกรณีการบล็อกการเข้าถึง on-premises จาก AWS เป็นตัวอย่างเชิงปฏิบัติการที่สะท้อนแนวโน้มนี้
  • สิ่งที่ถูกบล็อกหลัก ๆ คือ ความพยายามเชื่อมต่อ TCP ที่ไคลเอนต์ภายใน AWS เปิดมายังบริการ on-premises ส่วนการเชื่อมต่อขาออกจากไคลเอนต์ภายในเครื่องไปยังบริการที่โฮสต์บน AWS ยังทำได้ต่อไป
  • บริการ on-premises ที่ดำเนินงานอยู่ ได้แก่ เว็บ, เดโม Trualias, DNS และ SMTP โดย DNS ให้การเข้าถึงสาธารณะผ่าน UDP, TCP fallback และ เทเลเมทรีด้านความปลอดภัย แบบจำกัด
  • การบล็อก AWS เริ่มจากการรับมือทราฟฟิก ping ที่มากเกินไปและ crawler/scanner ที่มีพฤติกรรมละเมิด ปัจจุบันดูแล 53 CIDR ของพื้นที่แอดเดรส AWS ที่สังเกตว่าเป็นเป้าหมายหรือแหล่งที่มาของ abuse
  • หากผู้ให้บริการคลาวด์รายใหญ่ไม่เปิดเผย ข้อมูลฟอเรนสิก อย่าง reverse DNS, whois, namespace ของ DNS และรูปแบบ abuse ให้ดีกว่านี้ การแยกส่วนที่ผู้ใช้ภายในคลาวด์แทบไม่รู้สึกถึงความไม่สะดวกก็อาจยิ่งรุนแรงขึ้น

ความเป็นไปได้ของการแยกส่วนที่เกิดจากคลาวด์รายใหญ่

  • หากผู้ให้บริการคลาวด์รายใหญ่กลายเป็น bulletproof infrastructure ที่ “too big to fail” ก็อาจเป็นต้นเหตุโดยตรงของการแยกส่วนของอินเทอร์เน็ต
  • แม้ยังไม่ใช่ปรากฏการณ์ที่เกิดขึ้นเต็มรูปแบบ แต่ถือว่าเริ่มขึ้นแล้วหรืออาจปรากฏให้เห็นในไม่ช้า
  • ระบบนิเวศ cloud-native มี โครงสร้างพื้นฐานที่ปรับแต่งเฉพาะ เมื่อเทียบกับอินเทอร์เน็ตจริง และบริการคลาวด์แต่ละรายถูกจัดวางโดยเน้นฟีเจอร์ที่แตกต่าง มากกว่าสถาปัตยกรรมร่วมกัน
  • บริการจำนวนมากทำงานได้แบบสมบูรณ์ในตัวเองภายในคลาวด์ใดคลาวด์หนึ่ง และมีอุปสรรคต่อการทำงานร่วมกับอินเทอร์เน็ตทั่วไปอย่างโปร่งใส
  • ชุมชน cloud-native ปฏิบัติต่ออินเทอร์เน็ตทั่วไปเหมือนเป็น ทรัพยากรภายนอก และมีปฏิสัมพันธ์กับระบบนิเวศของผู้ให้บริการคลาวด์รายใดรายหนึ่งมากกว่าตัวอินเทอร์เน็ตเอง

กระแสการพาณิชย์ของอินเทอร์เน็ตสาธารณะ

  • ก่อนปี 1989 อินเทอร์เน็ตไม่มีการเข้าถึงสาธารณะทั่วไป และเป็นเครือข่ายลักษณะส่วนตัวที่หน่วยงานรัฐบาล ทหาร วิจัย และการศึกษาใช้งาน
  • NSF ดูแลแกนหลักของ backbone และการเข้าถึงสาธารณะในช่วงแรกได้รับอนุญาตภายใต้เงื่อนไขว่าเป็น ทราฟฟิกที่ไม่ใช่เชิงพาณิชย์
    • ไม่ได้หมายความว่าบริการเชิงพาณิชย์ถูกห้ามโดยตัวมันเอง แต่ทราฟฟิกที่ผ่าน backbone ของ NSFNet ต้องไม่ใช่ทราฟฟิกโฆษณาหรือบริการแบบชำระเงิน
  • ผู้ประกอบการเชิงพาณิชย์สร้างอินเทอร์เน็ตเชิงพาณิชย์แยกต่างหาก และในปี 1995 NSFNet ได้ปิดการเข้าถึงสาธารณะ
  • หลังการคัดออกครั้งใหญ่ราวปี 2000 โมเดลที่อยู่รอดคือโฆษณาบนฐานข้อมูลพฤติกรรมผู้ใช้และการขายข้อมูลพฤติกรรมผู้ใช้
  • ในกระแส AI ปัจจุบัน สิ่งที่เด่นชัดคือการเก็บรวบรวมและฟอกเนื้อหาที่เข้าถึงได้จำนวนมากเพื่อใช้ฝึกโมเดล โดยการคัดสรรและการฝึกทำกันเป็นหลักบนคลาวด์ และเพิ่มขึ้นเรื่อย ๆ โดยผู้ให้บริการคลาวด์เอง

การบล็อกการเชื่อมต่อจาก AWS ในบริการ on-premises

  • กำลังปิดใช้งานการเข้าถึงจาก AWS ที่เข้ามายังเซิร์ฟเวอร์ on-premises เป็นส่วนใหญ่
  • ในเชิงเทคนิค สนใจหลัก ๆ ที่ ทราฟฟิก TCP และสามารถแยกไคลเอนต์กับเซิร์ฟเวอร์ได้จาก handshake ช่วงต้น
    • บล็อกกรณีที่ไคลเอนต์ภายใน AWS พยายามเชื่อมต่อมายังบริการ on-premises
    • อนุญาตให้ไคลเอนต์ในเครือข่ายท้องถิ่นเชื่อมต่อไปยังบริการที่โฮสต์บน AWS ได้
  • มีการให้บริการหลายอย่างจากระบบภายในเครื่องที่เปิดสู่อินเทอร์เน็ต
    • บริการเว็บ
    • เดโม Trualias
    • เซิร์ฟเวอร์ DNS
    • เซิร์ฟเวอร์อีเมล SMTP
  • รักษานโยบาย no crawl มาหลายปี และทรัพย์สินที่ให้บริการมุ่งไปที่ผู้ใช้รายบุคคลบนอินเทอร์เน็ตเป็นหลัก
  • เซิร์ฟเวอร์ DNS ใช้ UDP และ TCP fallback พร้อมให้เทเลเมทรีความปลอดภัยสาธารณะแบบจำกัด
    • ตัวอย่าง query: dig @131.191.85.30 'fail2ban;*.keys.redis.athena.m3047' txt
    • อาจมีประโยชน์กับบริการที่รันบนคลาวด์ด้วย แต่หากจะพึ่งพาในการปฏิบัติงาน ก็คาดหวังให้ติดต่อมาก่อน

ข้อยกเว้นของ reverse DNS และ SMTP

  • หากปัญหามีแค่บริการเว็บ ก็สามารถใช้มาตรการบรรเทาอื่น เช่น การตรวจสอบ reverse DNS ได้
  • ผู้ให้บริการคลาวด์มักดูแล reverse DNS ได้ไม่ดี ซึ่งสอดคล้องกับเรื่องเล่าที่ว่าทรัพยากรในคลาวด์เป็นสิ่ง ชั่วคราว
  • AWS ทำ reverse DNS ได้ดีกว่าผู้ให้บริการคลาวด์จำนวนมาก และเคยได้ยินว่าสามารถตั้งค่า reverse DNS ของ instance ได้ แต่ไม่ได้ลองเอง
  • มีข้อยกเว้นให้ SMTP
    • หากไม่ได้เป็นปัญหารุนแรงเป็นพิเศษ แม้จะบล็อกการเชื่อมต่อของบริการอื่น ก็ยังอนุญาตการเชื่อมต่อของเมลเซิร์ฟเวอร์
    • ในเชิงเทคนิคสามารถให้บริการ SMTP ได้แม้ไม่มี reverse DNS ที่ถูกต้อง แต่ในทางปฏิบัติ หากไม่มี reverse DNS ที่ถูกต้อง อีกฝ่ายมักไม่รับเมล
  • การประเมิน reverse DNS ช่วยให้ ตัดสินเบื้องต้น ได้ว่า SYN มาจากเมลเซิร์ฟเวอร์ที่ถูกต้องหรือไม่
    • บริการ reputation สามารถให้คะแนน reverse DNS ได้
    • มีรูปแบบที่พบบ่อยในทรัพยากรแบบเช่าและแบบชั่วคราว
  • เพียงดูว่ามี reverse DNS หรือไม่ หรือรูปแบบเป็นอย่างไร ก็พอประเมินได้อย่างสมเหตุสมผลว่าแอดเดรสนั้นเป็นของผู้ให้บริการคลาวด์หรือไม่

เหตุผลที่เริ่มบล็อกแอดเดรส AWS

  • เริ่มจากงานบล็อก netblock ที่ระบุได้ของบริการ abusive บางส่วน แล้วต่อยอดเป็น proof of concept สำหรับการบล็อกผู้ให้บริการโฮสติ้งรายเล็กแบบคัดเลือก
  • ในกรณีของ AWS จุดเริ่มต้นคือ ทราฟฟิก ping ที่มากเกินไป
    • ping เป็นโปรโตคอลแบบไม่มีการเชื่อมต่อ จึงปลอมแปลงต้นทางได้
    • การตอบกลับของคำขอ ping ที่ถูกปลอมแปลงจะไปยังตำแหน่งจริงที่ถูกปลอม ไม่ใช่ผู้โจมตี
  • หากต้องการกดการตอบกลับ ping ที่ไม่หยุดหย่อน ต้องสร้างกฎไฟร์วอลล์ชั่วคราว แต่ขนาดของ Amazon ใหญ่เกินไปจนจำนวนกฎเพิ่มมาก
  • เริ่มรวบรวมช่วงแอดเดรสของ AWS และปัจจุบันมี 53 CIDR ที่เป็นตัวแทนพื้นที่แอดเดรส AWS ซึ่งถูกสังเกตว่าเป็นเป้าหมาย abuse หรือเป็นแหล่งที่มาของ abuse
  • บางครั้งพบกฎไฟร์วอลล์ชั่วคราวมากถึงสองเท่าของจำนวนดังกล่าว
  • การบล็อก crawler และ scanner แบบ abusive ที่เช่าจากผู้ให้บริการคลาวด์ “too big to fail” เป็นผลพลอยได้ที่ดี และแม้จะหายไปจากเว็บล็อกก็ไม่น่าเสียดาย

ผลกระทบที่ผู้ใช้คลาวด์ได้รับ

  • ทรัพยากรยอดนิยมส่วนใหญ่หรือทรัพยากรที่มีแนวโน้มถูก deploy บนคลาวด์ โฮสต์อยู่บน GitHub
  • ผู้ที่ deploy ทรัพยากรอื่นบนคลาวด์ต้องดูแล repository ของตนเองสำหรับใช้ staging
  • หาก repository อยู่บน AWS ก็จะไม่สามารถตรวจสอบอัปเดตได้อีก
    • ต้องตรวจสอบจากเดสก์ท็อป
    • ต้องตรวจสอบจากทรัพยากรที่โฮสต์แบบส่วนตัว
    • สามารถหารือ arrangement แยกต่างหากได้
  • สภาพที่มีเพียงสมาร์ทโฟน, S3 bucket และ EC2 instance อาจไม่ควรถูกมองว่า “อยู่บนอินเทอร์เน็ต” แต่บนสมาร์ทโฟนควรยังเข้าถึงทรัพยากรเหล่านั้นได้

การบรรเทาการขโมยข้อมูลและการใช้งานที่ไม่ได้ตั้งใจ

  • การขโมยข้อมูล ที่นำทรัพยากรโอเพนซอร์สไปใช้เพื่อวัตถุประสงค์ที่ไม่ได้ตั้งใจโดยไม่ได้รับอนุญาต ก็เป็นภัยคุกคามที่ต้องมีการบรรเทาแยกต่างหาก
  • การบล็อก AWS ทำหน้าที่เป็นหนึ่งในมาตรการบรรเทาเช่นนั้นด้วย
  • ข้อมูลเกี่ยวกับ cats, bunnies, birds ก็ถูกพูดถึงร่วมกันในบริบทของมาตรการบรรเทา
    • cats และ bunnies ถูกยกขึ้นมาเพราะมีวิดีโอที่เกี่ยวข้องจำนวนมาก และบางส่วนซื้อได้
    • birds มีประสิทธิภาพมากกว่าที่ OSI layer 2 และถูกบันทึกไว้ใน RFC ในฐานะวิธีส่ง IP datagram

ข้อมูลสาธารณะที่ผู้ให้บริการคลาวด์รายใหญ่จำเป็นต้องมี

  • ผู้ให้บริการคลาวด์รายใหญ่ควรมีระบบ เผยแพร่ข้อมูลฟอเรนสิก ที่ดีกว่านี้
  • DNS และ whois อาจเป็นเครื่องมือสำหรับเผยแพร่ข้อมูลที่มีประโยชน์ได้
  • หากเป็นผู้ให้บริการรายใหญ่ ก็ควรสามารถดูแล reverse DNS ของตนเองได้
  • อาจจำเป็นต้องมี whois สำหรับแอดเดรสแต่ละรายการ ข้อมูลเพิ่มเติมที่เข้ารหัสไว้ใน reverse DNS และข้อมูลสาธารณะแยกต่างหากใน namespace ของ DNS
  • storm center blog ที่ว่าด้วยรูปแบบ abuse ปัจจุบันและบล็อกแอดเดรสที่ได้รับผลกระทบ ก็เป็นแนวทางหนึ่งที่เป็นไปได้
  • สำหรับ SMTP นอกจาก reverse DNS แล้วยังมี SPF ที่เผยแพร่ผ่าน DNS TXT record
  • ควรสามารถค้นหาข้อมูลที่จะตอบคำถามต่อไปนี้ได้จาก IP address เพียงรายการเดียว
    • ทรัพยากรที่อยู่เบื้องหลังแอดเดรสนั้นส่ง ping หรือไม่
    • ส่ง ping มากเพียงใด
    • สร้างการเชื่อมต่อ outbound TCP หรือไม่
    • เชื่อมต่อไปยังบริการใด
    • ใครเป็นผู้ควบคุมทรัพยากรนั้น
    • ทรัพยากรกำลังถูกโจมตีอยู่หรือไม่
    • เป็นการโจมตีประเภทใด
    • ทรัพยากรอื่นบนอินเทอร์เน็ตต้องการให้มีการบรรเทาแบบใด
  • การบรรเทาที่เหมาะสมเป็นประโยชน์ต่อทุกคน แต่การบรรเทาที่เล็งผิดเป้าไม่ใช่เช่นนั้น

ผลลัพธ์ของอินเทอร์เน็ตที่แยกส่วน

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

บทความที่เกี่ยวข้อง

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

 
GN⁺ 2024-09-01
ความคิดเห็นบน Hacker News

  • ผู้ให้บริการคลาวด์รายใหญ่ทั้งหมดเผยแพร่ รายการช่วง IP ที่เครื่องอ่านได้
    เช่น: https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-rang...
    https://www.microsoft.com/en-us/download/details.aspx?id=565...
    https://support.google.com/a/answer/10026322?product_name=Un... เป็นต้น

    • วันนี้ยังไม่ได้ตรวจดู แต่ตัวอย่างเช่นไฟล์ JSON ของ Amazon นั้น นอกเหนือจากประเด็นว่าเป็นเจ้าของจริงหรือไม่ แทบจะกลบความจริงที่ว่าใช้ 3.0.0.0/8 ไปเลย
      ผมไม่คิดจะเล่นเกมทำนอง “ลองบล็อกรายการ JSON มหึมาของ Amazon กันเถอะ” และกฎมีแค่ 53 ข้อเท่านั้น ยอมรับผลข้างเคียงได้ในระดับหนึ่ง และเว็บที่อยู่บน AWS ก็ยังเข้าได้ดี

  • ทุกวันนี้บนอินเทอร์เน็ต ความเร็วที่ทราฟฟิกเชิงโจมตีเข้ามาเกาะทันทีที่เปิดเผยโครงสร้างพื้นฐานนั้นบ้าคลั่งมาก
    เมื่อไม่นานมานี้ผมประกาศ ซับเน็ต /23 หนึ่งผ่าน BGP เพื่อทำคอนฟิก anycast พอ route ขึ้นและทราฟฟิกไหลเข้ามาที่เราเตอร์ tcpdump ก็พุ่งทะลักด้วย port scan ไปยัง IP ทุกตัวในช่วงนั้นทันที
    แน่นอนว่าไม่ใช่เพราะ route เอง แต่ดูเหมือนมีหลายฝ่ายสแกนช่วง IP ทั้งหมดแบบหว่านและตลอดเวลา ช่วงนี้ไม่ได้ถูกประกาศมาหลายปีแล้ว จึงไม่น่าจะอยู่ในรายชื่อเซิร์ฟเวอร์ที่ใช้งานอยู่ของใคร
    ยังรู้สึกตกใจที่ยังมีการเปิดบริการเว็บภายในอย่าง GitLab ออกสู่อินเทอร์เน็ตตรง ๆ อย่างน้อยควรมี ชั้นป้องกันเพิ่มเติม อย่าง VPN เพื่อไม่ให้บริการถูกค้นพบบนอินเทอร์เน็ตสาธารณะ
    สิ่งเดียวที่เข้าถึงได้แบบสาธารณะคือ SSH ของ bastion host เพียงตัวเดียว และภายหลังผมก็อยากเอาสิ่งนี้ออกโดยวางชั้น VPN เพิ่มเข้าไปเช่นกัน

    • ควรปรับความคาดหวังใหม่จะดีกว่า port scan ไม่ใช่เรื่องใหญ่อะไร และจะเรียกว่าเป็นการโจมตีก็ยังคลุมเครือ มันเหมือนรังสีพื้นหลังของอินเทอร์เน็ต
      เหมือนเวลาไปอวกาศก็มีรังสีพื้นหลัง พอไปอินเทอร์เน็ตก็มีรังสีพื้นหลังของอินเทอร์เน็ต ถ้าคุณไม่ได้รันบริการที่มีช่องโหว่ port scan พวกนี้ก็มีความเสี่ยงประมาณกินกล้วยเพิ่มอีกลูกต่อเดือน
      มันน่ารำคาญก็เพราะคุณนั่งดูมันอยู่ตรงคอนโซล เหมือนถือเครื่องวัดไกเกอร์ที่ไวเกินไปขึ้นเครื่องบินแล้วอาจตกใจ แต่ถ้าไม่รู้ก็ไม่ได้เป็นอันตรายอะไร
      ผมเองก็ตกใจกับการเปิดบริการภายในสู่อินเทอร์เน็ตเหมือนกัน ด้วยสองเหตุผล คือไม่เชื่อถือระบบยืนยันตัวตนของโปรแกรมส่วนใหญ่ และไม่อยากให้ภายนอกรู้ว่าใช้บริการภายในอะไรอยู่ มีเหตุผลที่ใกล้กับความเป็นส่วนตัวมากกว่าความปลอดภัยเชิงเทคนิคล้วน ๆ ด้วย
      ในทางกลับกัน สิ่งที่จำเป็นต้องอยู่บนอินเทอร์เน็ต และมีประตูหน้าที่แข็งแรง หรือเชื่อว่าถูก sandbox ไว้เพียงพอ ก็อยู่บนอินเทอร์เน็ตทั้งวันได้
      port scan คือเวอร์ชันอินเทอร์เน็ตของการเดินไปทั่วเมืองแล้วจดว่าบ้านไหนเปิดไฟอยู่ อาจดูเหมือนสตอล์กเกอร์ไปหน่อย แต่เป็นข้อมูลสาธารณะ
      อนึ่ง ssh -w สร้างอินเทอร์เฟซ VPN tunnel ได้ แต่ไม่ได้ตั้งค่าส่วนที่เหลือให้อัตโนมัติเหมือนผลิตภัณฑ์ VPN จริง ๆ
    • ถ้าต้องการเพิ่มชั้น VPN ไว้ด้านบน ก็สงสัยว่าจะใช้ ซอฟต์แวร์ VPN ตัวไหน โดยส่วนตัวผมยังไม่เจอตัวที่รู้สึกว่าน่าเชื่อถือเท่า OpenSSH
    • SSH สาธารณะที่ตั้งค่าผิดพลาดห้ามเปิดขึ้นมาเด็ดขาด พูดตรง ๆ คืออาจโดนเจาะได้ภายในไม่กี่วินาที
      อินเทอร์เน็ตยิ่งรู้สึกเหมือนสิ่งที่เกิดขึ้นหลัง blackwall ใน Cyberpunk มากขึ้นเรื่อย ๆ
    • นี่ไม่ใช่เรื่องของ “สมัยนี้” เท่านั้น เมื่อ 25 ปีก่อน การที่สคริปต์หรือบอตคอยตรวจเว็บเซิร์ฟเวอร์ที่เปิดเผยอยู่ตลอดก็พบได้ค่อนข้างบ่อย และเห็นได้บ่อยในเว็บ access log
      ถ้าเปิด log การปฏิเสธการเข้าถึงของไฟร์วอลล์ไว้ ความพยายามต่อพอร์ตที่รู้จักและไม่รู้จักจะไหลเข้ามาอย่างถาวร
      ถ้าคุณเปิดเผยอะไรออกไป แม้จะเป็นคอมโพเนนต์เว็บที่ซ่อนลึกแค่ไหน ก็ต้องไม่ปล่อยให้มันกลายเป็นประตูเข้าสู่ข้อมูลและโครงสร้างพื้นฐาน
      สิ่งที่ต่างจากตอนนั้นเล็กน้อยคือแหล่งที่มาของทราฟฟิก และเกณฑ์ในการตัดสินว่าควรรับหรือควรบล็อก จำนวนเซิร์ฟเวอร์/บริการที่ถูกกฎหมาย พร็อกซีฝั่งผู้ใช้ปลายทาง ผู้ให้บริการคลาวด์ และ crawler เพิ่มขึ้นมาก
    • เรื่องนี้ฟังดูเหมือนเป็นปัญหาเฉพาะของ IPv4 ถ้าไปเป็น IPv6-only การสแกน IP สำหรับผู้ไม่หวังดีจะกลายเป็นเรื่องแทบทำไม่ได้ในทางปฏิบัติหรือเปล่า?

  • น่าเสียดายมากจริง ๆ การทำแบบนั้นจะทำให้คอนเทนต์ของตัวเองไม่โผล่ในเสิร์ชเอนจินเลย ไม่ถูกจับโดย Marginalia และยังเสี่ยงที่จะไม่ถูกเก็บไว้ใน Wayback Machine ด้วย
    ถ้าเดิมทีต้องการแบบนั้นจริง ๆ การบล็อกคลาวด์และดาต้าเซ็นเตอร์ทั้งหมดก็อาจเป็นทางเลือกที่ถูกต้อง แม้กระทั่งผู้ใช้ของ ISP รายเล็กบางรายก็อาจถูกบล็อกไปด้วย ขึ้นอยู่กับว่า ISP นั้นรัน CGNAT gateway ไว้ที่ไหน ความเป็นไปได้ต่ำ แต่ก็ไม่ใช่ว่าเป็นไปไม่ได้
    สิ่งที่บทความพูดถึงว่าเป็นการใช้งานในทางที่ผิดจริง ๆ ดูเหมือนมีแค่ ping ที่ปลอมแปลงที่อยู่ต้นทางเท่านั้น และเราไม่อาจรู้ได้ว่าแพ็กเก็ต ping ที่ปลอมแปลงนั้นมาจาก AWS หรือไม่ เพราะที่อยู่ต้นทางคือที่อยู่ที่ผู้ปลอมแปลงต้องการให้ส่งคำตอบกลับไป ไม่ใช่ที่อยู่ของผู้ปลอมแปลงเอง
    วิธีบรรเทาที่รุกล้ำน้อยกว่ามากคือการทำ rate limit ให้ ping เหลือประมาณ 10 ครั้งต่อวินาที
    อินเทอร์เน็ตกำลังแตกเป็นเสี่ยง ๆ จริง แต่สาเหตุหลักไม่ใช่การบล็อกช่วง IP เท่ากับการที่โซเชียลมีเดียกลายเป็นไซโลเพื่อหารายได้จากโฆษณาและข้อมูล รวมถึงกระแสพยายามรีดรายได้จากข้อมูลสำหรับฝึก AI กรณีอย่างสัญญาผูกขาด Reddit/Google น่าจะใกล้เคียงกว่า
    เข้าใจได้ยากกับวิธีคิดที่บ่นว่า IP connectivity กำลังถูกแบ่งแยกเป็นเขต ๆ ทั้งที่ตนเองบล็อกผู้ให้บริการบางรายเพราะ ping ไม่กี่ครั้ง ฝ่ายที่ทำให้เกิดการแบ่งแยกคือฝ่ายที่บล็อกต่างหาก

    • ทุกวันนี้ในเสิร์ชเอนจินแทบไม่เห็นอะไรนอกจากเว็บใหญ่ ๆ อย่าง content farm ขนาดยักษ์ที่เต็มไปด้วยโฆษณา, Wikipedia, Stack Overflow, เว็บไซต์ข่าว/สื่อรายใหญ่ และ YouTube
      ไม่เห็นบล็อกส่วนตัวหรือเว็บงานอดิเรกเล็ก ๆ ในผลค้นหามานานพอสมควรแล้ว
      ถ้าต้องการ Wikipedia หรือ Stack Overflow ก็ไปค้นหาในเว็บนั้นโดยตรงได้อยู่แล้ว อยากให้มีตัวเลือกที่ตัด “ตัวเลือกเดิม ๆ ที่เห็นประจำ” ออก แล้วแสดงคอนเทนต์หางยาวให้มากขึ้น
    • ดูเหมือนเป็นการคร่ำครวญที่ถูก “บังคับ” ให้ต้องใช้มาตรการที่อาจก่อให้เกิดการแบ่งแยกเป็นเขต ๆ
      อย่างไรก็ตาม โทนโดยรวมให้ความรู้สึกใกล้เคียงกับการเอาเรื่องถูกยุงกัดมาเล่าเป็นมหากาพย์ประวัติศาสตร์มากกว่า
    • แม้จะเป็น ISP รายเล็ก ทำไมถึงต้องรัน CGNAT gateway ในที่ที่ไม่ใช่พื้นที่ IP ของตัวเองด้วย?
      ถ้ารัน CGNAT gateway บนคลาวด์น่าจะมีปัญหาเยอะ เพราะสมาชิกจะไม่ได้ใช้ IP แบบที่พักอาศัย อาจดูบริการอย่าง Netflix ไม่ได้ และมีโอกาสเจอ CAPTCHA กันบอทจาก Cloudflare หรือ Google บ่อยขึ้นมาก
      อยากรู้ว่ามีกรณีจริงที่เป็นที่รู้จักหรือไม่
    • อยากรู้ว่าสมมติฐานที่มองว่า “ไม่โผล่ในเสิร์ชเอนจิน” เป็นข้อเสียหรือความเสียหายคืออะไร แม้จะไม่ได้มีมุมมองร่วมกัน แต่กำลังพยายามทำความเข้าใจอยู่
    • ผู้เขียนเคยบอกมานานแล้วว่ายึดนโยบาย ห้ามครอว์ล อยู่ คงไม่ได้ใส่ใจนัก และเมื่อดู enshittification ของ Google แล้ว อาจเป็นทางเลือกที่ถูกต้องด้วยซ้ำ

  • Hetzner, DigitalOcean, Linode, OVH, Contabo ถูกบล็อกมาสักพักแล้ว
    ทำผ่าน การบล็อก ASN ใน pfBlocker NG ก็ได้ หรือใช้กฎ UFW ก็ได้: https://blog.abctaylor.com/ufw-and-firewalld-rules-to-block-...

    • ถ้าบล็อกยกทั้งก้อนแบบนี้ องค์กรปกติอาจเข้าถึงไซต์ไม่ได้ ถ้าเป็นไซต์ที่ขายอะไรสักอย่างก็อาจกลายเป็นปัญหา
      ตัวอย่างเช่น องค์กรหนึ่งอาจรัน WireGuard หรือโซลูชัน VPN อื่นเองบนผู้ให้บริการคลาวด์ แล้วเมื่อผู้คนเชื่อมต่อผ่านตรงนั้น IP ขาออกก็จะดูเป็น IP ของผู้ให้บริการคลาวด์
    • ทุกวันนี้บริษัททั้งใหญ่และเล็กจำนวนมากใช้ VPN หรือโซลูชันคล้ายกันที่มี exit node อยู่บนคลาวด์ การบล็อกแบบนี้สุดท้ายอาจทำให้เข้าถึงเว็บไซต์จากคอมพิวเตอร์ที่ใช้ทำงานไม่ได้
    • โธ่ ทำไมถึงรวม Hetzner ด้วย?
    • คิดว่าควรเป็นแบบต่างตอบแทนเหมือนโลกจริง ถ้าใครบล็อกผู้ให้บริการ ผู้ให้บริการนั้นก็ควรมีสิทธิ์บล็อกกลับได้
      จะผูกระบบอัตโนมัติเข้าไปด้วยก็ได้ แบบนั้นถึงจะยุติธรรม และแต่ละฝ่ายจะได้รู้ว่าเกิดอะไรขึ้น ไม่อย่างนั้นก็เลิกเล่นเกมกระบะทรายแบบนี้ แล้วใช้ปืนจริงไปเลย

  • สิ่งแรกที่นึกถึงคือเดสก์ท็อปจริงที่รันอยู่บน AWS โดยเฉพาะบริการอย่าง Amazon Workspaces อาจถูกบล็อกได้
    อย่างไรก็ตาม พื้นที่ IP ของบริการแบบนั้นก็ดูเหมือนจะมีเอกสารเผยแพร่ไว้แล้ว ดังนั้นถ้าจำเป็นก็อนุญาต IP เหล่านั้นแยกต่างหากได้
    ถึงอย่างนั้น ถ้าใช้พร็อกซีหรือ VPN การเลี่ยงการบล็อกแบบนี้ก็ง่ายมาก

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

  • นานมาแล้ว เซิร์ฟเวอร์ Amazon หลายสิบเครื่องเริ่มทำให้เซิร์ฟเวอร์ on-premise ของเราช้าลง เลยทำแบบนี้
    อาจเป็นความพยายาม SSO อะไรสักอย่างก็ได้ แต่สุดท้ายก็ไม่ได้ไล่ตามจนรู้แน่ชัด แค่เขียนสคริปต์ให้ดาวน์โหลดรายการช่วง IP ของ Amazon เป็นระยะ ๆ แล้วบล็อกทั้งหมด จากนั้นก็ปล่อยผ่านไป

  • เข้าใจได้ ถ้าผมอยากกั้นพื้นที่ใหญ่ ๆ ของอินเทอร์เน็ตออกจากสิ่งที่ผมสร้าง ผมก็คงทำแบบเดียวกัน มันไม่ได้ต่างจากการบล็อกทั้งประเทศมากนัก
    เข้าใจความต้องการที่จะลดเสียงรบกวนและอนุญาตให้มีแค่ “กลุ่มเพื่อนเล็ก ๆ” ได้เช่นกัน
    แต่ผมทำแบบนั้นเฉพาะกับบางบริการ ไม่ใช่ทั้งโดเมน เซิร์ฟเวอร์ Mumble เปิดให้เฉพาะ 3–4 ประเทศที่มีเพื่อนอยู่ และไม่รวมผู้ให้บริการคลาวด์ ส่วนบล็อกเทคนิคเปิดให้คนทั่วโลกดูได้
    ผมยืนอยู่ฝั่งที่เชื่อมั่นว่า ความรู้ที่แบ่งปันกัน เป็นประโยชน์ต่อทุกคน ถ้าบันทึกของผมเกี่ยวกับสตริงเริ่มต้นโมเด็มของโมเด็ม C64 ความเร็ว 300 บอดช่วยใครได้แม้เพียงคนเดียว คนคนนั้นก็จะไม่ต้องเจ็บปวดซ้ำแบบที่ผมเคยเจอ และโลกก็จะดีขึ้นเล็กน้อย
    เข้าใจว่าความต้องการแบบนั้นเกิดขึ้นได้จากหลายเหตุผล ไม่เป็นไร ต่างคนต่างจัดการกันเองก็แล้วกัน

    • Zen InterSLIP Dialing Script ที่ผมเขียน เดินทางไปทั่วโลกตามตัวอักษรเลย
      Amazon ใหญ่เกินกว่าจะเพิกเฉยได้ เข้าใจว่าในทราฟฟิก ICMP และ SYN มีขยะอยู่มาก ผมเองก็อยากช่วยบล็อก และที่จริงก็มีมาตรการบรรเทาเตรียมไว้เป็นพื้นฐานอยู่แล้ว
      ปัญหาคือ Amazon เข้ามากระทบมาตรการบรรเทาของผม “ในระดับขนาดใหญ่” จึงกลายเป็นเรื่องน่าปวดหัว Amazon ไม่ได้ช่วยแยกแกลบออกจากข้าวสารเลย เป็นแนวว่า “ส่ง PCAP มาให้เรื่องปัญหา ping”
      ถ้าส่งข้อมูลให้ Amazon แล้วไม่ได้ยินคำตอบใด ๆ ก็ไม่มีอะไรให้เรียนรู้ ผมไม่ต้องการทั้งทราฟฟิกดี ทราฟฟิกไม่ดี หรือทราฟฟิกปลอมแปลงที่โจมตีพวกเขา
      ถ้าพวกเขาไม่มีความคิดจะช่วยให้ผมช่วยพวกเขาได้ ผมก็ไม่ต้องการทั้งหมด แค่รักษาชีวิตตัวเองให้เรียบง่ายอยู่เท่านั้น

  • เห็นเรื่องแบบนี้แล้วก็คิดถึง อินเทอร์เน็ต สมัยก่อน อธิบายได้ยากจริง ๆ ว่าอินเทอร์เน็ตก่อนยุคการค้าจะยอดเยี่ยมแค่ไหน
    ความสุขขม ๆ ที่ได้บอกว่าเราทายถูกเป๊ะว่าผลลัพธ์จะออกมาแบบนี้ ไม่ได้เป็นการชดเชยสิ่งที่สูญเสียไปเลยแม้แต่น้อย

    • อ้อ ใช่สิ แค่คำพูดเพ้อเจ้อด้วยความคิดถึงอดีตนั่นแหละ อินเทอร์เน็ตเป็นเรื่องเงินมาตั้งแต่แรกแล้ว

  • AWS นี่ถือว่าอยู่ในระดับลูกเสือเมื่อเทียบกับ DigitalOcean, OVHcloud, ColoCrossing, Scaleway, Tencent หรือแม้แต่ Google
    โดยเฉพาะ DigitalOcean ผมคิดว่าการไปทำการตลาดกับชุมชน “ไซเบอร์ซีเคียวริตี้” เป็นความผิดพลาดที่เลวร้ายมาก

    • จริง ๆ ถ้าอ่านบทความจะเห็นว่าเขียนไว้ว่า “ได้บล็อกผู้ให้บริการโฮสติ้งรายเล็กบางรายเพื่อเป็น proof of concept” ซึ่งนั่นก็คือ DigitalOcean นั่นเอง ด้วยเหตุผลที่คุณพูดถึง

  • ขอเปิดเผยผลประโยชน์ทับซ้อน: ปัจจุบัน AWS เป็นนายจ้างของผม
    ผมอาจพลาดอะไรที่ชัดเจนไปก็ได้ แต่ถ้าผู้เขียนเชื่อว่าทราฟฟิก ping ถูกสปูฟ แล้วจะรู้ได้อย่างไรว่า AWS เป็นแหล่งที่มา?

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