วิธีทำให้ทั้งโลกส่งรายงานการใช้งานในทางที่ผิดไปหาเพื่อนซี้ของคุณ

บทนำ

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

จุดเริ่มต้นของเหตุการณ์

• ผู้เขียนได้รับอีเมลจาก Hetzner ว่ามีรายงานการใช้งานในทางที่ผิดเกี่ยวกับที่อยู่ IP ของตน
• พบความพยายามเชื่อมต่อ SSH ที่ผิดปกติบนเซิร์ฟเวอร์ แต่ความจริงแล้วไม่ใช่การเชื่อมต่อออกจากเซิร์ฟเวอร์ไปภายนอก หากเป็นแพ็กเก็ต TCP reset ที่ถูกส่งจากภายนอกเข้ามายังเซิร์ฟเวอร์

IP spoofing

• บนอินเทอร์เน็ต IP spoofing คือการส่งแพ็กเก็ตโดยปลอมแปลงที่อยู่ IP ต้นทาง
• BCP38 แนะนำให้อนุญาตเฉพาะที่อยู่ IP ที่คาดหมายได้เมื่อมีการส่งต่อแพ็กเก็ต IP ระหว่างเครือข่าย แต่ไม่ใช่ทุกเครือข่ายที่จะปฏิบัติตาม

การคาดเดาแรงจูงใจ

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

ความเชื่อมโยงกับ Tor

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

บทสรุป

• อินเทอร์เน็ตมีปัญหามาตั้งแต่ 25 ปีก่อน และทุกวันนี้ก็ยังมีปัญหาอยู่
• IP spoofing ยังคงเป็นปัญหา และกฎด้านความปลอดภัยอย่าง BCP38 ก็ยังไม่ได้ถูกบังคับใช้อย่างเหมาะสม
• หากคุณได้รับรายงานการใช้งานในทางที่ผิดลักษณะนี้ คุณจะได้รู้วิธีอธิบายกับผู้ให้บริการโฮสติ้งว่าเซิร์ฟเวอร์ของคุณเป็นฝ่ายถูกกระทำ

# สรุปโดย GN⁺

• บทความนี้กล่าวถึงปัญหาด้านความปลอดภัยที่เกี่ยวข้องกับ IP spoofing พร้อมอธิบายความเชื่อมโยงกับเครือข่าย Tor
• เน้นย้ำความสำคัญของความปลอดภัยบนอินเทอร์เน็ตและความจำเป็นของ BCP38
• โครงการที่มีฟังก์ชันคล้ายกันอาจแนะนำได้เป็นเครื่องมือด้านความปลอดภัยเครือข่ายหลากหลายประเภท

[GN⁺]

ความคิดเห็นจาก Hacker News

• ปัญหา IP spoofing แก้ได้ยาก เพราะทั้งผู้ไม่หวังดีและผู้ใช้ที่บริสุทธิ์ต่างก็ใช้ข้ออ้างเดียวกันได้

  • อินเทอร์เน็ตมีปัญหานี้มาตั้งแต่ 25 ปีก่อน และจนถึงตอนนี้ก็ยังไม่ถูกแก้ไข
  • ปัญหาที่อยู่ IP ถูก spoof ยังคงมีอยู่แม้ในปี 2024 และชุมชนอินเทอร์เน็ตก็ยังไม่บังคับใช้กฎความปลอดภัยเพื่อแก้ปัญหานี้

• ในอดีตเคยตั้งค่ากฎไฟร์วอลล์พื้นฐานไว้ แต่ก็ยังเกิดปัญหาจากแพ็กเก็ตที่ถูก spoof

  • ได้รับแพ็กเก็ตที่ spoof มาจาก IP บางตัว จึงต้องปรับกฎไฟร์วอลล์เพื่อรับมือ
  • การมีหลาย IP address เป็นสิ่งสำคัญ และถ้า ISP ทำ source-based filtering ก็จะย้ายไปใช้ ISP เจ้าอื่น

• หากหา transit provider ที่ไม่ทำ BCP38 filtering ได้ ก็สามารถส่งแพ็กเก็ตโดยใช้ source IP อะไรก็ได้ตามต้องการ

  • ต้นกำเนิดของ BCP38 ย้อนไปถึงปี 1998 แต่ก็ยังมี network provider ที่ไม่ได้นำไปใช้
  • เพื่อป้องกันการ spoofing จำเป็นต้องปฏิเสธทราฟฟิกจากทุก AS ที่ไม่ทำ BCP38

• ทฤษฎีของใครก็ตามที่ไม่ชอบ Tor relay ดูเหมือนไม่มีคุณค่าอะไร

  • อาจเป็นความพยายามที่จะเดินระบบ relay ที่เป็นอันตราย พร้อมกับกำจัด relay ที่ถูกต้องตามกฎหมายออกไป

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

  • ความแตกต่างคือเป็นการร้องเรียนผ่านบุคคลที่ไม่เกี่ยวข้อง

• ในอดีตเคยสแกนหา DrDoS reflector และผู้ให้บริการคลาวด์ก็ได้รับคำร้องเรียนจำนวนมาก

  • เซิร์ฟเวอร์ที่ส่งแพ็กเก็ตสแกนแบบ spoof จะไม่ถูกตรวจพบ และสามารถสแกนอินเทอร์เน็ตซ้ำ ๆ ได้
  • การติดตามต้นทางของแพ็กเก็ตที่ถูก spoof นั้นทำได้ แต่ต้องอาศัยความร่วมมือจาก transit provider

• ระบบไม่ควรรายงานการใช้งานในทางที่ผิดโดยอัตโนมัติจากเพียงแพ็กเก็ตเดียว และควรรายงานเฉพาะเมื่อเป็นทราฟฟิกระดับปฏิเสธการให้บริการเท่านั้น

  • สำหรับ SSH จะยังไม่ถือเป็นความพยายามเชื่อมต่อที่ใช้ได้จริง จนกว่าจะเกิดการ handshake

• IP spoofing เป็นปัญหาคล้ายกับ swatting, patent trolling และการใส่ร้ายคนบริสุทธิ์

  • เป็นการใช้กลไกป้องกันการละเมิดเป็นอาวุธเพื่อโจมตีเป้าหมายที่ตนไม่ชอบ
  • หน่วยงานต่าง ๆ อาจกลายเป็นจุดอ่อนและถูกผู้ไม่หวังดีนำไปใช้เป็นอาวุธได้

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

  • honeypot อาจไม่ส่งอีเมลร้องเรียนการละเมิด หรือผู้ให้บริการอาจกรองสิ่งเหล่านี้ได้