วันที่ Telnet หายไป

 (labs.greynoise.io)
4 คะแนน โดย GN⁺ 2026-02-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อวันที่ 14 มกราคม 2026 เวลา 21:00 น. (UTC) ทราฟฟิก Telnet ทั่วโลกล่มลงอย่างฉับพลัน โดยเครือข่ายสังเกตการณ์ยืนยันการลดลงอย่างต่อเนื่อง 59%
  • 18 ASN เงียบสนิทโดยสมบูรณ์ และทราฟฟิกของ 5 ประเทศ (ซิมบับเว ยูเครน แคนาดา โปแลนด์ อียิปต์) หายไปทั้งหมด
  • ผู้ให้บริการ คลาวด์รายใหญ่ (AWS, Contabo เป็นต้น) กลับเพิ่มขึ้น, ขณะที่ ISP ในอเมริกาเหนือปรับลดลงอย่างมาก
  • อีก 6 วันต่อมา มีการเปิดเผย ช่องโหว่ยืนยันตัวตนข้ามได้ของ GNU Inetutils telnetd (CVE-2026-24061) ซึ่งยืนยันว่าเป็นช่องโหว่ร้ายแรงที่สามารถยึดสิทธิ์ root ได้
  • วงการให้ความสนใจกับความเป็นไปได้ว่าเป็นมาตรการ กรองพอร์ต 23 ในระดับแบ็กโบน จากการแจ้งเตือนล่วงหน้า และประเมินว่าเป็นเหตุการณ์เชิงสัญลักษณ์ของจุดจบของ Telnet

การพังทลายของทราฟฟิก Telnet ทั่วโลก

  • เมื่อวันที่ 14 มกราคม 2026 เวลา 21:00 น. (UTC) GreyNoise Global Observation Grid ตรวจพบ การพังทลายของทราฟฟิก Telnet อย่างฉับพลัน
    • จากประมาณ 74,000 เซสชันหนึ่งชั่วโมงก่อนหน้า ลดลงเหลือ 22,000 เซสชันในชั่วโมงถัดมา หายไป 65%
    • สองชั่วโมงถัดมา ลดลงถึง 83% เหลือราว 11,000 เซสชัน และคงอยู่ในระดับนั้น
  • เมื่อเทียบกับ ค่าเฉลี่ยรายวัน 910,000 เซสชัน ตั้งแต่เดือนธันวาคม 2025 ถึงต้นเดือนมกราคม 2026 หลังจากนั้นลดลงเหลือ ระดับ 370,000 เซสชัน หรือลดลง 59%
  • การเปลี่ยนแปลงนี้ไม่ใช่การลดลงแบบค่อยเป็นค่อยไป แต่เป็น การขาดหายอย่างฉับพลันในจุดเวลาเดียว (การเปลี่ยนแบบ step function) ซึ่งบ่งชี้ถึงความเป็นไปได้ของการเปลี่ยนการตั้งค่าโครงสร้างพื้นฐานการเราต์

เครือข่ายและประเทศที่เงียบหายไป

  • 18 ASN เปลี่ยนเป็นทราฟฟิก Telnet เท่ากับ '0' หลังวันที่ 15 มกราคม
    • Vultr (AS20473) 380,000 ครั้ง → 0, Cox Communications (AS22773) 150,000 ครั้ง → 0
    • รวมถึง Charter/Spectrum (AS20115), BT/British Telecom (AS2856) เป็นต้น
  • 5 ประเทศ (ซิมบับเว ยูเครน แคนาดา โปแลนด์ อียิปต์) มีทราฟฟิกหายไปทั้งหมด
  • ในทางกลับกัน AWS เพิ่มขึ้น 78%, Contabo เพิ่มขึ้น 90%, DigitalOcean ทรงตัวที่ +3%
    • ผู้ให้บริการคลาวด์หลีกเลี่ยงผลกระทบจากการกรองที่แบ็กโบนได้ผ่าน เครือข่าย peering ส่วนตัว

