Ngày Telnet biến mất

 (labs.greynoise.io)
4 điểm bởi GN⁺ 2026-02-12 | 1 bình luận | Chia sẻ qua WhatsApp
  • Vào 21:00 (UTC) ngày 14/01/2026, lưu lượng Telnet toàn cầu sụp đổ đột ngột, mạng lưới quan sát xác nhận mức giảm bền vững 59%
  • 18 ASN im lặng hoàn toàn, và lưu lượng của 5 quốc gia (Zimbabwe, Ukraine, Canada, Ba Lan, Ai Cập) biến mất hoàn toàn
  • Các nhà cung cấp đám mây lớn (AWS, Contabo, v.v.) lại tăng, trong khi các ISP ở Bắc Mỹ giảm mạnh trên diện rộng
  • Sáu ngày sau, lỗ hổng bỏ qua xác thực trong GNU Inetutils telnetd (CVE-2026-24061) được công bố, được xác nhận là lỗi nghiêm trọng có thể giành quyền root
  • Ngành công nghiệp chú ý đến khả năng lọc cổng 23 ở cấp backbone là biện pháp được triển khai sau thông báo trước, và xem đây là sự kiện mang tính biểu tượng cho sự kết thúc của Telnet

Sự sụp đổ của lưu lượng Telnet toàn cầu

  • Vào 21:00 (UTC) ngày 14/01/2026, GreyNoise Global Observation Grid phát hiện sự sụp đổ đột ngột của lưu lượng Telnet
    • Từ khoảng 74.000 phiên một giờ trước đó xuống 22.000 phiên trong giờ kế tiếp, giảm 65%
    • Hai giờ sau giảm xuống còn khoảng 11.000 phiên, tức giảm 83%, rồi duy trì ở mức đó
  • So với trung bình 910.000 phiên mỗi ngày trong giai đoạn tháng 12/2025 đến đầu tháng 01/2026, sau đó con số này giảm xuống mức 370.000, tức giảm 59%
  • Đây không phải là sự giảm dần từng bước mà là một sự đứt gãy đột ngột tại một thời điểm duy nhất (thay đổi kiểu hàm bậc thang), cho thấy khả năng thay đổi cấu hình trong hạ tầng định tuyến

Các mạng và quốc gia im lặng

  • 18 ASN chuyển sang mức lưu lượng Telnet bằng ‘0’ kể từ sau ngày 15/01
    • Vultr(AS20473) 380.000 → 0, Cox Communications(AS22773) 150.000 → 0
    • Bao gồm Charter/Spectrum(AS20115), BT/British Telecom(AS2856), v.v.
  • Lưu lượng của 5 quốc gia (Zimbabwe, Ukraine, Canada, Ba Lan, Ai Cập) biến mất hoàn toàn
  • Trong khi đó AWS tăng 78%, Contabo tăng 90%, DigitalOcean giữ ở mức +3%
    • Các nhà cung cấp đám mây tránh được tác động của việc lọc backbone nhờ mạng peering riêng

Khả năng lọc cổng 23

  • Mẫu hình cho thấy khả năng các nhà cung cấp transit Tier 1 ở Bắc Mỹ đã áp dụng lọc cổng 23
    • Thời điểm này tương ứng 16:00 theo giờ miền Đông Hoa Kỳ, trùng với khung giờ bảo trì tại Mỹ
    • Các ISP Mỹ như Cox, Charter, Comcast(-74%) chịu ảnh hưởng nặng
    • Verizon/UUNET(AS701) giảm 79%, có thể là chủ thể lọc hoặc tuyến thượng nguồn với tư cách nhà cung cấp backbone lớn
  • Các quốc gia châu Âu có peering trực tiếp (Pháp +18%, Đức -1%) hầu như ít bị ảnh hưởng
  • Các nhà mạng Trung Quốc (China Telecom, China Unicom) đều giảm 59%
    • Tỷ lệ giảm đồng đều cho thấy khả năng lọc tại các liên kết xuyên Thái Bình Dương phía Mỹ

