포트 23: Telnet (그리고 왜 사용하면 안 되는가)

1969년 Telnet이 탄생했을 때, 인터넷은 서로 아는 연구자들이 운영하는 수백 대의 컴퓨터로 이루어져 있었습니다. 네트워크를 통해 명령어를 평문으로 전송하는 것은 순진한 선택이 아니었습니다 — 그것은 실용적인 선택이었습니다. 네트워크에 있는 모든 사람을 신뢰할 수 있는데, 굳이 암호화라는 복잡성을 추가할 이유가 있었을까요?

그 전제는 처참하게 빗나가고 말았습니다. 오늘날 포트 23은 경고 신호입니다. Telnet을 여전히 실행 중인 시스템은 위험할 정도로 잘못 설정되었거나, 레거시 인프라에 갇혀 있는 것입니다. 왜 그런지 이해하려면 Telnet이 실제로 무엇을 하는지, 그리고 낯선 사람들로 가득한 네트워크에서 그것을 사용할 때 무슨 일이 벌어지는지를 살펴봐야 합니다.

Telnet의 동작 방식

Telnet은 원격 컴퓨터의 터미널을 제공합니다. 포트 23에 연결하면 로그인 프롬프트가 표시되고, 자격 증명을 입력하면 명령줄에 접근할 수 있습니다. 그다음부터는 원격 시스템이 허용하는 모든 작업을 수행할 수 있습니다 — 서버 설정, 파일 관리, 진단 실행 등.

30년 동안, 이것은 시스템 관리자들이 직접 손이 닿지 않는 컴퓨터를 관리하는 방법이었습니다. 전국의 데이터 센터, 해외 지사, 캠퍼스 내 대학 서버 — 모두 Telnet을 통해 책상에서 접근할 수 있었습니다.

프로토콜 자체는 단순합니다. 키 입력이 원격 컴퓨터로 전달되고, 응답이 되돌아옵니다. 문자 하나하나, 명령어 하나하나, 전체 세션이 네트워크를 통해 흐릅니다.

모든 문자가 평문으로.

한번 알면 못 잊는 문제

Telnet 세션에서 비밀번호를 입력하면, 각 문자가 읽을 수 있는 텍스트로 인터넷을 가로질러 이동합니다. 로컬 네트워크를 통해. ISP를 통해. 백본 라우터를 통해. 경로상의 모든 홉에서 이를 읽을 수 있습니다.

이것은 이론적인 취약점이 아닙니다. 당신과 서버 사이의 어떤 네트워크 구간에서든 패킷 캡처 소프트웨어를 실행하는 사람은 모든 것을 볼 수 있습니다: 사용자 이름, 비밀번호, 입력하는 모든 명령어, 받는 모든 응답까지.

더 심각한 문제도 있습니다. 암호화가 없으면, 실제 서버와 통신하고 있다는 것을 확인할 방법이 없습니다. 연결을 가로채는 공격자는 가짜 로그인 프롬프트를 제시하고 자격 증명을 탈취한 뒤, 연결을 보이지 않게 중계하거나 시스템에 대한 유효한 인증 정보를 가지고 사라질 수 있습니다.

SSH: Telnet을 쓸모없게 만든 프로토콜

1995년, 타투 일로넨이라는 핀란드 연구자가 자신의 대학 네트워크에서 비밀번호 스니핑 공격을 당한 후 SSH를 만들었습니다. 설계 방향은 명확했습니다: Telnet이 제공하는 모든 것을 제공하되, 민감한 정보가 회선을 통해 전달되기 전에 전체 세션을 암호화하는 것이었습니다.

SSH는 먼저 암호화된 터널을 구성한 다음 인증합니다. 비밀번호는 절대 평문으로 이동하지 않습니다. 서버는 암호학적으로 자신의 신원을 증명하므로, 올바른 컴퓨터와 통신하고 있다는 것을 알 수 있습니다. 전체 세션 — 명령어, 응답, 파일 전송 — 이 종단 간 암호화된 상태를 유지합니다.

SSH는 Telnet에는 없던 기능도 추가했습니다: 공개 키 인증(비밀번호 불필요), 보안 파일 전송, 포트 포워딩, 터널링. 단순히 더 안전한 것이 아니라 — 더 유용했습니다.

2000년대 초반까지, SSH는 보안이 중요한 모든 곳에서 Telnet을 대체했습니다. 오늘날, 원격 관리에 SSH 대신 Telnet을 선택하는 것은 봉투에 넣는 대신 엽서에 비밀번호를 써서 우편으로 보내는 것과 같습니다.

왜 포트 23이 아직 존재하는가

Telnet이 완전히 사라진 것은 아닙니다. 몇 가지 정당한 사용 사례가 남아 있습니다:

프로토콜 테스트: Telnet 클라이언트를 사용하면 HTTP 요청, SMTP 명령어 또는 다른 텍스트 프로토콜을 직접 입력하여 서버의 응답을 확인할 수 있습니다. 어차피 암호화되지 않은 프로토콜을 테스트하는 것이므로, Telnet에 암호화가 없어도 추가적인 위험은 없습니다.

레거시 장비: 일부 산업 제어 시스템과 오래된 네트워크 장비는 Telnet만 지원합니다. 이러한 장비는 일반적으로 격리된 네트워크에 위치해 보안 위험이 제한됩니다.

