การโจมตีแบบ IP Spoofing ที่ทำให้คนทั่วโลกส่งรายงานการละเมิดไปหาเพื่อนของคุณ

 (delroth.net)
1 คะแนน โดย GN⁺ 2024-10-30 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Hetzner ส่งต่อ รายงานการละเมิด ว่ามีการสแกนพอร์ต SSH จาก 195.201.9.37 แต่ภายในเซิร์ฟเวอร์ไม่พบหลักฐานของโปรเซสอันตราย การเปลี่ยนแปลงไฟล์ หรือทราฟฟิกผิดปกติ
  • จากการตรวจสอบโฟลว์จริงด้วย tcpdump พบว่าไม่ใช่เซิร์ฟเวอร์เชื่อมต่อออกไปยัง 22/tcp ภายนอก แต่ใกล้เคียงกับ backscatter ที่โฮสต์อินเทอร์เน็ตหลายแห่งส่ง TCP RST กลับมายังเซิร์ฟเวอร์
  • สาเหตุหลักคือสามารถส่งแพ็กเก็ตที่ใส่ IP ต้นทางตามใจได้ผ่านเครือข่ายที่ไม่ทำการกรองแบบ BCP38 และใน TCP, QUIC, TLS ที่ต้องมีการตอบกลับไปมา ผู้โจมตีจะไม่เห็นการตอบกลับโดยตรง
  • รูปแบบเดียวกันนี้ปรากฏใน Tor relay อีก 2 ตัวของผู้เขียนด้วย และในเมลลิงลิสต์ tor-relays กับ issue ของ Tor Project ก็มีรายงานปรากฏการณ์คล้ายกันมาตั้งแต่หลายวันก่อน รวมถึงมีกรณีที่บางโหนดล่มชั่วคราว
  • ผู้โจมตีสามารถปลอม IP ของเหยื่อเป็นต้นทาง แล้วส่งความพยายามเชื่อมต่อไปยังเป้าหมาย SSH หลายแห่ง เพื่อกระตุ้นรายงานการละเมิดอัตโนมัติ รายการบล็อก และการดำเนินการจากผู้ให้บริการโฮสติ้งได้

รายงานการละเมิดจาก Hetzner และการตรวจสอบเซิร์ฟเวอร์

  • Hetzner ส่งอีเมล AbuseInfo สำหรับ IP 195.201.9.37
    • ผู้แจ้งคือ abuse@watchdogcyberdefense.com
    • ในล็อกมีรายการ DENIED ที่มุ่งไปยัง 22/tcp ของปลายทาง 202.91.16x.x หลายรายการ
  • เมื่อมองภายนอก ดูเหมือนว่าเซิร์ฟเวอร์เริ่มส่งการเชื่อมต่อ SSH ออกไปยังอินเทอร์เน็ต ซึ่งโดยทั่วไปเป็นสถานการณ์ที่น่าสงสัยว่าอาจมี มัลแวร์ติดเครื่อง
  • ตรวจสอบอยู่ 1–2 ชั่วโมง แต่สถานะเซิร์ฟเวอร์ดูใกล้เคียงปกติ
    • ไม่มีโปรเซสผิดปกติ
    • ไม่มีการเปลี่ยนแปลงไฟล์ซิสเต็ม
    • ไม่มีทราฟฟิกเครือข่ายผิดปกติเมื่อมองจากฝั่งไฮเปอร์ไวเซอร์
  • เซิร์ฟเวอร์ดังกล่าวรันบริการแบบกระจายและแบบ federated หลายตัว
    • Syncthing relay
    • Mastodon instance
    • Tor relay
    • Matrix homeserver
  • Tor relay มีการเชื่อมต่อไปยัง relay บางตัวที่ใช้ 22/tcp แต่ไม่ตรงกับเครือข่ายในรายงาน และในล็อกของ Matrix/Mastodon รวมถึงคิว Mastodon Sidekiq ก็ไม่พบร่องรอยคำขอไปยัง IP หรือพอร์ตแบบสุ่ม