ความเป็นไปได้ของการกรองพอร์ต 23

  • จากรูปแบบที่พบ มีสัญญาณว่า ผู้ให้บริการทรานซิต Tier 1 ในอเมริกาเหนือได้ใช้การกรองพอร์ต 23
    • ช่วงเวลานั้นตรงกับ 16:00 น. ตามเวลาตะวันออกของสหรัฐฯ ซึ่งสอดคล้องกับ ช่วงเวลาบำรุงรักษาในสหรัฐฯ
    • ISP สหรัฐฯ อย่าง Cox, Charter, Comcast (-74%) ได้รับผลกระทบหนัก
    • Verizon/UUNET (AS701) ลดลง 79% ในฐานะผู้ให้บริการแบ็กโบนรายใหญ่ จึงอาจเป็นผู้ลงมือกรองหรือเป็นเส้นทางต้นน้ำ
  • ประเทศในยุโรปที่มี direct peering (ฝรั่งเศส +18%, เยอรมนี -1%) ได้รับผลกระทบน้อยมาก
  • ผู้ให้บริการโทรคมนาคมจีน (China Telecom, China Unicom) ลดลงทั้งคู่ 59%
    • อัตราการลดลงที่สม่ำเสมอบ่งชี้ถึงความเป็นไปได้ของ การกรองบนลิงก์ข้ามแปซิฟิกฝั่งสหรัฐฯ

การเปิดเผยช่องโหว่ CVE-2026-24061

  • ช่องโหว่ยืนยันตัวตนข้ามได้ของ GNU Inetutils telnetd ระดับ CVSS 9.8
    • ระหว่างการจัดการตัวแปรแวดล้อม USER หากมีการฉีดอาร์กิวเมนต์แล้วส่ง -f root ก็จะ ได้ root shell โดยไม่ต้องยืนยันตัวตน
    • ถูกนำเข้ามาตั้งแต่คอมมิตปี 2015 และไม่ถูกค้นพบอยู่นานราว 11 ปี
  • ไทม์ไลน์หลัก
    • 14 ม.ค.: เริ่มการพังทลายของทราฟฟิก Telnet
    • 20 ม.ค.: เปิดเผย CVE
    • 21 ม.ค.: ขึ้นทะเบียนใน NVD และพบการโจมตีจริงครั้งแรก
    • 26 ม.ค.: เพิ่มเข้าในรายการ CISA KEV
  • การพังทลายของทราฟฟิกเกิดขึ้นก่อนการเปิดเผย CVE ถึง 6 วัน ทำให้เกิดข้อสันนิษฐานว่าอาจมีความเชื่อมโยงมากกว่าแค่ความบังเอิญ

สมมติฐานเรื่องการแจ้งเตือนล่วงหน้าและการตอบสนองของโครงสร้างพื้นฐาน

  • ผู้รายงานช่องโหว่คือ Kyu Neushwaistein / Carlos Cortes Alvarez โดยทราบกันว่ารายงานเมื่อวันที่ 19 มกราคม
  • การที่ การเตรียมแพตช์และการตอบสนองของ CISA เกิดขึ้นภายในเวลาเพียงวันเดียวหลังการเปิดเผย ชี้ว่ามีความเป็นไปได้ของ การประสานงานล่วงหน้า
  • GreyNoise เสนอฉากทัศน์ดังต่อไปนี้
    • ผู้ดูแลโครงสร้างพื้นฐานหลักได้รับ การแจ้งเตือนล่วงหน้าและใช้การกรองพอร์ต 23 เชิงรุก
    • 14 ม.ค. เริ่มกรอง → 20 ม.ค. เปิดเผย → 26 ม.ค. ขึ้นทะเบียนกับ CISA
  • ยังไม่มีหลักฐานชัดเจน และก็มีการกล่าวถึงความเป็นไปได้ว่าเป็นเพียงช่วงเวลาที่บังเอิญตรงกัน

รูปแบบของทราฟฟิก Telnet หลังจากนั้น

  • หลังวันที่ 14 มกราคมยังคงมี รูปแบบฟันเลื่อย ต่อเนื่อง
    • ตัวอย่าง: 28 ม.ค. 800,000 เซสชัน → 30 ม.ค. 190,000 เซสชัน
    • อาจเกิดจากการกรองเป็นช่วงๆ การเปลี่ยนแปลงการเราต์ หรือแคมเปญสแกนเนอร์เฉพาะกลุ่ม
  • ค่าเฉลี่ยรายสัปดาห์
    • สัปดาห์ของวันที่ 19 ม.ค.: 360,000 เซสชัน (40% ของค่าฐาน)
    • สัปดาห์ของวันที่ 2 ก.พ.: 320,000 เซสชัน (35%)
  • ทรงตัวอยู่ที่ราว 1/3 ของค่าฐาน และยังคงมีแนวโน้มลดลง

