เมื่อชื่อโฮสต์ภายในรั่วไหลไปยังคลาวด์

 (rachelbythebay.com)
1 คะแนน โดย GN⁺ 2026-02-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • พบกรณีที่เว็บอินเทอร์เฟซของอุปกรณ์ NAS ภายในบ้าน ส่งชื่อโฮสต์ที่ใช้ภายในเท่านั้นออกไปยังบริการภายนอก
  • สคริปต์รายงานข้อผิดพลาดของ sentry.io ที่รวมอยู่ในเว็บ UI ของ NAS ส่งชื่อโฮสต์ภายในออกไปพร้อมกับสแต็กเทรซ
  • สังเกตพฤติกรรมแปลกที่ฝั่ง sentry.io พยายามเชื่อมต่อ TLS ย้อนกลับ ไปยังชื่อโฮสต์ดังกล่าว แต่ไม่ได้ส่งคำขอจริง
  • ด้วยการตั้งค่าไวลด์การ์ด DNS ไว้ล่วงหน้า จึงสามารถ ตรวจจับการรั่วไหล ได้ และหากใช้ชื่อโฮสต์ที่มีข้อมูลอ่อนไหวก็มีความเสี่ยงต่อการเปิดเผยข้อมูลอย่างร้ายแรง
  • หากนำกลไกนี้ไปใช้ในทางที่ผิด อาจกลายเป็นปัญหาความปลอดภัยที่สามารถ ชักนำให้สแกน DNS ไปยังโฮสต์ตามอำเภอใจ ได้

การติดตั้ง NAS และการตั้งค่าชื่อโฮสต์ภายใน

  • ซื้ออุปกรณ์ NAS มา ติดตั้งไดรฟ์ และเชื่อมต่อเข้ากับเครือข่ายในบ้าน โดยใช้งานในโหมด HTTPS
  • ติดตั้ง ใบรับรอง TLS แบบไวลด์การ์ด สำหรับซับโซนย่อยของโดเมนที่ไม่มีความหมายบนอินเทอร์เน็ตสาธารณะ (เช่น *.nothing-special.whatever.example.com)
  • เพิ่ม รายการเฉพาะในเครื่อง เช่น 172.16.12.34 nas.nothing-special.whatever.example.com ลงในไฟล์ /etc/hosts เพื่อเข้าถึงจากเบราว์เซอร์

การค้นพบการเข้าถึงจากภายนอกที่ไม่คาดคิด

  • ไม่กี่วันหลังติดตั้ง NAS ก็เริ่มมี คำขอจากภายนอก ("outside world") เข้ามายังชื่อโฮสต์เดียวกัน
  • ชื่อโฮสต์ดังกล่าวเป็น ชื่อที่ใช้ภายในเท่านั้นโดยสมบูรณ์ และมีอยู่แค่ในไฟล์ /etc/hosts ของแล็ปท็อป
  • เนื่องจากได้ตั้งค่า รายการ DNS แบบไวลด์การ์ด สำหรับ *.nothing-special.whatever.example.com ทั้งหมดให้ชี้ไปยังเครื่องที่ตนเองดูแลไว้ล่วงหน้า จึงสามารถตรวจจับการรั่วไหลได้
  • ทุกครั้งที่โหลด NAS จะมี โฮสต์ GCP พยายามเชื่อมต่อโดยนำเสนอชื่อโฮสต์ภายในนั้นเป็น SNI

สาเหตุของการรั่วไหล: การรายงานข้อผิดพลาดของ sentry.io

  • เว็บอินเทอร์เฟซของ NAS มี ฟังก์ชัน phone home รวมอยู่ และส่วนหนึ่งของมันคือการส่งสแต็กเทรซไปยัง sentry.io
  • เมื่อเบราว์เซอร์ทำคอลแบ็กไปยัง sentry.io ก็จะ ส่งชื่อโฮสต์ ที่ใช้กับอุปกรณ์จัดเก็บข้อมูลภายในไปด้วย
  • ยืนยันได้ว่าฝั่ง sentry.io สร้างการเชื่อมต่อ TLS ย้อนกลับ ไปยังชื่อโฮสต์นั้น แต่ไม่ได้ส่งคำขอ HTTP จริงเลยแม้แต่น้อย