초기 구성: 네트워크 장비는 SSH가 설정되기 전 초기 설정을 위해 Telnet이 필요한 경우가 있습니다. 이것은 네트워크가 아닌 직접 연결된 콘솔 케이블을 통해 이루어집니다.

레트로 컴퓨팅: BBS 팬과 레트로 컴퓨팅 애호가들은 보안이 중요하지 않은 역사적 진정성을 위해 Telnet을 사용합니다.

공통된 패턴: 통제된 환경, 격리된 네트워크, 테스트 시나리오, 또는 기밀성이 중요하지 않은 상황.

포트 23을 열어두면 어떤 일이 생기는가

공격자들은 끊임없이 인터넷에서 포트 23 서비스가 열려 있는지 스캔합니다. 자동화된 스크립트는 기본 자격 증명을 시도합니다 — admin/admin, root/root, 아무도 바꾸지 않은 제조업체 기본값들 — 노출된 Telnet 서비스에 하루에도 수백 번씩.

이것은 추측이 아닙니다. Mirai 봇넷은 기본 비밀번호가 설정된 Telnet 서비스를 악용하여 수십만 대의 IoT 기기를 침해했습니다. 카메라, 라우터, DVR — Telnet이 활성화된 채로 출시되어 한 번도 보안이 강화되지 않은 기기들 — 이 대규모 분산 공격의 무기가 되었습니다.

자격 증명이 강력하더라도 평문 문제는 여전히 남습니다. 네트워크 트래픽을 감시할 수 있는 사람은 누구든 — ISP, 침해된 라우터, 로컬 네트워크의 공격자 — 자격 증명을 탈취할 수 있습니다. 그리고 사람들은 비밀번호를 재사용하기 때문에, 탈취된 Telnet 자격 증명이 종종 다른 시스템의 문을 열어줍니다. 하나의 취약한 고리가 더 광범위한 침해의 발판이 됩니다.

포트 23이 가르쳐 주는 교훈

Telnet의 이야기는 잘못 설계된 프로토콜에 관한 것이 아닙니다. 더 이상 존재하지 않는 네트워크를 위해 설계된 프로토콜에 관한 것입니다.

1969년의 인터넷은 신뢰할 수 있는 공간이었습니다. 오늘날의 인터넷은 낯선 사람들이 제어하는 인프라를 통해, 들어본 적도 없는 네트워크를 거쳐, 셀 수 없이 많은 도청의 기회를 지나 트래픽을 라우팅합니다. 신뢰할 수 있는 네트워크를 위해 설계된 프로토콜은 적대적인 환경에서 처참하게 실패합니다.

이 교훈은 Telnet을 넘어 확장됩니다. 암호화되지 않은 모든 프로토콜 — FTP, TLS 없는 HTTP, STARTTLS 없는 SMTP — 은 동일한 근본적인 위험을 지닙니다. 차이는 정도의 문제일 뿐입니다.

Telnet 서비스를 실행 중이라면, 비활성화하세요. Telnet이 필요한 장비를 관리하고 있다면, 격리하세요. 무엇이든 원격 접근이 필요하다면, SSH를 사용하세요.

포트 23은 자신의 목적을 다했습니다. 그 목적은 수십 년 전에 끝났습니다.

Telnet과 포트 23에 관한 자주 묻는 질문

Telnet을 안전하게 사용할 수 있는 경우가 있나요?

모든 장치를 제어하고 접근 권한이 있는 모든 사람을 신뢰하는 물리적으로 격리된 네트워크에서는, Telnet에 암호화가 없어도 문제가 되지 않습니다 — 도청할 사람이 없으니까요. 인터넷에 연결된 네트워크나 신뢰할 수 없는 사용자가 있는 네트워크에서는, Telnet을 사용하면 자격 증명이 쉽게 탈취될 수 있습니다.

IoT 기기들이 여전히 Telnet을 활성화한 채로 출시되는 이유는 무엇인가요?

비용과 편의성 때문입니다. Telnet 구현은 단순하고 가벼워서, 최소한의 처리 능력만 필요합니다. 제조업체는 보안보다 초기 설정의 편의성을 우선시하며, 사용자가 기본값을 변경하거나 네트워크 접근을 제한할 것이라고 가정합니다. 하지만 많은 사람들이 그렇게 하지 않습니다.

Telnet을 사용해 포트가 열려 있는지 테스트할 수 있나요?

네 — 이것이 Telnet의 정당한 남은 용도 중 하나입니다. telnet hostname 80을 실행하면 포트 80이 연결을 수락하는지 테스트할 수 있습니다. 인증하거나 민감한 데이터를 보내는 것이 아니므로, 평문 전송은 문제가 되지 않습니다.

Telnet과 SSH의 차이점은 무엇인가요?

두 프로토콜 모두 원격 터미널 접근을 제공하지만, SSH는 확립된 암호화 프로토콜을 사용하여 전체 세션을 암호화합니다. SSH는 또한 호스트 키를 통해 서버 신원을 확인하고, 공개 키 인증을 지원하며, 보안 파일 전송과 포트 포워딩을 제공합니다. Telnet은 이 중 어느 것도 하지 않습니다 — 보호되지 않은 연결을 통해 문자를 주고받을 뿐입니다.