▲

텔넷이 사라진 날

 (labs.greynoise.io)
1P by GN⁺ 6시간전 | ★ favorite | 댓글 1개
  • 2026년 1월 14일 21시(UTC)에 전 세계 텔넷 트래픽이 급격히 붕괴, GreyNoise 관측망에서 59%의 지속적 감소가 확인됨
  • 18개 ASN이 완전히 침묵하고, 5개국(짐바브웨·우크라이나·캐나다·폴란드·이집트) 의 트래픽이 완전 소멸
  • 주요 클라우드 사업자(AWS·Contabo 등)는 오히려 증가, 반면 북미 지역 ISP는 대규모 감소
  • 6일 뒤 GNU Inetutils telnetd의 인증 우회 취약점(CVE-2026-24061) 공개, 루트 권한 획득이 가능한 치명적 결함으로 확인
  • 업계는 백본 수준의 포트 23 필터링이 사전 통보에 따른 조치일 가능성을 주목하며, 텔넷의 종말을 상징하는 사건으로 평가

전 세계 텔넷 트래픽 붕괴

  • 2026년 1월 14일 21시(UTC)에 GreyNoise Global Observation Grid가 텔넷 트래픽의 급격한 붕괴를 감지
    • 1시간 전 약 74,000세션에서 다음 시간 22,000세션으로 65% 급감
    • 두 시간 후에는 83% 감소한 11,000세션 수준으로 하락 후 유지
  • 2025년 12월~2026년 1월 초까지의 평균 일일 세션 91만 건 대비, 이후 37만 건 수준으로 59% 감소
  • 변화는 점진적 감소가 아닌 단일 시점의 급격한 단절(스텝 함수형 변화) 로, 라우팅 인프라 설정 변경 가능성 시사

침묵한 네트워크와 국가

  • 18개 ASN이 1월 15일 이후 텔넷 트래픽 ‘0’으로 전환
    • Vultr(AS20473) 38만 건 → 0, Cox Communications(AS22773) 15만 건 → 0
    • Charter/Spectrum(AS20115), BT/British Telecom(AS2856) 등 포함
  • 5개국(짐바브웨, 우크라이나, 캐나다, 폴란드, 이집트) 의 트래픽 완전 소멸
  • 반면 AWS 78% 증가, Contabo 90% 증가, DigitalOcean +3% 유지
    • 클라우드 사업자는 사설 피어링망을 통해 백본 필터링 영향 회피

포트 23 필터링의 가능성

  • 패턴상 북미 Tier 1 트랜짓 사업자가 포트 23 필터링을 적용한 정황
    • 시점이 미국 동부시간 16시로, 미국 내 유지보수 시간대와 일치
    • Cox, Charter, Comcast(-74%) 등 미국 ISP가 큰 타격
    • Verizon/UUNET(AS701) 79% 감소, 주요 백본 사업자로서 필터링 주체 혹은 상위 경로 가능성
  • 유럽 직접 피어링 국가(프랑스 +18%, 독일 -1%) 는 영향 미미
  • 중국 통신사(China Telecom, China Unicom) 모두 59% 감소
    • 균일한 감소율은 미국 측 태평양 횡단 링크에서의 필터링 가능성 시사

CVE-2026-24061 취약점 공개

  • GNU Inetutils telnetd의 인증 우회 취약점, CVSS 9.8 등급
    • USER 환경변수 처리 중 인자 주입으로 -f root 전달 시 인증 없이 루트 셸 획득 가능
    • 2015년 커밋에서 도입되어 약 11년간 미발견 상태
  • 주요 일정
    • 1월 14일: 텔넷 트래픽 붕괴 시작
    • 1월 20일: CVE 공개
    • 1월 21일: NVD 등재 및 첫 악용 관측
    • 1월 26일: CISA KEV 목록 추가
  • 트래픽 붕괴가 CVE 공개 6일 전 발생, 단순한 우연 이상의 연관 가능성 제기

사전 통보와 인프라 대응 가설

  • 취약점 제보자는 Kyu Neushwaistein / Carlos Cortes Alvarez, 1월 19일 보고로 알려짐
  • 패치 준비·CISA 대응이 공개 하루 만에 이루어진 점에서 사전 조율 가능성 존재
  • GreyNoise는 다음 시나리오를 제시
    • 주요 인프라 운영자가 사전 통보를 받고 포트 23 필터링을 선제 적용
    • 1월 14일 필터링 가동 → 1월 20일 공개 → 1월 26일 CISA 등록
  • 명확한 증거는 없으며, 단순한 시기적 일치일 가능성도 언급