นัยต่อความปลอดภัยและการปฏิบัติการ

  • ผู้ใช้ GNU Inetutils telnetd ควรอัปเดตเป็น 2.7-2 ขึ้นไปทันที หรือปิดบริการ
    • CISA กำหนดเส้นตายให้หน่วยงานรัฐบาลกลางแพตช์ภายใน 16 กุมภาพันธ์ 2026
    • หลังเปิดเผยไม่นาน พบความพยายามโจมตีภายในไม่กี่ชั่วโมง และเพิ่มขึ้นสูงสุดถึง 2,600 เซสชันต่อวันในต้นเดือนกุมภาพันธ์ก่อนลดลง
  • ผู้ดูแลเครือข่าย ควรพิจารณาการกรองพอร์ต 23
    • ในระดับแบ็กโบนมีการกรองดำเนินอยู่แล้ว และ ทราฟฟิก Telnet ถูกมองว่าไม่ใช่โปรโตคอลที่มีคุณค่าอีกต่อไป
  • GreyNoise บันทึกข้อเท็จจริงว่า “มีใครบางคนตัด Telnet ออกจากอินเทอร์เน็ตส่วนใหญ่” และประเมินว่าเป็นเหตุการณ์ที่เป็นสัญลักษณ์ของ
    จุดจบของยุค Telnet

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

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

 
GN⁺ 2026-02-12
ความเห็นจาก Hacker News

  • สิ่งที่ร้ายแรงยิ่งกว่า telnetd คือการที่ ผู้ให้บริการทรานซิต Tier 1 เริ่มกรองพอร์ต
    นี่หมายความว่าอินเทอร์เน็ตถูกแบ่งแยก และกลายเป็นโครงสร้างที่แม้แต่การเราต์อัตโนมัติ (BGP) ก็ไม่สามารถอ้อมได้

    • ตอนที่เคยทำงานอยู่กับ ISP เล็ก ๆ สมัยก่อน ตอน หนอน Blaster ระบาด การบล็อกพอร์ตอย่าง 139 คือวิธีตอบสนองที่เร็วที่สุด
      ตอนนั้น ISP ส่วนใหญ่ก็ปิดกั้นพอร์ต และผลลัพธ์ก็คือปลอดภัยขึ้น
      ถ้าจำเป็นต้องใช้ telnet จริง ๆ ก็ย้ายไปพอร์ตอื่นหรือทำ tunneling ก็ได้
      สงสัยจริง ๆ ว่ายังมีใครรัน telnet บนพอร์ตมาตรฐาน 23 อยู่ไหม
    • ความเสี่ยงด้านการเซ็นเซอร์ก็เป็นปัญหา แต่การที่ระบบอย่างโรงพยาบาล ธนาคาร หรือโรงไฟฟ้านิวเคลียร์ถูกแฮ็กจนทำให้ชีวิตคนตกอยู่ในอันตรายก็เป็นเรื่องร้ายแรงเหมือนกัน
      คนที่ตัดสินใจเรื่องแบบนี้มีทั้ง อำนาจและความรับผิดชอบ พร้อมกัน
    • พอร์ต 23 ถูกผู้ให้บริการส่วนใหญ่กรองมาหลายสิบปีแล้ว
      เพราะงั้นทุกอย่างเลยไหลไปรวมกันที่ พอร์ต TLS 443
      เรื่องนี้ไม่ใช่อะไรที่จะต้องร้องว่าเป็นการเซ็นเซอร์ การเซ็นเซอร์จริง ๆ ควรไปดูในกฎหมายอย่าง FOSTA/SESTA มากกว่า
    • ผมคิดว่าการบล็อกพอร์ตก็แทบ ไม่ต่างจากการเซ็นเซอร์ อยู่ดี
    • ผมยังเชื่อมต่อไปยังเซิร์ฟเวอร์ในซีแอตเทิลและเนเธอร์แลนด์ผ่าน GNU telnet client โดยใช้ ISP ของ Spectrum ได้อยู่

  • เป็นบั๊กที่น่าตกใจจริง ๆ
    ช่วง 10 ปีแรกของอินเทอร์เน็ตแทบจะเป็น ยุคที่ใช้แต่ telnet
    ตอนนั้นถ้าดูทราฟฟิกบนอีเธอร์เน็ตก็เห็นรหัสผ่านกันตรง ๆ และระบบส่วนใหญ่ก็เป็นสภาพแวดล้อมแบบหลายผู้ใช้
    น่าเหลือเชื่อที่คำสั่งอย่าง telnet -l 'root -f' server.test จะอยู่รอดมาได้ตั้ง 11 ปี

    • ยิ่งทำงานสายซอฟต์แวร์มานาน ก็ยิ่งรู้สึกแปลกใจที่โลกมันยังหมุนแบบนี้ได้
      น่าจะยังมีช่องโหว่ประเภท ผลไม้ที่ห้อยต่ำ แบบนี้อยู่อีกเยอะ
    • ผมไม่ได้ล็อกอินเป็น root แต่ก็มีช่วงหนึ่งที่ใช้บัญชี AIX ของโรงเรียนเปิดเว็บผ่าน lynx
      ตอนนั้นไม่เคยนึกเลยว่าทราฟฟิกจะถูกสอดส่อง มันเป็นช่วงเวลาที่อิสระเรียบง่ายมาก
      ใช้ telnet ทำทุกอย่างทั้งเมล (pine), เว็บ (lynx) และ IRC
    • จำไม่ได้แล้วว่าหยุดใช้ telnet ตั้งแต่เมื่อไร
      มีเซิร์ฟเวอร์มากมายที่เปิดให้ root เข้า telnet ได้ และไม่เคยโดนแฮ็กเลย
      คิดถึงยุคนั้นจริง ๆ
    • ทำให้นึกถึงช่องโหว่อย่าง rlogin -l '-froot' สมัยก่อน
      ตอนนั้นเรื่องแบบนี้พบได้ทั่วไป
    • ไม่ได้ใช้สำหรับล็อกอิน แต่ยังมีประโยชน์ในฐานะ เครื่องมือดีบัก
      ใช้บ่อยเวลาตรวจดูว่าทราฟฟิกระหว่างคอนเทนเนอร์วิ่งถึงกันไหม

  • ตัว Telnet client เองยังไม่ถึงกับตาย
    สมัยก่อนเคยใช้ telnet ต่อเข้า SMTP server (พอร์ต 25) เพื่อส่ง อีเมลปลอมผู้ส่ง
    แต่เมื่อมีการบล็อกพอร์ตมากขึ้นเรื่อย ๆ ด้วยเหตุผลด้านความปลอดภัย ท้ายที่สุดผมคิดว่าทุกบริการก็จะไปรวมกันที่ พอร์ต 443

    • ทุกวันนี้มีเครื่องมืออย่าง netcat, socat, openssl s_client ที่เป็นทางเลือกดีกว่ามาก
      ทรงพลังกว่า telnet เยอะ
    • ตอนเด็ก ๆ เคยใช้ telnet ส่ง SMS
      ฝั่งผู้รับจะเห็นเหมือนส่งมาจากบัญชีทางการของผู้ให้บริการโทรคมนาคม ตอนนั้นอาจทำไปแบบไร้เดียงสา แต่พอย้อนคิดก็เป็นการแกล้งที่อันตราย
    • ทั้ง telnet client และ telnetd เองก็ยังใช้งานได้
      เพียงแต่ดูเหมือนว่าพอร์ตมาตรฐานจะถูกบล็อกในระดับการเราต์ทั่วโลก
      น่าจะเป็นมาตรการเพื่อปกป้องระบบเก่าที่ไม่ปลอดภัย

  • ผมยังไม่เข้าใจว่าทำไมถึงยังใช้ telnet บนอินเทอร์เน็ตกันอยู่
    ส่วนใหญ่น่าจะเป็นทราฟฟิกโจมตีไม่ใช่หรือ

    • บางส่วนรันไว้เพื่อ อนุรักษ์ระบบประวัติศาสตร์
    • ที่จริงก็เพื่อดู ASCII Star Wars
      telnet towel.blinkenlights.nl
      ลิงก์วิดีโอ YouTube
    • อุปกรณ์ legacy, IoT และอุตสาหกรรม ยังใช้ telnet กันอยู่
      แม้แต่ SSH เองในทางปฏิบัติก็มักถูกใช้อย่างหละหลวมด้านความปลอดภัย
      เช่น ปิดการตรวจสอบ host key หรือใช้คีย์ที่ไม่มีรหัสผ่าน
      เพราะงั้นในโลกความเป็นจริง ชุด telnet + HTTPS websocket + OAuth อาจปลอดภัยกว่าก็ได้
    • ในวงการวิทยุสมัครเล่น (HAM) ห้ามใช้การเข้ารหัส จึงใช้ telnet
      แต่อนุญาตให้ส่งข้อมูลที่มีลายเซ็นได้ ดังนั้นจึงต้องมีโปรโตคอลทางเลือกแบบนั้น
    • เซิร์ฟเวอร์เกมข้อความอย่าง MUD หรือ MOO ส่วนใหญ่ก็ยังใช้ telnet อยู่

  • CVE ครั้งนี้เป็นข่าวดีสำหรับ ชุมชนแฮ็กอุปกรณ์ embedded
    เพราะความเป็นไปได้ที่จะได้สิทธิ root จากอุปกรณ์ที่เปิด telnetd ไว้นั้นสูงขึ้น

    • ผมลองทดสอบกับ Zyxel WiFi AP โดยตรงแล้ว แต่ดูเหมือนจะไม่เปราะบาง เพราะใช้ telnetd ที่อิงกับ busybox

  • CVE ที่เป็นประเด็นนี้มาจากคอมมิตนี้
    แก่นสำคัญคือการเปลี่ยน user_name เป็น uname และผมก็สงสัยว่าทำไมต้องเปลี่ยนชื่อแบบนี้

    • ถ้าดูใน ChangeLog จะเห็นว่าเปลี่ยนเพราะ user_name ชนชื่อกับตัวแปร global จนเกิด name shadowing
    • แต่ผมคิดว่าที่สำคัญกว่าการแก้แบบนี้คือการตรวจสอบ การเรียก getenv()
      เพราะการพาร์สค่าป้อนเข้ามันยาก และมักทำให้เกิดช่องโหว่ได้

  • น่าสนใจที่มีใครบางคนตัดสินใจทิ้งทราฟฟิก telnet จากด้านบนของโครงสร้างพื้นฐานทรานซิตอินเทอร์เน็ต
    อาจจะเป็นการตัดสินใจที่ถูกต้องก็ได้
    สงสัยว่าจะกระทบทราฟฟิก MUD ไหม

    • MUD ส่วนใหญ่ ไม่ได้ใช้ Telnet protocol โดยตรง
      มักเป็น TCP ธรรมดา และนิยมใช้ไคลเอนต์เฉพาะทางมากกว่า
      พอร์ต 23 ถูก IANA จองไว้ให้ Telnet แต่ MUD มักใช้พอร์ตเลข 4 หลักที่สูงกว่า
      ถ้าทุกวันนี้ไปรันบนพอร์ต 23 น่าจะยิ่งเข้าถึงยากกว่าเดิม
    • ในบทความไม่ได้บอกชัด แต่ดูเหมือนว่าน่าจะกรองเฉพาะทราฟฟิกโจมตี
      เพราะ Telnet เป็นข้อความล้วน จึงจับได้ง่ายด้วย การวิเคราะห์แพตเทิร์น
    • เป็นไปได้มากว่าจะเป็นการบล็อกตามพอร์ตแบบเดียวกับ การบล็อกพอร์ต SMTP
      ทุกวันนี้ถ้าเป็นเซิร์ฟเวอร์บนเครือข่ายสาธารณะก็ควรใช้ SSH

  • CVE นี้และการตอบสนองต่อมันถือเป็น เหตุการณ์ประวัติศาสตร์ จริง ๆ
    ไม่น่าเชื่อว่าคนคนเดียวจะปิดฉากยุค telnet ได้แทบจะโดยลำพัง

    • จริง ๆ แล้วมีสองคน คือคนที่ส่ง PR กับคนที่อนุมัติ
      ไม่ใช่ความผิดของนักวิจัยด้านความปลอดภัย

  • ตอนเป็นเด็กฝึกงาน ผมรู้สึกทึ่งมากเมื่อพบว่าสามารถ telnet เข้าไปที่โทรศัพท์ VoIP บนโต๊ะได้

    • ตอนผมเป็นอินเทิร์นก็เคยทดสอบ สคริปต์ Perl CGI ผ่าน telnet เหมือนกัน
      เพราะคุ้นกับคำสั่ง Hayes อยู่แล้ว การพิมพ์ HTTP request ตรง ๆ เลยเป็นเรื่องธรรมชาติ
    • ผมก็เหมือนกัน เป็นความทรงจำที่สนุกดี

  • เมื่อเร็ว ๆ นี้ผมดูสถิติของเซิร์ฟเวอร์ telnet ของตัวเอง พบว่ามีการเชื่อมต่อเฉลี่ยประมาณ 2,000 IP
    ช่วงกลางเดือนมกราคมพุ่งขึ้นไปถึง 7,500 แล้วก็ลดลงอีก และในเดือนกุมภาพันธ์ลดลงมาอยู่ราว 1,000