รับมือ Tailworm: เสริมความปลอดภัยเครือข่าย Tailscale โดยไม่ทำให้ระบบ production หยุดชะงัก

วิธีที่เราตรวจสอบเครือข่าย Tailscale ตามข้อค้นพบของ Tailworm ปิดช่องโหว่จาก Tailscale SSH และให้งาน production ทุกงานทำงานต่อเนื่อง

สรุป

เมื่อวันที่ 25 ตุลาคม 2026 นักวิจัยด้านความปลอดภัยรายหนึ่งได้เผยแพร่ “Tailworm” ซึ่งเป็นข้อค้นพบ 11 รายการใน Tailscale และ headscale โดยเผยแพร่โดยไม่ผ่านกระบวนการเปิดเผยข้อมูลแบบประสานงาน (coordinated disclosure) ณ เวลาที่เขียนบทความนี้ Tailscale ยังไม่ได้เผยแพร่การแก้ไข ในเย็นวันเดียวกัน เราได้ตรวจสอบเครือข่าย Tailscale ของเราเทียบกับข้อค้นพบแต่ละรายการ เราปิดจุดเสี่ยงเพียงจุดเดียวที่เกี่ยวข้องกับเรา จำกัดสิทธิ์การเข้าถึงให้รัดกุมขึ้น และงาน production ทุกงานยังคงทำงานตลอดเวลา

บทความนี้อธิบายว่าเราตรวจสอบอะไร เปลี่ยนอะไร หลีกเลี่ยงการหยุดชะงักของระบบได้อย่างไร และได้บทเรียนอะไรบ้าง บทความนี้ไม่ใช่การตรวจสอบรายงานดังกล่าวอย่างเป็นอิสระ

สรุปสั้น ๆ ว่า Tailworm รายงานอะไร

ข้อค้นพบทั้ง 11 รายการแบ่งได้เป็นไม่กี่กลุ่ม:

• Tailscale SSH (ร้ายแรงที่สุด) เซสชัน SSH ที่ได้รับอนุญาตสามารถยกระดับสิทธิ์เป็น root บนเครื่องปลายทางได้ ในห้องทดลองของนักวิจัย การโจมตีนี้แพร่กระจายจากเครื่องหนึ่งไปยังอีกเครื่องหนึ่ง
• App connectors ไม่มีการตรวจสอบความถูกต้องของปลายทาง (destination)
• หน่วยความจำถูกใช้จนหมด ทั้งในเซิร์ฟเวอร์ควบคุมและในฝั่งไคลเอนต์
• กรณีขอบ (edge case) ของ Serve และ Funnel

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

ขั้นตอนที่ 1: ตรวจสอบก่อนเปลี่ยนแปลง

เราเริ่มจากการตรวจสอบแบบอ่านอย่างเดียว และบันทึกผลไว้ก่อนแตะต้องสิ่งใด:

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

ผลการตรวจสอบ:

• Tailscale SSH เปิดใช้งานอยู่ในบางส่วนของสภาพแวดล้อมของเรา ดังนั้นข้อค้นพบ F1–F3 และ F5 จึงเกี่ยวข้องกับเรา
• ฟีเจอร์ที่ข้อค้นพบอื่น ๆ ต้องอาศัยไม่ได้ถูกใช้งาน ข้อค้นพบส่วนใหญ่จึงไม่เกี่ยวข้อง
• บันทึก SSH ไม่พบแหล่งที่มาที่ผิดปกติและไม่มีคำขอส่งต่อ

ขั้นตอนที่ 2: ปิดจุดเสี่ยงโดยไม่ทำให้ระบบหยุดชะงัก

วิธีแก้ที่เห็นได้ชัดคือปิด Tailscale SSH แล้วใช้การยืนยันตัวตนด้วยคีย์ของ OpenSSH แบบมาตรฐานแทน แต่การตรวจสอบล่วงหน้าของเราพบกับดักอยู่

Tailscale SSH ยืนยันตัวตนด้วยตัวตนใน tailnet ไม่ใช่ด้วยคีย์ SSH สคริปต์อัตโนมัติของเราระบุคีย์ SSH ไว้ในบรรทัดคำสั่ง แต่คีย์นั้นป้องกันด้วยรหัสผ่าน (passphrase) จึงไม่มีทางทำงานแบบไม่มีคนดูแลได้เลย งานต่าง ๆ ทำงานได้ก็เพียงเพราะ Tailscale SSH ไม่เคยตรวจสอบคีย์ หากเราปิด Tailscale SSH ไปเฉย ๆ งานอัตโนมัติทุกงานจะหยุดทำงาน