이후의 텔넷 트래픽 양상

  • 1월 14일 이후 톱니형 패턴 지속
    • 예: 1월 28일 80만 세션 → 1월 30일 19만 세션
    • 간헐적 필터링, 라우팅 변동, 특정 스캐너 캠페인 가능성
  • 주간 평균
    • 1월 19일 주: 36만 세션(기준 대비 40%)
    • 2월 2일 주: 32만 세션(35%)
  • 기준 대비 약 1/3 수준으로 안정화, 여전히 감소 추세

보안 및 운영상의 시사점

  • GNU Inetutils telnetd 사용자는 즉시 2.7-2 이상으로 업데이트 또는 서비스 비활성화 필요
    • CISA는 2026년 2월 16일까지 연방기관 패치 마감
    • 공개 직후 수 시간 내 악용 시도 관측, 2월 초 일일 2,600세션까지 증가 후 감소
  • 네트워크 운영자는 포트 23 필터링 검토 필요
    • 백본 수준에서 이미 필터링이 진행 중이며, 텔넷 트래픽은 더 이상 가치 없는 프로토콜로 간주
  • GreyNoise는 “누군가 인터넷의 상당 부분에서 텔넷을 끊었다”는 사실을 기록하며,
    텔넷 시대의 종말을 상징하는 사건으로 평가