Công bố lỗ hổng CVE-2026-24061

  • Lỗ hổng bỏ qua xác thực trong GNU Inetutils telnetd, mức CVSS 9.8
    • Trong quá trình xử lý biến môi trường USER, việc chèn đối số cho phép truyền -f root để giành shell root mà không cần xác thực
    • Được đưa vào từ commit năm 2015 và không bị phát hiện trong khoảng 11 năm
  • Các mốc thời gian chính
    • 14/01: bắt đầu sụp đổ lưu lượng Telnet
    • 20/01: công bố CVE
    • 21/01: được ghi vào NVD và ghi nhận đợt khai thác đầu tiên
    • 26/01: được thêm vào danh sách CISA KEV
  • Sự sụp đổ lưu lượng xảy ra trước 6 ngày so với lúc CVE được công bố, làm dấy lên khả năng có liên hệ vượt quá mức trùng hợp đơn thuần

Giả thuyết về thông báo trước và phản ứng hạ tầng

  • Người báo cáo lỗ hổng là Kyu Neushwaistein / Carlos Cortes Alvarez, được biết là đã báo cáo vào ngày 19/01
  • Việc chuẩn bị bản vá và phản ứng của CISA được thực hiện chỉ trong vòng một ngày sau khi công khai cho thấy khả năng đã có sự điều phối từ trước
  • GreyNoise đưa ra các kịch bản sau
    • Các nhà vận hành hạ tầng lớn nhận được thông báo trước và chủ động áp dụng lọc cổng 23
    • 14/01 kích hoạt lọc → 20/01 công bố → 26/01 CISA ghi danh
  • Chưa có bằng chứng rõ ràng, và cũng có thể chỉ là sự trùng hợp về thời điểm

Diễn biến lưu lượng Telnet sau đó

  • Sau ngày 14/01, mẫu hình răng cưa tiếp tục xuất hiện
    • Ví dụ: ngày 28/01 có 800.000 phiên → ngày 30/01 còn 190.000 phiên
    • Có thể do lọc gián đoạn, biến động định tuyến hoặc các chiến dịch quét cụ thể
  • Trung bình theo tuần
    • Tuần của ngày 19/01: 360.000 phiên (40% so với mức chuẩn)
    • Tuần của ngày 02/02: 320.000 phiên (35%)
  • Ổn định ở khoảng 1/3 so với mức chuẩn, nhưng vẫn tiếp tục xu hướng giảm

Hàm ý về bảo mật và vận hành

  • Người dùng GNU Inetutils telnetd cần cập nhật ngay lên 2.7-2 trở lên hoặc vô hiệu hóa dịch vụ
    • CISA yêu cầu các cơ quan liên bang hoàn tất vá lỗi trước 16/02/2026
    • Các nỗ lực khai thác đã được ghi nhận chỉ vài giờ sau khi công bố, tăng lên tới 2.600 phiên mỗi ngày vào đầu tháng 2 rồi giảm
  • Các nhà vận hành mạng cần xem xét lọc cổng 23
    • Việc lọc ở cấp backbone đã diễn ra, và lưu lượng Telnet được xem là một giao thức không còn giá trị
  • GreyNoise ghi nhận rằng “ai đó đã ngắt Telnet khỏi một phần đáng kể của Internet”,
    và đánh giá đây là sự kiện biểu tượng cho sự kết thúc của kỷ nguyên Telnet

Bài viết liên quan