เราจึงสลับระบบตามลำดับนี้:

1. สร้างคีย์เฉพาะสำหรับงานอัตโนมัติ จำกัดให้ใช้จากเครื่องต้นทางเพียงเครื่องเดียว และปิดการส่งต่อ
2. ทดสอบเส้นทางใหม่ก่อนสลับ เราเปิดพอร์ต OpenSSH ชั่วคราวที่เข้าถึงได้เฉพาะภายใน tailnet และเชื่อมต่อจากสภาพแวดล้อมแบบเดียวกับที่งานของเราทำงาน (ไม่มี SSH agent ไม่มีเทอร์มินัล) ด้วยทุกวิธีที่สคริปต์ของเราเรียกใช้ SSH
3. ทดสอบเชิงลบ คีย์ใหม่ถูกปฏิเสธเมื่อใช้จากนอกแหล่งที่อนุญาต และคำขอส่งต่อถูกปฏิเสธ
4. ตั้งการย้อนกลับอัตโนมัติไว้ก่อน ก่อนปิด Tailscale SSH เราตั้งตัวจับเวลาให้เปิดกลับมาเองโดยอัตโนมัติ เส้นทางกู้คืนนี้ไม่ขึ้นกับว่า SSH ใช้งานได้หรือไม่
5. สลับระบบ แล้วตรวจสอบงานอัตโนมัติทุกงานด้วยการเชื่อมต่อใหม่ ทุกงานทำงานจริงจนเสร็จหนึ่งรอบ เราไม่นับเซสชันที่เปิดค้างอยู่แล้วเป็นหลักฐาน
6. ลบส่วนประกอบชั่วคราว ได้แก่ พอร์ตที่เพิ่ม กฎไฟร์วอลล์ และตัวจับเวลาย้อนกลับ แล้วตรวจสอบอีกครั้ง

ขั้นตอนที่ 3: รัดกุมส่วนที่เหลือ

• ล้างนโยบาย Tailscale SSH ให้ว่าง นโยบายเริ่มต้นอนุญาตให้อุปกรณ์ใดก็ได้ของผู้ใช้เปิดเซสชัน SSH ไปยังอุปกรณ์อื่นของผู้ใช้คนเดียวกัน รวมถึงในฐานะ root โดยต้องอนุมัติซ้ำผ่านเบราว์เซอร์สัปดาห์ละครั้งเท่านั้น เราล้างนโยบายนี้ ดังนั้นหากเผลอเปิด Tailscale SSH กลับมา ก็จะไม่ให้สิทธิ์เข้าถึงอีกต่อไป
• ปิด SSH จากอินเทอร์เน็ต ก่อนปิด เรายืนยันว่าการล็อกอินผ่านคอนโซลนอกแบนด์ (out-of-band) ใช้งานได้ เพื่อไม่ให้ล็อกตัวเองออกจากระบบ หลังจากนั้นเราตรวจสอบจากเครือข่ายภายนอกว่า SSH ไม่ตอบสนองอีกแล้ว
• บังคับให้อนุมัติอุปกรณ์ อุปกรณ์ใหม่ต้องได้รับการอนุมัติจากผู้ดูแลระบบก่อนจึงจะเข้าร่วมได้
• ตรวจสอบคีย์ลงทะเบียน ไม่มีคีย์ที่ต้องเพิกถอน
• ยืนยันว่าบัญชีผู้ดูแลระบบเปิดใช้ MFA ใครก็ตามที่ยึดการล็อกอินของผู้ดูแลระบบได้ สามารถย้อนการควบคุมในระดับเครือข่ายได้ทั้งหมด
• เริ่มสังเกตทราฟฟิกจริงระหว่างอุปกรณ์ เพื่อให้ขั้นต่อไป คือการจำกัดว่าอุปกรณ์ใดเข้าถึงบริการใดได้ อิงจากหลักฐาน ไม่ใช่การคาดเดา

Tailnet Lock และการอนุมัติอุปกรณ์ต่างก็ป้องกันไม่ให้อุปกรณ์แปลกปลอมเข้าร่วมเครือข่ายได้ แต่ใช้ร่วมกันไม่ได้ จึงควรเลือกอย่างใดอย่างหนึ่งอย่างตั้งใจ