▲
GN⁺ 6시간전  [-]
Hacker News 의견들

  • telnetd보다 더 심각한 건 Tier 1 트랜짓 제공자들이 포트 필터링을 시작한 사실임
    이건 인터넷이 분할된 것이고, 자동 라우팅(BGP)으로도 우회할 수 없는 구조가 되어버림

    • 예전에 작은 ISP에서 일할 때 Blaster 웜이 터졌는데, 포트 139 같은 걸 막는 게 가장 빠른 대응이었음
      그때 대부분의 ISP가 포트를 차단했고, 결과적으로 더 안전해졌음
      만약 정말 telnet이 필요하다면 다른 포트로 옮기거나 터널링하면 됨
      기본 포트 23으로 telnet을 돌리는 사람이 아직도 있을까 궁금함
    • 검열 위험도 문제지만, 병원·은행·원자력 같은 시스템이 해킹돼서 사람 목숨이 위험해지는 것도 심각한 일임
      이런 결정을 내리는 사람들은 권한과 책임을 동시에 가짐
    • 포트 23은 이미 수십 년 전부터 대부분의 제공자가 필터링했음
      그래서 모든 게 TLS 443 포트로 몰리는 중임
      이걸 검열이라며 소리칠 일은 아님, 진짜 검열은 FOSTA/SESTA 같은 법에서 찾아야 함
    • 포트를 막는 건 결국 검열과 다를 바 없음이라고 생각함
    • 나는 Spectrum ISP를 통해 GNU telnet 클라이언트로 시애틀과 네덜란드 서버에 접속할 수 있었음

  • 정말 놀라운 버그임
    인터넷 초창기 10년은 거의 telnet만 쓰던 시절이었음
    그땐 이더넷 트래픽을 보면 비밀번호가 그대로 보였고, 대부분의 시스템이 다중 사용자 환경이었음
    telnet -l 'root -f' server.test 같은 명령이 11년이나 살아남았다니 믿기지 않음

    • 소프트웨어 일을 오래 할수록, 세상이 이렇게 돌아가는 게 신기할 뿐임
      아직도 낮게 달린 과일 같은 취약점이 많을 것 같음
    • 나는 root로 로그인하진 않았지만, 학교 AIX 계정으로 lynx로 웹을 탐색하던 시절이 있었음
      그땐 트래픽이 감시된다고 생각도 안 했고, 단순히 자유로운 시절이었음
      telnet으로 메일(pine), 웹(lynx), IRC까지 다 했음
    • 언제 telnet을 안 쓰게 됐는지 기억도 안 남
      수많은 서버가 root telnet 접속을 열어뒀는데, 한 번도 해킹당하지 않았음
      정말 그 시절이 그립음
    • 예전에 rlogin -l '-froot' 같은 취약점도 있었던 게 생각남
      그 시절엔 이런 게 흔했음
    • 로그인용으로는 안 썼지만, 디버깅 도구로는 여전히 유용했음
      컨테이너 간 트래픽이 통하는지 확인할 때 자주 썼음

  • Telnet 클라이언트 자체는 아직 죽지 않았음
    예전에 SMTP 서버(포트 25)에 telnet으로 접속해서 스푸핑 메일을 보내곤 했음
    하지만 보안 명목으로 포트 차단이 늘어나면서 결국 모든 서비스가 443 포트로 몰릴 거라 생각함

    • 요즘은 netcat, socat, openssl s_client 같은 도구가 훨씬 나은 대안임
      telnet보다 훨씬 강력함
    • 어릴 때 telnet으로 SMS를 보낸 적이 있었음
      수신자에게는 공식 통신사 계정처럼 보였고, 그땐 순수했지만 지금 생각하면 위험한 장난이었음
    • telnet 클라이언트나 telnetd 자체는 여전히 쓸 수 있음
      다만 글로벌 라우팅 차원에서 기본 포트가 차단된 것 같음
      보안되지 않은 구형 시스템을 보호하기 위한 조치로 보임

  • 아직도 왜 telnet을 인터넷에서 쓰는지 모르겠음
    대부분 공격 트래픽 아닌가 싶음

    • 일부는 역사적 시스템 보존을 위해 돌리고 있음
    • 사실 ASCII 스타워즈를 보기 위해서임
      telnet towel.blinkenlights.nl
      YouTube 영상 링크
    • 레거시·IoT·산업용 장비에서는 여전히 telnet이 쓰임
      SSH도 실제로는 보안이 허술하게 쓰이는 경우가 많음
      호스트 키 검증을 끄거나, 비밀번호 없는 키를 쓰는 등
      그래서 현실적으로는 telnet + HTTPS websocket + OAuth 조합이 더 안전할 수도 있음
    • 아마추어 무선(HAM)에서는 암호화가 금지되어 있어서 telnet을 씀
      대신 서명된 데이터 전송이 허용되므로, 그런 대체 프로토콜이 필요함
    • 아직도 MUD나 MOO 같은 텍스트 기반 게임 서버들은 대부분 telnet을 씀

  • 이번 CVE는 임베디드 장비 해킹 커뮤니티에겐 좋은 소식임
    telnetd가 열려 있는 장비에서 root 권한을 얻을 가능성이 커졌음

    • 직접 Zyxel WiFi AP에서 테스트했는데, busybox 기반 telnetd라 그런지 취약하지 않았음

  • 문제의 CVE는 이 커밋에서 비롯됨
    user_name을 uname으로 바꾼 게 핵심인데, 이런 이름 변경이 왜 필요한지 의문이었음

    • ChangeLog를 보면, user_name이 전역 변수와 이름 충돌(shadowing) 을 일으켜서 바꾼 것임
    • 하지만 이런 수정보다 getenv() 호출을 점검하는 게 더 중요하다고 생각함
      입력값 파싱이 어려워서 종종 취약점이 생기기 때문임

  • 누군가 인터넷 트랜짓 인프라 상단에서 telnet 트래픽을 버리기로 결정했다는 건 흥미로움
    아마도 올바른 결정일 수도 있음
    MUD 트래픽엔 영향이 있을까 궁금함

    • 대부분의 MUD는 Telnet 프로토콜을 직접 쓰지 않음
      단순한 TCP 기반이고, 전용 클라이언트를 선호함
      포트 23은 IANA에서 예약된 Telnet용이지만, MUD는 보통 4자리 높은 포트를 씀
      오히려 지금은 23번 포트로 돌리면 접근하기 더 어려워질 것임
    • 기사에서 명확히 안 나왔지만, 아마 공격 트래픽만 필터링하는 듯함
      Telnet은 평문이라 패턴 분석으로 쉽게 걸러낼 수 있음
    • 아마 SMTP 포트 차단처럼 포트 기반 블록일 가능성이 큼
      요즘은 공개망 서버라면 SSH를 써야 함

  • 이번 CVE와 그 대응은 정말 역사적인 사건임
    한 사람이 사실상 telnet 시대를 끝냈다는 게 믿기지 않음

    • 사실 PR을 올린 사람과 승인한 사람, 두 명이 있었음
      보안 연구자 탓은 아님

  • 인턴 시절, 책상에 있던 VoIP 전화기에 telnet 접속이 가능하다는 걸 발견했을 때 정말 신기했음

    • 나도 인턴 때 Perl CGI 스크립트를 telnet으로 테스트하곤 했음
      Hayes 명령어에 익숙해서 HTTP 요청을 직접 타이핑하는 게 자연스러웠음
    • 나도 그랬음, 재밌는 추억임

  • 최근 내 telnet 서버 통계를 보니 평균 2000개 IP 정도 접속함
    1월 중순에 7500개로 급등했다가 다시 줄었고, 2월엔 1000개 수준으로 떨어졌음

답변달기