โฟลว์แพ็กเก็ตจริงที่ tcpdump แสดงให้เห็น

  • ตอนแรกพยายามตรวจสอบทราฟฟิกที่ออกจากเซิร์ฟเวอร์ไปยัง 22/tcp ภายนอกด้วยฟิลเตอร์ dst port 22
  • เมื่อเปลี่ยนฟิลเตอร์เป็น not src host 195.201.9.37 ก็เห็นแพ็กเก็ต TCP RST ที่เข้ามาจาก 22/tcp ของ IP ภายนอกหลายแห่งมายังพอร์ตชั่วคราวของเซิร์ฟเวอร์ผู้เขียน
  • ในความเป็นจริง ไม่ใช่เซิร์ฟเวอร์ส่งการเชื่อมต่อไปยัง 22/tcp ของโฮสต์สุ่ม แต่เป็นลักษณะที่โฮสต์อินเทอร์เน็ตสุ่มส่งแพ็กเก็ต reset มายังเซิร์ฟเวอร์
  • รูปแบบนี้ตรงกับ backscatter ที่แพ็กเก็ตตอบกลับย้อนมายัง IP ที่ถูกปลอม เนื่องจาก การปลอม IP ต้นทาง

การปลอม IP ต้นทางและช่องโหว่ของ BCP38

  • บนอินเทอร์เน็ต IP ปลายทางต้องถูกต้อง แต่การส่งแพ็กเก็ตที่ตั้งค่า IP ต้นทางเป็นของปลอมไปยังหลายปลายทางยังทำได้
  • BCP38 คือแนวปฏิบัติที่ถือว่าเป็น best practice ในปัจจุบัน ซึ่งระบุให้อนุญาตเฉพาะ IP address ที่คาดว่าเครือข่ายคู่เชื่อมต่อจะใช้เป็นต้นทางเท่านั้น
  • การกรองนี้ต้องถูกนำไปใช้ตั้งแต่ช่วงต้นของเส้นทางแพ็กเก็ตจึงจะได้ผล
    • ในระดับ transit provider รายใหญ่ การกรองอย่างมีความหมายทำได้ยาก เพราะ peer คาดหวังให้ provider ดังกล่าวส่งต่อทราฟฟิกทั้งอินเทอร์เน็ตให้
  • แค่พบ transit provider ที่ไม่ได้ใช้ BCP38 เพียงรายเดียว ก็สามารถส่งแพ็กเก็ตที่ใส่ IP ต้นทางตามใจได้แล้ว
  • APNIC เผยแพร่ บทความ ในปี 2023 ว่าทำไมการตรวจสอบความถูกต้องของที่อยู่ต้นทางยังคงเป็นปัญหา
  • กลุ่ม TCP, QUIC, TLS ต้องมีการสื่อสารแบบไปกลับ ดังนั้นหากปลอม IP ต้นทาง ผู้โจมตีจะไม่เห็นการตอบกลับ
    • ไม่เหมาะกับการตรวจสอบผลของการสแกนพอร์ตทั่วไป
    • มีรูปแบบการใช้ในทางที่ผิดที่เป็นที่รู้จักอยู่แล้ว เช่น reflected DDoS

ทำไมการ spoofing แบบนี้จึงสร้างความเสียหายได้

  • โฟลว์ที่เป็นไปได้มากที่สุดคือมีใครบางคนใช้ IP ของผู้เขียนเป็น IP ต้นทาง แล้วส่งความพยายามเชื่อมต่อไปยัง 22/tcp ของโฮสต์อินเทอร์เน็ตหลายแห่ง
  • หากเป้าหมายคือการค้นหาพอร์ตเปิดแบบทั่วไป จะไม่สมเหตุสมผล เพราะผู้ปลอมจะไม่เห็นการตอบกลับ
  • ในอดีตเคยมีเทคนิคชื่อ Idle Scanning แต่ต้องพึ่งพาเซิร์ฟเวอร์ที่ไม่ค่อยยุ่งและตัวนับใน network stack ที่คาดเดาได้ และแทบไม่ใช้งานได้จริงมาตั้งแต่หลายสิบปีก่อน
  • ปริมาณทราฟฟิกต่ำเกินไปและระยะเวลายาวเกินไป ทำให้คำอธิบายว่าใส่ IP ต้นทางผิดในการตั้งค่าสแกนเนอร์ดูไม่น่าเชื่อเท่าไร
  • ความเสียหายจริงเกิดจาก ระบบอัตโนมัติในการรายงานการละเมิด
    • ความพยายามเชื่อมต่อที่ถูก spoof ไปถึงเครือข่ายที่มี honeypot หรือระบบตรวจจับการบุกรุก
    • บางระบบส่งรายงานการละเมิดโดยอัตโนมัติ
    • ผู้ให้บริการโฮสติ้งอาจเข้าใจผิดว่าเซิร์ฟเวอร์ของเหยื่อถูกเจาะหรือเป็นอันตราย

