# 텔넷이 사라진 날 > Clean Markdown view of GeekNews topic #26606. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26606](https://news.hada.io/topic?id=26606) - GeekNews Markdown: [https://news.hada.io/topic/26606.md](https://news.hada.io/topic/26606.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-12T00:33:31+09:00 - Updated: 2026-02-12T00:33:31+09:00 - Original source: [labs.greynoise.io](https://www.labs.greynoise.io/grimoire/2026-02-10-telnet-falls-silent/) - Points: 4 - Comments: 1 ## Summary 전 세계 **텔넷 트래픽이 단 한 시간 만에 60% 가까이 붕괴**하며, 18개 ASN과 5개국의 연결이 완전히 사라졌습니다. 불과 엿새 뒤 공개된 **GNU Inetutils telnetd의 인증 우회 취약점(CVE-2026-24061)** 과 시점이 맞물리면서, 주요 백본 사업자가 사전 통보를 받고 **포트 23 필터링을 선제 적용했을 가능성**이 제기됩니다. 클라우드 사업자는 사설 피어링망으로 영향을 피했지만, 북미 ISP의 급감은 텔넷이 사실상 인터넷 인프라에서 퇴장했음을 보여줍니다. ## Topic Body - 2026년 1월 14일 21시(UTC)에 **전 세계 Telnet 트래픽이 급격히 붕괴**, 관측망에서 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는 “**누군가 인터넷의 상당 부분에서 텔넷을 끊었다**”는 사실을 기록하며, **텔넷 시대의 종말**을 상징하는 사건으로 평가 ## Comments ### Comment 51019 - Author: neo - Created: 2026-02-12T00:33:31+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46967772) - 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 영상 링크](https://www.youtube.com/watch?v=Mhcf6tc2jeQ) - **레거시·IoT·산업용 장비**에서는 여전히 telnet이 쓰임 SSH도 실제로는 보안이 허술하게 쓰이는 경우가 많음 호스트 키 검증을 끄거나, 비밀번호 없는 키를 쓰는 등 그래서 현실적으로는 **telnet + HTTPS websocket + OAuth** 조합이 더 안전할 수도 있음 - 아마추어 무선(HAM)에서는 **암호화가 금지**되어 있어서 telnet을 씀 대신 서명된 데이터 전송이 허용되므로, 그런 대체 프로토콜이 필요함 - 아직도 **MUD나 MOO** 같은 텍스트 기반 게임 서버들은 대부분 telnet을 씀 - 이번 CVE는 **임베디드 장비 해킹 커뮤니티**에겐 좋은 소식임 telnetd가 열려 있는 장비에서 root 권한을 얻을 가능성이 커졌음 - 직접 **Zyxel WiFi AP**에서 테스트했는데, busybox 기반 telnetd라 그런지 취약하지 않았음 - 문제의 CVE는 [이 커밋](https://codeberg.org/inetutils/inetutils/commit/fa3245ac8c288b87139a0da8249d0a408c4dfb87)에서 비롯됨 `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개 수준으로 떨어졌음