1 bình luận

 
GN⁺ 2026-02-12
Ý kiến trên Hacker News

  • Điều nghiêm trọng hơn telnetd là các nhà cung cấp transit Tier 1 đã bắt đầu lọc cổng
    Điều này có nghĩa là Internet đã bị phân mảnh, và đã thành cấu trúc không thể né tránh ngay cả bằng định tuyến tự động (BGP)

    • Hồi tôi còn làm ở một ISP nhỏ, sâu Blaster bùng phát, và chặn những cổng như 139 là cách ứng phó nhanh nhất
      Lúc đó phần lớn ISP đều chặn cổng, và kết quả là an toàn hơn
      Nếu thực sự cần telnet thì chỉ việc chuyển sang cổng khác hoặc dùng tunneling
      Tôi tự hỏi liệu giờ vẫn còn ai chạy telnet trên cổng mặc định 23 không
    • Nguy cơ kiểm duyệt cũng là vấn đề, nhưng việc các hệ thống như bệnh viện, ngân hàng, nhà máy điện hạt nhân bị hack rồi đe dọa tính mạng con người cũng là chuyện nghiêm trọng
      Những người đưa ra quyết định kiểu này đồng thời nắm cả quyền hạn lẫn trách nhiệm
    • Cổng 23 thực ra đã bị đa số nhà cung cấp lọc từ hàng chục năm trước
      Vì thế mọi thứ đang dồn cả vào cổng TLS 443
      Đây không phải thứ cần la ó là kiểm duyệt, kiểm duyệt thật sự phải tìm ở những đạo luật như FOSTA/SESTA
    • Tôi nghĩ chặn cổng thì rốt cuộc không khác gì kiểm duyệt
    • Tôi vẫn có thể dùng client GNU telnet qua ISP Spectrum để kết nối tới máy chủ ở Seattle và Hà Lan

  • Đây đúng là một lỗi gây kinh ngạc
    10 năm đầu của Internet gần như là thời kỳ chỉ dùng telnet
    Khi đó chỉ cần nhìn lưu lượng Ethernet là thấy ngay mật khẩu, và đa số hệ thống đều là môi trường đa người dùng
    Thật khó tin một lệnh như telnet -l 'root -f' server.test lại tồn tại được suốt 11 năm

    • Làm phần mềm càng lâu, tôi càng chỉ thấy lạ là thế giới vẫn vận hành được như vậy
      Có vẻ vẫn còn rất nhiều lỗ hổng kiểu trái treo thấp
    • Tôi không đăng nhập bằng root, nhưng đã có thời dùng tài khoản AIX ở trường để duyệt web bằng lynx
      Hồi đó tôi chưa từng nghĩ lưu lượng của mình bị giám sát, đơn giản chỉ là một thời kỳ tự do hơn
      Tôi dùng telnet cho mail (pine), web (lynx), cả IRC nữa
    • Tôi cũng chẳng nhớ mình ngừng dùng telnet từ khi nào
      Rất nhiều máy chủ để mở đăng nhập root qua telnet, mà chưa từng bị hack lần nào
      Tôi thực sự nhớ thời đó
    • Tôi nhớ hồi trước còn có lỗ hổng như rlogin -l '-froot'
      Thời đó mấy thứ này rất phổ biến
    • Tôi không dùng nó để đăng nhập, nhưng nó vẫn hữu ích như một công cụ debug
      Tôi thường dùng để kiểm tra lưu lượng giữa các container có thông hay không

  • Bản thân client Telnet vẫn chưa chết
    Ngày xưa người ta còn telnet vào máy chủ SMTP (cổng 25) để gửi email giả mạo
    Nhưng khi việc chặn cổng ngày càng tăng dưới danh nghĩa bảo mật, tôi nghĩ cuối cùng mọi dịch vụ sẽ dồn hết về cổng 443

    • Giờ các công cụ như netcat, socat, openssl s_client là lựa chọn thay thế tốt hơn nhiều
      Chúng mạnh hơn telnet rất nhiều
    • Hồi nhỏ tôi từng gửi SMS bằng telnet
      Với người nhận thì nó hiện như tài khoản chính thức của nhà mạng, lúc đó thì vô tư nhưng giờ nghĩ lại đúng là một trò đùa nguy hiểm
    • Bản thân telnet client hay telnetd vẫn dùng được
      Chỉ là có vẻ cổng mặc định đã bị chặn ở cấp độ định tuyến toàn cầu
      Có vẻ đây là biện pháp để bảo vệ các hệ thống cũ không được bảo mật

  • Tôi vẫn không hiểu vì sao người ta còn dùng telnet trên Internet
    Chẳng phải phần lớn đều là lưu lượng tấn công sao

    • Một số người vẫn chạy nó để bảo tồn các hệ thống lịch sử
    • Thật ra là để xem Star Wars bằng ASCII
      telnet towel.blinkenlights.nl
      Liên kết video YouTube
    • Thiết bị legacy, IoT, thiết bị công nghiệp vẫn còn dùng telnet
      Ngay cả SSH trong thực tế cũng thường được dùng một cách lỏng lẻo về bảo mật
      Ví dụ tắt xác minh host key, hoặc dùng khóa không mật khẩu
      Nên trong thực tế, tổ hợp telnet + HTTPS websocket + OAuth đôi khi còn có thể an toàn hơn
    • Trong giới vô tuyến nghiệp dư (HAM), mã hóa bị cấm, nên họ dùng telnet
      Thay vào đó, truyền dữ liệu có chữ ký được cho phép, nên cần một giao thức thay thế kiểu đó
    • Các máy chủ game văn bản như MUD hay MOO đến giờ phần lớn vẫn dùng telnet

  • CVE lần này là tin vui đối với cộng đồng hack thiết bị nhúng
    Khả năng giành được quyền root trên thiết bị có mở telnetd đã tăng lên

    • Tôi đã thử trực tiếp trên Zyxel WiFi AP, nhưng có lẽ vì nó dùng telnetd dựa trên busybox nên không bị ảnh hưởng

  • CVE đang nói đến bắt nguồn từ commit này
    Điểm mấu chốt là đổi user_name thành uname, và tôi từng thắc mắc vì sao cần đổi tên như vậy

    • Nhìn vào ChangeLog thì thấy user_name gây xung đột tên (shadowing) với biến toàn cục nên mới đổi
    • Nhưng tôi nghĩ quan trọng hơn mấy chỉnh sửa kiểu này là phải rà soát các lệnh gọi getenv()
      Vì việc phân tích giá trị đầu vào rất khó nên hay sinh ra lỗ hổng

  • Thật thú vị khi có ai đó đã quyết định loại bỏ lưu lượng telnet ở tầng trên của hạ tầng transit Internet
    Có lẽ đây còn là quyết định đúng đắn
    Tôi tò mò không biết lưu lượng MUD có bị ảnh hưởng không

    • Đa số MUD không dùng trực tiếp giao thức Telnet
      Chúng chỉ dựa trên TCP đơn giản và thường thích client chuyên dụng hơn
      Cổng 23 được IANA dành riêng cho Telnet, nhưng MUD thường dùng các cổng 4 chữ số cao hơn
      Thậm chí giờ chạy trên cổng 23 có lẽ còn khó truy cập hơn
    • Bài viết không nói rõ, nhưng có lẽ họ chỉ lọc lưu lượng tấn công
      Vì Telnet là dạng văn bản thuần nên phân tích mẫu rất dễ bắt được
    • Có lẽ đây là kiểu chặn theo cổng như chặn cổng SMTP
      Ngày nay nếu là máy chủ trên mạng công cộng thì nên dùng SSH

  • CVE này và cách ứng phó với nó thực sự là một sự kiện lịch sử
    Thật khó tin một người gần như đã kết thúc cả thời đại telnet

    • Thực ra có hai người, một người mở PR và một người phê duyệt
      Không phải lỗi của nhà nghiên cứu bảo mật

  • Hồi còn là thực tập sinh, tôi đã thấy cực kỳ thú vị khi phát hiện điện thoại VoIP trên bàn có thể telnet vào được

    • Tôi cũng từng dùng script Perl CGI qua telnet để thử nghiệm hồi còn là thực tập sinh
      Vì đã quen với lệnh Hayes nên việc tự gõ trực tiếp các yêu cầu HTTP thấy rất tự nhiên
    • Tôi cũng vậy, kỷ niệm vui thật

  • Gần đây xem thống kê máy chủ telnet của mình, tôi thấy trung bình có khoảng 2000 địa chỉ IP kết nối vào
    Giữa tháng 1 con số này tăng vọt lên 7500 rồi lại giảm, và sang tháng 2 thì rơi xuống mức khoảng 1000