รูปแบบที่เกิดซ้ำใน Tor relay อื่น

  • ผู้เขียนยืนยันอีกครั้งว่าเซิร์ฟเวอร์ของตนทำงานเป็น Tor relay
  • Tor relay เป็นโหนดภายในเครือข่าย Tor และหากไม่ใช่ exit node ก็จะไม่สื่อสารโดยตรงกับอินเทอร์เน็ตสาธารณะ
    • relay ส่งต่อทราฟฟิกนิรนามที่เข้ารหัสระหว่างโหนดที่เข้าร่วมเครือข่าย Tor
    • relay บางตัวทำหน้าที่เป็น Guard Node และเป็นจุดเข้าสู่เครือข่าย Tor ได้
  • ผู้เขียนรัน tcpdump บน relay เพิ่มอีก 2 ตัวที่อยู่คนละประเทศและคนละ ISP
    • relay บนสายอินเทอร์เน็ตบ้าน
    • relay บน Linode VPS ในญี่ปุ่น
  • relay ทั้งสองตัวก็พบ รูปแบบ TCP response ที่ถูก spoof แบบเดียวกันจาก 22/tcp ภายนอกมายัง IP ของ relay
  • ผู้เขียนส่งอีเมลไปยัง เมลลิงลิสต์ tor-relays และมี issue ของ Tor Project ที่วิเคราะห์ปรากฏการณ์เดียวกันอยู่ก่อนแล้วตั้งแต่หลายวันก่อน
  • การโจมตีแบบ spoofing นี้เริ่มจากโหนดประเภทอื่นก่อน relay และมีกรณีที่การเชื่อมต่อปลอมในขนาดใหญ่ขึ้นทำให้บางโหนดล่มชั่วคราว

โฟลว์การโจมตีที่ใครก็อาจตกเป็นเป้าได้

  • โฟลว์การโจมตีที่เป็นไปได้มีดังนี้
    • ผู้โจมตีเข้าถึง เครือข่ายที่ไม่มีการกรอง BCP38
    • ส่งคำขอเชื่อมต่อ TCP ไปยัง 22/tcp ของโฮสต์อินเทอร์เน็ตแบบสุ่มจำนวนมาก
    • ปลอม IP ต้นทางเป็น IP ของเหยื่อ
    • โฮสต์ปลายทางหรือระบบความปลอดภัยมองว่าเหยื่อพยายามเชื่อมต่อ และส่งรายงานการละเมิด
    • หากมีปริมาณมากพอ IP ของเหยื่ออาจถูกเพิ่มในหลายรายการบล็อก และผู้ให้บริการโฮสติ้งอาจระงับเซิร์ฟเวอร์
  • การโจมตีนี้ไม่มีองค์ประกอบที่เฉพาะเจาะจงกับ Tor
  • วิธีนี้ดูไม่ได้ยากเป็นพิเศษสำหรับผู้โจมตีคนเดียวที่มีแรงจูงใจ
  • เหยื่อไม่ใช่ผู้โจมตีจริง แต่เป็นเจ้าของ IP ต้นทางที่ถูกปลอม ทว่าอาจได้รับความเสียหายด้านการปฏิบัติการจากรายงานการละเมิดอัตโนมัติและการตอบสนองของผู้ให้บริการโฮสติ้ง