ขั้นตอนที่ 4: แก้ runbook ไม่ใช่แค่เซิร์ฟเวอร์

ขั้นตอนกู้คืนเดิมของเราระบุให้เชื่อมต่อเซิร์ฟเวอร์ใหม่โดยเปิด Tailscale SSH ไว้ หากทำตามหลังการเปลี่ยนแปลงนี้ ฟีเจอร์ที่มีความเสี่ยงจะกลับมาโดยไม่มีใครสังเกต เราจึงเขียนขั้นตอนใหม่:

• วินิจฉัยก่อน การเชื่อมต่อเครือข่ายขาดหาย หรือปัญหาอยู่ที่ตัว SSH เอง (คีย์ การกำหนดค่า ไฟร์วอลล์) ทั้งสองกรณีมีวิธีแก้ต่างกัน
• เชื่อมต่อใหม่โดยไม่เปลี่ยนการตั้งค่า ไม่ใส่แฟล็กเพิ่ม บันทึกการตั้งค่าของโหนดก่อนเชื่อมต่อใหม่ แล้วเปรียบเทียบหลังเชื่อมต่อ
• เปิดการเข้าถึงฉุกเฉินพร้อมตัวจับเวลาเท่านั้น ขออนุมัติก่อน ตั้งเวลาปิดอัตโนมัติก่อนเปิด จำกัดแหล่งที่มา และตรวจสอบทั้ง IPv4 และ IPv6
• ห้ามเปิด Tailscale SSH กลับมา แม้ในกรณีฉุกเฉิน การเปลี่ยนนโยบายการเข้าถึงที่จำเป็นสำหรับฟีเจอร์นี้ไม่สามารถย้อนกลับอัตโนมัติได้

บทเรียนที่ได้

1. รู้ให้แน่ว่าฟีเจอร์ความปลอดภัยยืนยันตัวตนด้วยอะไรจริง ๆ ก่อนจะถอดออก คีย์ที่สคริปต์ของเราระบุไว้ไม่เคยถูกใช้งานเลย
2. ทดสอบเส้นทางที่จะย้ายไปใช้จริง ๆ ในสภาพแวดล้อมเดียวกับที่งานของคุณทำงาน ก่อนทำการสลับ
3. เตรียมการย้อนกลับที่ไม่ขึ้นกับสิ่งที่กำลังเปลี่ยน ใช้ตัวจับเวลา ไม่ใช่ “เดี๋ยวค่อย SSH เข้าไปแก้”
4. ตรวจสอบช่องทางกู้คืนก่อนปิดประตู เรายืนยันการเข้าถึงคอนโซลก่อนปิด SSH จากอินเทอร์เน็ต
5. อัปเดต runbook ในการเปลี่ยนแปลงเดียวกัน ขั้นตอนกู้คืนแบบเก่าอาจย้อนการแก้ไขด้านความปลอดภัยได้ในอีกหลายเดือนต่อมา
6. อ่านนโยบายเริ่มต้น “อนุญาตอุปกรณ์ของตัวเอง รวมถึง root” คือค่าเริ่มต้นที่เราใช้อยู่ตอนแรก
7. แยก “การเปลี่ยนแปลงสำเร็จ” ออกจาก “ช่องโหว่ได้รับการแก้ไขแล้ว” เราไม่ได้เสี่ยงต่อข้อค้นพบเกี่ยวกับ Tailscale SSH อีกต่อไป แต่ Tailworm โดยรวมยังไม่จบจนกว่าการแก้ไขจากต้นทาง (upstream) จะออกมา เราจะอัปเดตไคลเอนต์เมื่อการแก้ไขออกมา
8. วัดก่อน แล้วค่อยจำกัด มีข้อมูลทราฟฟิกที่สังเกตได้และรายการการพึ่งพาจริงก่อนจะเข้มงวดกฎการเข้าถึง เพื่อไม่ให้การเสริมความปลอดภัยทำให้ธุรกิจหยุดชะงัก

ขั้นต่อไป

เรากำลังจำกัดการเข้าถึงเครือข่ายระหว่างอุปกรณ์ให้เหลือเพียงขั้นต่ำที่แต่ละบริการต้องใช้ โดยอิงจากทราฟฟิกที่สังเกตได้ และจะติดตั้งการแก้ไขของ Tailscale ทันทีที่เผยแพร่

อ้างอิง: รายงาน Tailworm (tailworm.com) และเอกสารของ Tailscale เรื่อง Tailnet Lock