นัยด้านความปลอดภัยและการรับมือ

  • หากชื่อโฮสต์มีข้อมูลอ่อนไหวรวมอยู่ด้วย (เช่น mycorp-and-othercorp-planned-merger-storage) ก็มีความเสี่ยงต่อ การรั่วไหลของข้อมูลอย่างร้ายแรง
  • สามารถอาศัยกลไกรายงานของ sentry นี้เพื่อ ชักนำให้เกิดการสแกน DNS ไปยังโฮสต์ภายนอกตามอำเภอใจ ได้ (วิธีการแบบเจาะจงขอปล่อยให้ผู้อ่านคิดต่อเอง)
  • มาตรการรับมือคือเปิดใช้ Little Snitch และบล็อกทั้งโดเมนดังกล่าวสำหรับทุกแอป

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

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

 
GN⁺ 2026-02-06
ความเห็นใน Hacker News

  • ดูเหมือนว่าหลายคนกำลังเข้าใจผิด ประเด็นนี้ไม่ใช่ปัญหาของ CT log แต่เกี่ยวกับ wildcard certificate
    Sentry เก็บ client-side trace แล้วดึง hostname ที่ส่งคำขอออกมา จากนั้นพยายาม poll กลับไปที่ hostname นั้นแต่ถูกปฏิเสธ

    • เป็นไปได้ว่าอาจพยายามดึง favicon มาแสดงใน UI ของ trace
    • แต่ถ้าโครงสร้างเป็นแบบนี้ ก็อาจกลายเป็น ช่องโหว่ด้านความปลอดภัย ที่ทำให้ Sentry ส่งคำขอไปยัง IP ใดก็ได้ตามอำเภอใจ โดยเฉพาะอาจเข้าถึง IP ที่ใช้รายงานทราฟฟิกอันตรายแบบอัตโนมัติซ้ำ ๆ ได้
    • ที่คนสับสนกันก็เพราะบทความต้นฉบับ เขียนได้สับสนและไม่ชัดเจนมาก

  • โดยพื้นฐานแล้ว hostname ไม่ใช่ข้อมูลส่วนตัว
    มันสามารถรั่วออกไปภายนอกได้จากหลายทาง เช่น DNS query หรือ TLS certificate
    ถ้าจะซ่อนบริการภายใน ควรใส่ความลับไว้ใน URL path แทน hostname จะดีกว่า
    ตัวอย่างเช่น fileservice.example.com/my-hidden-service-007-abc123/ แบบนี้จะถูกส่งผ่าน HTTPS เท่านั้น จึงมีโอกาสรั่วน้อยกว่ามาก

    • แน่นอนว่าแม้ในกรณีนี้ path ก็อาจถูกส่งไปยังบริการภายนอกอย่าง Sentry ได้เช่นกัน ดังนั้นควรใช้ URL แบบ opaque และไม่สร้างนิสัยใส่ความลับไว้ใน URL
    • มีคนถามด้วยว่า “ถ้าใช้แค่ HTTP การรั่วแบบนี้จะลดลงไหม?”

  • มีคนสงสัยว่า “clown GCP Host” เป็นคำเทคนิคหรือเปล่า สุดท้ายพบว่าเป็นคำที่ผู้เขียนใช้ ล้อเลียน cloud
    ประเด็นสำคัญคือเว็บอินเทอร์เฟซของ NAS ส่งล็อกไปยัง Sentry พร้อมแนบ internal hostname ไปด้วย
    ถ้าเป็นฉัน คงเปลี่ยนไปใช้ โอเพนซอร์ส OS ที่เชื่อถือได้ หรือไม่ก็ใช้ DNS block อย่าง PiHole เพื่อกันไม่ให้เรียกหา Sentry

    • คำว่า “clown” เป็น คำเหน็บแนม cloud ของ Big Tech และมีคนบอกว่าสมัยก่อนใน IRC ก็ใช้คำว่า “clown computing” กัน
      บางคนอธิบายว่าตัวเองใช้ local DNS กับ TLS proxy เพื่อปิดกั้นทราฟฟิกขาออกทั้งหมด
    • อีกคนเสริมว่า “clown” เป็นคำเก่าที่ใช้ เสียดสีผู้ให้บริการคลาวด์รายใหญ่และผู้ใช้ของพวกเขา
    • บางคนก็เล่นมุกว่าบางทีก็ใช้คำว่า “weenie” แทน “clown”
    • ยังมีมุกแนว “คณะละครสัตว์ไปแล้ว แต่ ตัวตลกยังอยู่” ด้วย

  • เพราะกรณีแบบนี้ ฉันเลยมองว่า uBlock Origin คือมาตรฐานขั้นต่ำของความปลอดภัยบนเว็บ
    ตอนนี้เว็บส่วนใหญ่โหลด third-party script กันเยอะเกินไปจนข้อมูลรั่วกันหนักมาก
    มันไม่ใช่ทางแก้ที่ราก แต่ก็เป็นสิ่งที่ดีที่สุดที่เราพอทำได้ตอนนี้

    • ฉันเองก็ติดตั้ง AdGuard Home ไว้ที่เราเตอร์ แล้วพบว่าทราฟฟิกถูกบล็อกไป 15~20% ทำให้เห็นชัดเลยว่าการติดตามกับโฆษณาหนักขนาดไหน

  • ถ้าจะป้องกันปัญหาแบบนี้ ควรวาง Nginx reverse proxy ไว้ด้านหน้าแล้ว inject CSP header
    วิธีนี้อาจหยุดไม่ให้ NAS ส่งคำขอออกไปภายนอกเองไม่ได้ แต่สามารถบล็อกไม่ให้เบราว์เซอร์เป็นคนส่งแทนได้
    ตัวอย่างเช่นคำขอ avatar ของ Steam (https://avatars.steamstatic.com/HASH_medium.jpg) ก็สามารถบล็อกได้ด้วยนโยบาย CSP
    ถ้าจำเป็นก็เปิดไว้แค่บางส่วนได้ และยังสามารถเพิ่ม Referrer-Policy: no-referrer เพื่อไม่ให้ hostname ไปโผล่ในล็อกภายนอก

    • มีคนหนึ่งทักเรื่องการพูดซ้ำแบบ “ATM machine”
    • ส่วนอีกคนตอบขำ ๆ ว่า “NPM นี่ค่อนข้างง่ายนะ”

  • ฉันเคยซื้อ Synology NAS แล้วเสียใจหลายครั้ง
    แทบทำอะไรได้น้อยมากนอกจากใช้ซอฟต์แวร์จากคอมมูนิตี้
    การตั้งค่า SSL ด้วย Let's Encrypt ก็ยุ่งยาก และ path ก็ไม่เป็นมาตรฐานจนหาตำแหน่ง config ได้ยาก
    ทั้ง rsync เวอร์ชันเก่า ยูทิลิตีพื้นฐานที่ขาด ๆ หาย ๆ และเรื่องอื่นอีกมาก ทำให้รู้สึกว่าน่าจะไปใช้ NAS ที่อยู่บน Linux หรือ BSD ดีกว่า

    • แต่ก็มีคนบอกว่าถ้าใช้ Synology เป็น file server อย่างเดียว มัน เสถียรมาก จนน่าพอใจ เพียงแต่เพราะแนวทางที่ปิดมากเกินไปจึงวางแผนจะย้ายไป UniFi NAS
    • มีอีกเสียงตอบว่าถ้าคุณอยากได้ server แล้วมาบ่นว่า NAS ไม่ใช่ server มันก็ย้อนแย้งอยู่
    • มีคนแชร์ด้วยว่าใน ฟอรัม Doozan มีไกด์สำหรับลง Debian รุ่นล่าสุด บน Synology NAS
    • อีกคำแนะนำคือ “ปล่อยให้มันเป็นแค่ file/iSCSI server ไปเถอะ มัน เสถียรมาก อย่าไปแตะมัน”
    • ในทางกลับกันก็มีคนบอกว่าซื้อรุ่น RS217 มาในราคา $100 แล้วเป็นการซื้อที่คุ้มที่สุด ใช้ Synology Office แทน Google Docs และประทับใจกับความเนี้ยบของ UI มาก

  • ไม่นานมานี้ฉันเพิ่งลองตั้งค่า Sentry และพบว่าระบบนี้มีฟีเจอร์ที่พยายาม ตั้งค่า uptime monitoring อัตโนมัติ
    ถ้ามันรู้จักโฮสต์ มันจะส่ง ping เป็นระยะ ๆ และถ้าตอบสนองได้เสถียรอยู่หลายวัน ก็จะแจ้งเตือนว่า “ต้องการตั้งค่า uptime monitoring ให้โฮสต์นี้ไหม?”

    • มีคนคอมเมนต์สั้น ๆ ว่า “โอกาสในการขยาย”

  • ส่วนตัวฉัน บล็อกทุกโดเมนที่เกี่ยวกับ Sentry ไปเลย
    มันอาจไม่ใช่วิธีแก้ทั่วไป แต่ในสภาพแวดล้อมของฉัน นั่นคือทางเลือกที่ดีที่สุด

  • มักจะเห็น reverse lookup server พยายาม resolve แม้กระทั่งที่อยู่เครือข่ายภายในอย่าง ULA หรือ RFC1918
    ถ้านำข้อมูลพวกนี้ไปรวมกับข้อมูลอื่น ก็อาจใช้อนุมานสถานะภายในได้
    ยังมีคนบอกด้วยว่า “ตอนเก็บข้อมูล Darknet เคยจับ UDP audio ได้ด้วย”

    • มีคนถามกลับว่า UDP audio นั้นเป็น SIP traffic ของปีไหน

  • เมื่อก่อนฉันเคยสืบกรณีคล้ายกันบน Heroku
    เวลาสร้างแอปใหม่ ระบบจะให้ random subdomain มา และถึงจะยังไม่ได้ทำ DNS lookup ก็จะมี คำขอจาก vulnerability scanner เข้ามาทันที
    พอไปถาม Heroku ก็ได้คำตอบว่าเป็นเพราะ URL ของแอปใหม่ถูกเปิดเผยใน Certificate Transparency (CT) log

    • มีคนบอกว่านี่เท่ากับติดป้าย “ช่วยมาโจมตีฉันที” ให้ทุกบริการใหม่ และชี้ว่าควรบันทึกแค่ hash ลง CT log แทนที่จะเป็น certificate จริง
      พร้อมแชร์ลิงก์ How Certificate Transparency Works
    • อีกคนบอกว่า “ฉันใช้ wildcard domain เลยหลบปัญหานี้ได้” พร้อมแนบสกรีนช็อต (ลิงก์ภาพ)