ปัญหาด้านการดำเนินงานของอินเทอร์เน็ตที่ยังคงอยู่ในปี 2024

  • การที่ IP ต้นทางปลอม ยังเป็นปัญหาในปี 2024 นั้นแทบจะเป็นความล้มเหลวด้านการดำเนินงานของอินเทอร์เน็ต
  • ไม่ใช่แค่ BCP38 เท่านั้น RPKI ก็ประสบปัญหาคล้ายกันในด้านการนำไปใช้ และเพิ่งเริ่มขยายตัวเมื่อบริษัทอินเทอร์เน็ตรายใหญ่เริ่มบังคับข้อกำหนดกับ peer โดยตรง
  • ขั้นตอนถัดไปสำหรับการโจมตีนี้ยังไม่ชัดเจน
    • มันกำลังเกิดขึ้นจริงแล้ว
    • ผู้เขียนไม่ทราบว่าเป็นการโจมตีที่เคยมีการบันทึกไว้แล้วหรือไม่
    • ผู้เขียนไม่ทราบวิธีติดตามแหล่งที่มาจริงของแพ็กเก็ต IP ปลอมย้อนหลัง
  • ผู้ดูแลระบบที่ได้รับรายงานการละเมิดคล้ายกันควรตรวจสอบว่าเซิร์ฟเวอร์อาจเป็นเหยื่อ ไม่ใช่ผู้ก่อเหตุ และควรรวบรวมหลักฐานสำหรับอธิบายต่อผู้ให้บริการโฮสติ้ง

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

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

 
GN⁺ 2024-10-30
ความคิดเห็นจาก Hacker News

  • ปัญหาประเภทนี้จัดการได้น่ารำคาญจริง ๆ เพราะคำตอบที่ถูกต้องต่อรายงานการละเมิดอย่าง “มีคน spoof IP ของผม ไม่ใช่ผม และอุปกรณ์ของผมก็ไม่ได้ถูกเจาะ” นั้น เหมือนกับข้ออ้างที่ผู้ไม่หวังดีจะยกมาแบบเป๊ะ ๆ
    สุดท้ายก็ต้อง พิสูจน์ความไม่อยู่ ณ ที่เกิดเหตุ ให้ฝ่ายตรงข้ามที่แทบไม่ได้สนใจอะไรเหมือนในบทความ ซึ่งในทางปฏิบัติแทบเป็นไปไม่ได้

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

  • MAC address, อีเมลแอดเดรส, ข้อความ ARP, Neighbor Discovery และใบรับรอง TLS ของคนกลางที่ถูก spoof ก็เหมือนกัน
    น่าทึ่งด้วยซ้ำที่ยังมีอะไรทำงานได้อยู่

    • อินเทอร์เน็ตไม่ได้พัง แต่มี ประโยชน์ใช้สอยและความน่าเชื่อถือ สูงมาก
      ถ้าทำให้มันถูกออกแบบและดำเนินการอย่างสมบูรณ์แบบ มันอาจพังหนักค่อนข้างบ่อยกว่าเดิมด้วยซ้ำ คุณสมบัติที่ทนต่อความไม่สมบูรณ์เล็ก ๆ น้อย ๆ มีส่วนอย่างมากต่อความแข็งแกร่งและประโยชน์ใช้สอยของอินเทอร์เน็ต
      ไม่ได้หมายความว่าไม่ควรปรับปรุง แต่เป็นคำเตือนมากกว่าว่าถ้าไล่ตาม ความสมบูรณ์แบบนิยม ก็มีโอกาสทำผิดพลาดครั้งใหญ่จนทำให้ทุกอย่างพังได้ง่าย
    • MAC address ที่ spoof ได้ค่อนข้างจำเป็นต่อ ความเป็นส่วนตัว ของ Wi‑Fi
    • ในเครือข่ายมือถือ SS7 ก็มีปัญหาคล้ายกัน: https://youtu.be/wVyu7NB7W6Y
    • เริ่มรู้สึกว่าข้อเสนอของจีนที่อยากปฏิรูปโปรโตคอลอินเทอร์เน็ตอาจมีเหตุผลอยู่เหมือนกัน
    • ได้ยินคนบ่นเรื่อง DNS บ่อย ๆ เลยสงสัยว่าจริง ๆ แล้วมันปลอดภัยแค่ไหน และทำไมความพยายามจะแก้ไขมันถึงมีน้อย

  • เมื่อก่อนเราเคยสแกน เซิร์ฟเวอร์สะท้อน DrDoS ด้วยวิธีคล้ายกัน บริษัทโฮสติ้งไม่มีใครอยากรับรายงาน port scan ดังนั้นถ้าตั้งที่อยู่ต้นทางของการสแกนเป็น IP ของผู้ให้บริการคลาวด์ที่บริสุทธิ์และมีชื่อเสียงดี เซิร์ฟเวอร์สะท้อนก็จะส่ง UDP response ไปทางนั้นอย่างดี
    บริษัทคลาวด์ย่อมได้รับรายงานมหาศาล แต่ถ้าบอกว่าจากเซิร์ฟเวอร์ของผมไม่ได้สแกน ผู้ให้บริการก็จะตรวจสอบและไม่ปิดบริการ เซิร์ฟเวอร์ที่ส่งแพ็กเก็ตสแกนแบบ spoof จะไม่ถูกตรวจพบ จึงสามารถสแกนทั้งอินเทอร์เน็ตซ้ำ ๆ ได้โดยไม่ต้องเจอปัญหารายงานการละเมิดตามปกติ
    ไม่รู้ว่าในความเป็นจริงเกิดขึ้นบ่อยแค่ไหน แต่ถ้าร่วมมือกับผู้ให้บริการขนส่งข้อมูลแล้วไล่ย้อนกลับไปตาม hop ก็สามารถตามหาต้นทางของแพ็กเก็ต spoof ได้ ครั้งหนึ่ง JPMorgan เคยร่วมมือกับ Cogent แล้วมาแจ้งว่าอย่าส่งแพ็กเก็ตไปยัง IP address ของพวกเขา อนึ่ง Cogent นับว่าเป็นหนึ่งในผู้ให้บริการ Tier 1 ของอินเทอร์เน็ตที่ค่อนข้างผ่อนปรนกับการ spoof
    เพิ่งเคยได้ยินว่าวิธีนี้ถูกใช้เจาะจงกับ Tor และมันค่อนข้างขัดกับสัญชาตญาณ เพราะถ้าเป็นฝ่ายที่ส่งแพ็กเก็ต spoof ก็น่าจะเป็นผู้สนับสนุน Tor มากกว่า เป็นไปได้สูงว่าเป็นแค่โทรลล์ และโชคดีที่ผู้ให้บริการที่โฮสต์ Tor คงไม่ใส่ใจกับเรื่องแบบนี้มากนัก

    • Cogent โดยรวมก็ดูไม่ค่อยดีอยู่แล้ว
      อาจเป็นแค่โทรลล์ก็ได้ แต่ก็อาจเป็นฝ่ายที่อยากทำให้ Tor ถูกมองเหมือน กากกัมมันตรังสี เพราะมันขัดขวางงานเฝ้าระวัง

  • เรื่องนี้ไม่ใช่เรื่องใหม่ หลายปีก่อนผมเคยสร้างกฎไฟร์วอลล์พื้นฐานมาก ๆ โดยถ้าเป็นแพ็กเก็ต TCP ขาเข้าที่มีพอร์ตปลายทาง 22 และ SYN=1, ACK=0 ก็จะบล็อก IP ต้นทางเป็นเวลาหนึ่งวัน
    แต่แล้วก็มีคนบ่นว่าเข้าเว็บและบริการบางอย่างไม่ได้ ปรากฏว่าทุก ๆ สองสามวันจะมีแพ็กเก็ตแบบนั้นมาจาก IP ของเซิร์ฟเวอร์ยอดนิยมอย่าง 8.8.8.8, 1.1.1.1, Steam, Roblox, Microsoft, Facebook, Instagram และบริการแชตต่าง ๆ แน่นอนว่าทั้งหมดเป็น แพ็กเก็ต spoof สุดท้ายเลยต้องเพิ่มการตรวจสอบให้กฎไฟร์วอลล์อีกเล็กน้อย
    ดังนั้นผมค่อนข้างมั่นใจว่านี่เป็นเรื่องที่พบได้บ่อย ส่วนตัวรู้ว่าผมเป็นกรณีพิเศษที่ใช้งานหลาย IP address แต่ผมต้องการความยืดหยุ่นที่จะใช้ที่อยู่ต้นทางใดก็ได้ของตัวเองเพื่อส่งแพ็กเก็ตผ่าน ISP ใดก็ได้ นี่สำคัญสำหรับผม และถ้า ISP กรองตามต้นทางก็เป็นเหตุผลพอให้เลิกทำธุรกิจกัน แล้วผมจะย้ายไป ISP อื่น

    • ถ้าคุณมี IP address ของตัวเองจริง ๆ นั่นคือพฤติกรรมปกติและเป็นสิ่งที่คาดหวังได้ แต่ถ้าคุณสามารถใช้ IP address ของ ISP A ผ่าน ISP B หรือกลับกันได้ นั่นเป็น บั๊ก เสมอ และไม่ควรใช้งานแบบนั้น
      กรณีหลังจัดอยู่ในแนวเดียวกับ “เปิดฮีตเตอร์สเปซบาร์กลับมาอีกครั้ง” มากกว่า และหวังว่า ISP ทั้งหลายจะแก้เครือข่ายที่พังของตัวเอง
    • ขอเล่าตัวอย่างจริงที่เป็นรูปธรรม
      บริษัทแห่งหนึ่งโฮสต์เว็บแอสเซ็ตบางส่วนไว้ที่สาขาแบบ on-premises และที่นั่นมีลิงก์ 1Gbps ที่สำนักงานใหญ่มีลิงก์ 10G หลายเส้นและดาต้าเซ็นเตอร์ที่ค่อนข้างดี จึงย้ายเว็บ VM ไปที่สำนักงานใหญ่ แต่ยังคง IP address ที่ได้รับจัดสรรไว้ นั่นคือ public static IP ของ ISP-A เอาไว้ โดย route ผ่าน VPN ไปยังสำนักงานใหญ่ และเซิร์ฟเวอร์ส่ง response ที่มี IP ต้นทางของ ISP-A ออกทางลิงก์ 10G ของ ISP-B ผ่าน default gateway
      วิธีนี้ทำให้แม้ขาเข้าจะถูกจำกัดที่ 1G แต่ขาออกก็ใช้ 10G ได้ ยังไงก็มีแต่ GET request อยู่แล้ว ไม่ใช่การตั้งค่าที่เหมาะที่สุด และสุดท้ายก็เปลี่ยน IP แต่ดูเป็นกรณีใช้งานที่สมเหตุสมผล
      ตัวอย่างที่สอง มีลิงก์จาก ISP สองรายต่างกัน พร้อม ASN ของตัวเองและช่วง /23 ของตัวเอง ต้องการทำ load balancing ทราฟฟิกบางส่วน เลยส่ง IP ครึ่งหนึ่งไปทาง ISP-A และอีกครึ่งไปทาง ISP-B มันทำงานได้ดี แต่พอพยายามผสมสมดุลให้มากขึ้น ก็พบปัญหาน่าสนใจ เราประกาศ /24 แรกไปที่ ISP-A และ /24 ที่สองไปที่ ISP-B แต่ ISP-A มี RP filtering อยู่ เลยต้องประกาศ IP ทั้งหมดไปทางนั้นด้วย
      ด้วยวิธีการทำงานของ RP filter จึงทำอะไรอย่าง prepend ไม่ได้ และทราฟฟิกทั้งหมดต้องเข้ามาทางพวกเขา ถ้าเห็นเส้นทางที่ดีกว่าสำหรับ prefix นั้นก็จะกรองทิ้ง พวกเขาปฏิเสธจะแก้ไขอยู่หลายเดือนโดยอ้างเรื่องความปลอดภัย ในเมื่ออ้างว่าเป็นแนวปฏิบัติที่ดีที่สุดด้านความปลอดภัย ก็น่าจะเปิดชื่อ ISP ได้ นั่นคือ Virgin Media
      อนึ่ง ลิงก์อินเทอร์เน็ตที่มี rp_filter นี้ไม่ใช่เดือนละ 20 ดอลลาร์ แต่เดือนละมากกว่า 5,000 ดอลลาร์ ในพื้นที่นั้นไม่มีทางเลือกอื่นจึงเปลี่ยนไม่ได้ แต่ถ้ามีทางเลือก ก็เห็นชัดว่าใครจะเสียสัญญาไป
    • ในฐานะคนที่ปกติเปิด rp_filter ทุกที่ ผมสงสัยจริง ๆ ว่าทำไมถึงต้องการความยืดหยุ่นแบบนั้น
    • ในเชิงเทคนิค ISP แบบนั้นก็น่าจะอยู่ในสถานะละเมิดเช่นกัน จำเป็นต้องมี ASN ของตัวเอง

  • สมมติฐานที่ว่า “มีใครบางคนเกลียด Tor relay” ดูไม่น่าเชื่อเท่าไรเมื่อเทียบกับความพยายามที่ต้องลงไป
    อาจเป็นไปได้ว่าผู้ที่รัน relay อันตรายกำลังดึง relay ที่ถูกกฎหมายลงอย่างผิดจริยธรรม เพื่อเพิ่มสัดส่วนของเครือข่ายที่ตนควบคุม

    • แทบจะแน่นอนว่าน่าจะเป็นฝั่งนั้น ที่นี่มีการ หลีกหนีความจริง ค่อนข้างมากเกี่ยวกับว่า ผู้โจมตีที่เข้าถึง log ของ node บางส่วนที่ไม่ได้ใหญ่โตนัก จะมองเห็นรูปแบบการเข้าถึงบริการของแต่ละคนได้ง่ายแค่ไหน
    • ถ้าเกลียดเครือข่าย Tor วิธีที่ง่ายกว่าคือถล่ม traffic เข้าไปให้บริการเสื่อมคุณภาพ
      แค่เปิดดาวน์โหลด BitTorrent ไม่กี่รายการก็อาจเพียงพอแล้ว

  • ต้องใช้อะไรบ้างเพื่อให้ผู้ให้บริการเครือข่ายจำนวนมากพอปฏิเสธ traffic จาก AS ทุกแห่งที่ไม่ทำ BCP38 จนทำให้การ spoof ทำไม่ได้อีกต่อไป?

    • แค่ Cloudflare อย่างเดียวก็น่าจะเพียงพอแล้ว
      เพราะควบคุม inbound traffic ได้มากพออยู่แล้ว “กำลังตรวจสอบความปลอดภัยของการเชื่อมต่อ” จึงอาจมีความหมายจริงขึ้นมา
    • ต้องหาวิธีทำให้ผู้ให้บริการเครือข่ายใส่ใจ โดยเฉพาะ ผู้ให้บริการขนส่งระดับ Tier 1 หรือเครือข่ายที่ใหญ่ผิดปกติ
      อย่างไรก็ตาม การลดค่าสัมประสิทธิ์การสะท้อนแบบขยายผลนั้นง่ายกว่ามาก เพราะ IPv4 สามารถสแกนหา reflection vector ได้ และสามารถไปร้องเรียนกับคนที่ตอบกลับเป็น 10 เท่าของจำนวน byte ที่ส่งเข้าไปได้

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

  • สำหรับคำขอที่เป็น packet เดียวและไม่มี round trip ระบบไม่ควรส่งรายงาน abuse โดยอัตโนมัติ เว้นแต่จะเป็น traffic ระดับ denial-of-service
    โดยเฉพาะถ้าเป็น SSH ก่อนที่จะมี handshake ใด ๆ เกิดขึ้น ก็ไม่มีทางถือได้ว่าเป็นความพยายามเชื่อมต่อที่ถูกต้อง

    • ถ้าใครก็ส่งรายงาน abuse ได้ ผู้ให้บริการเซิร์ฟเวอร์ก็ควร ตรวจสอบรายงานจริง ๆ ก่อนจะเริ่มใช้มาตรการตามเงื่อนไขบริการ เช่น “ถ้าไม่ตอบภายใน 2 วันจะระงับเซิร์ฟเวอร์”
      เซิร์ฟเวอร์หลักของผมก็เคยถูกปิดเพราะรายงาน abuse ปลอมเช่นกัน เขาอ้างว่าได้รับการโจมตี DoS เกิน 1Gbps จาก IP ของผม แต่สายของเซิร์ฟเวอร์ผมถูกจำกัดไว้ที่ 400Mbps ถ้ามีคนอ่านรายงานจริง ๆ ก็คงรู้ว่าเป็นไปไม่ได้ และผมคงไม่ต้องเถียงกับฝ่าย support ทางโทรศัพท์อยู่สองวันระหว่างลาพักร้อน
    • แต่ก็มีบางกรณีที่พฤติกรรม abuse ที่ดูเหมือนเกิดขึ้นจริง เช่น port scan มีแค่ packet เดียวนั้นเอง

  • นี่เหมือน swatting เวอร์ชัน IP, การกลั่นแกล้งด้วยสิทธิบัตร, การใส่ร้ายผู้บริสุทธิ์ หรือคำขอ DMCA takedown เพื่อกำจัดคู่แข่ง
    โดยพื้นฐานคือการทำให้กลไกป้องกัน abuse กลายเป็นอาวุธเพื่อโจมตีเป้าหมายที่ไม่ชอบ จุดที่น่าสนใจคือผู้มีอำนาจกลายเป็นจุดอ่อน และอาจถูกใช้เชิงรุกเพื่อบรรลุเป้าหมายของผู้กระทำที่ไร้ศีลธรรมได้ แต่ก็ไม่ใช่ปรากฏการณ์ใหม่โดยสิ้นเชิง

    • ถ้าฉลาดและมี relay ของตัวเองด้วย ยิ่งทำให้ relay อื่นล่มลงได้มากเท่าไร โอกาสที่ relay ของตัวเองจะถูกเลือกก็เพิ่มขึ้นเท่านั้น
      ดูจากกราฟจำนวน relay และ “advertised bandwidth” บน metrics.torproject.org แล้ว ดูเหมือนจะไม่ได้สร้างความแตกต่างมากนัก แต่ก็ยังน่าสนใจอยู่ดี
      สิ่งที่แย่ที่สุดคือพวกที่ทำตัวเหมือนนักข่มขู่อย่าง “Watchdog Cyber Defense”, Spamhaus, Shadowserver หรือ UCEPROTECT สามารถส่งรายงานอัตโนมัติเป็นล้าน ๆ ฉบับได้ และโฮสต์แทบไม่มีทางเลือกนอกจากต้องฟังรายงานเหล่านั้น หากไม่อยากให้ช่วง IP ของตนไปติด blocklist

  • ไม่มี วิธีแก้ในแบนด์เดียวกัน สำหรับปัญหานี้ แต่อาจมีวิธีแก้นอกแบนด์ได้
    เช่น (1) แจ้ง ISP ปลายทางว่ากำลังได้รับ traffic ย้อนกลับ, (2) ISP นั้นตรวจสอบว่า packet มาจากไหนแล้วแจ้ง ISP นั้น, (3) ทำซ้ำขั้นตอนที่ 2 จนกว่าจะพบต้นทาง, (4) แยกเครือข่ายส่วนนั้นออกจนกว่าจะทำงานได้ถูกต้อง
    สุดท้ายแล้ว อินเทอร์เน็ตก็ประกอบขึ้นจากผู้คน

    • บางครั้งก็มีคนแปลกใจเมื่อรู้ว่า เหตุผลที่อินเทอร์เน็ตทั้งระบบทำงานได้ คือมีมนุษย์กลุ่มหนึ่งที่ชอบจัดการ เกมวางท่อ ที่ถูกขยายสเกลเกินจริงที่สุดในโลกอย่างแท้จริง
    • ขั้นตอนที่ 2 และ 3 ต้องอาศัยให้คนจำนวนมาก ทำงานโดยไม่ได้ค่าตอบแทน เพื่อแก้ปัญหาของคนอื่น
    • อ้างอิง: https://news.ycombinator.com/item?id=41985920