안전하지 않은 프로토콜 교체: Telnet과 SSH, FTP와 SFTP
Telnet, FTP, HTTP 같은 평문 프로토콜이 자격 증명을 노출하는 이유와 암호화된 대체 프로토콜(SSH, SFTP, HTTPS)이 이러한 문제를 해결하는 방식을 이해합니다.
안전하지 않은 프로토콜 교체: Telnet과 SSH, FTP와 SFTP은(는) CoddyKit의 무료 Security+ Academy 강의입니다. 이것은 4개 중 1번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Security+ Academy 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Security+ Academy 강의에는 총 4개의 강의가 포함되어 있습니다.
평문 프로토콜의 문제
많은 인터넷 기반 프로토콜은 보안이 주요 관심사가 아니었던 1970년대와 1980년대에 설계되었습니다. 평문 프로토콜은 사용자 이름, 비밀번호, 민감한 정보 등 모든 데이터를 네트워크를 통해 평문으로 전송합니다. 같은 네트워크 구간에 있는 모든 장치나 패킷이 거쳐 가는 모든 시스템은 Wireshark와 같은 무료 도구를 사용해 이 트래픽을 캡처하고 읽을 수 있습니다. 네트워크 스위치가 있는 환경에서는 스위치가 일반적으로 포트 간 트래픽을 격리하지만, ARP 스푸핑을 사용하면 트래픽을 공격자의 시스템으로 리디렉션할 수 있으므로 '내부' 네트워크에서도 평문 프로토콜은 위험합니다.
# What an attacker sees on the wire with Telnet
# (captured via Wireshark or tcpdump)
tcpdump -i eth0 -A port 23
# Sample Telnet capture output:
..login: admin..
..password: S3cr3tPa$$...
..$ ls -la /etc/passwd..
# Every keystroke is visible in plaintext
# Credentials, commands, and file contents - all exposedTelnet과 SSH 비교
Telnet(TCP 포트 23)은 시스템에 원격 명령줄 접근을 제공하지만 모든 내용을 평문으로 전송합니다. 사용자 이름과 비밀번호를 암호화 없이 전송하는 것 외에는 기본 제공 인증 기능이 없습니다. SSH (Secure Shell)(TCP 포트 22)는 암호화되고 인증된 채널로 Telnet을 대체합니다. SSH는 비대칭 키 교환을 사용해 세션 키를 설정한 다음, 대칭 암호화로 이후의 모든 통신을 암호화합니다. 또한 SSH는 서버를 인증하여 서버 사칭을 방지하고, 비밀번호 인증과 함께 공개 키 인증(비밀번호 없이 사용할 수 있으며 비밀번호보다 안전함)을 지원합니다.
# SSH connection (encrypted, server authenticated)
ssh admin@192.168.1.10
# SSH key-based authentication (no password)
ssh -i ~/.ssh/id_rsa admin@192.168.1.10
# Generate SSH key pair
ssh-keygen -t ed25519 -C 'admin@company.com'
# Copy public key to server
ssh-copy-id -i ~/.ssh/id_rsa.pub admin@192.168.1.10
# Disable Telnet on network devices (Cisco IOS)
no service telnet
line vty 0 4
transport input ssh
login localSSH 키 교환 및 인증
SSH의 보안은 강력한 키 교환 과정에 기반합니다. 연결할 때 클라이언트는 서버의 호스트 키를 로컬에 저장된 사본과 대조하여 검증합니다. 이렇게 하면 서버 사칭을 방지할 수 있습니다. 호스트 키가 예기치 않게 변경되면 SSH는 사용자에게 경고하는데, 이는 중간자 공격의 일반적인 징후입니다. 서버를 검증한 후 클라이언트 인증에는 다음 방법을 사용할 수 있습니다. 비밀번호(전송 중에는 암호화되지만 무차별 대입 공격에 취약함), 공개 키(클라이언트가 개인 키를 보유하고 있음을 증명하며 훨씬 강력함), 또는 키보드 대화식 인증(MFA 지원)입니다. 조직은 인터넷에 노출된 SSH 서비스에서 키 기반 인증을 적용하고 비밀번호 인증을 비활성화해야 합니다.
# Harden SSH server configuration
# /etc/ssh/sshd_config
Port 22
PermitRootLogin no
PasswordAuthentication no # Require key auth only
ChallengeResponseAuthentication no
MaxAuthTries 3
AllowUsers admin deploy
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
ClientAliveInterval 300 # Disconnect idle sessions
ClientAliveCountMax 0
# Restart SSH after changes
systemctl restart sshdFTP와 SFTP 및 FTPS 비교
FTP (File Transfer Protocol)(TCP 포트 20/21)는 파일을 평문으로 전송하므로 자격 증명, 명령, 파일 데이터가 모두 노출됩니다. 또한 FTP는 별도의 데이터 채널(수동 또는 능동 모드)을 사용하므로 방화벽 규칙이 복잡해집니다. SFTP (SSH File Transfer Protocol)는 포트 22에서 SSH를 통해 파일 전송을 터널링합니다. FTP와는 완전히 다른 프로토콜이며 이름만 비슷합니다. FTPS (FTP Secure)는 기존 FTP 프로토콜에 TLS 암호화를 추가합니다. SFTP는 단일 포트를 사용하고 SSH의 인증 및 암호화를 그대로 활용하므로 일반적으로 더 선호됩니다. 모든 운영 시스템에서 FTP를 비활성화해야 합니다.
# SFTP usage (over SSH, single connection)
sftp admin@fileserver.company.com
sftp> put localfile.zip /uploads/
sftp> get /reports/monthly.pdf .
sftp> ls /uploads/
sftp> exit
# Automated SFTP transfer with key auth
sftp -i ~/.ssh/id_rsa admin@fileserver.company.com <<EOF
put /tmp/report.csv /incoming/
EOF
# Disable FTP on Linux (remove vsftpd)
apt purge vsftpd
# Verify no FTP listener:
ss -tlnp | grep ':21'HTTP와 HTTPS 비교
HTTP(TCP 포트 80)는 양식 데이터, 세션 쿠키, 인증 토큰을 포함한 웹 콘텐츠를 평문으로 전송합니다. HTTPS(TCP 포트 443)는 HTTP를 TLS로 감싸 암호화, 서버 인증, 데이터 무결성을 제공합니다. 조직은 어디서나 HTTPS를 적용해야 합니다. 모든 HTTP 트래픽을 HTTPS로 리디렉션하고(301 리디렉션), 브라우저가 HTTP로 연결하지 못하도록 HSTS를 구현하며, HTTP 또는 JavaScript를 통한 세션 토큰 탈취를 방지하도록 secure 및 HttpOnly 쿠키 플래그를 구성하십시오. 최신 브라우저는 HTTP 사이트를 '안전하지 않음'으로 표시하므로, 이제 모든 웹 서비스에서 HTTPS가 기본 요구 사항입니다.
# nginx: force HTTPS redirect
server {
listen 80;
server_name example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
ssl_certificate /etc/ssl/example.crt;
ssl_certificate_key /etc/ssl/example.key;
add_header Strict-Transport-Security
'max-age=31536000; includeSubDomains; preload';
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options SAMEORIGIN;
}SNMP v1/v2와 SNMPv3 비교
SNMP (Simple Network Management Protocol)는 네트워크 장치와 서버를 관리합니다. SNMPv1 및 v2c는 사실상 공유 비밀번호인 커뮤니티 문자열을 평문으로 전송합니다. 'public'(읽기) 및 'private'(쓰기)와 같은 커뮤니티 문자열은 공격자가 알고 있는 기본값입니다. 공격자가 SNMP 트래픽을 캡처하면 커뮤니티 문자열을 알아내 장치 구성을 읽거나 장치 설정을 변경할 수 있습니다. SNMPv3는 사용자별 자격 증명과 함께 인증(HMAC-MD5 또는 HMAC-SHA) 및 암호화(AES)를 추가하므로 운영 환경에 적합한 유일한 버전입니다. SNMPv1/v2c는 비활성화해야 합니다.
# SNMPv3 configuration (Cisco IOS)
snmp-server group MYGROUP v3 priv
snmp-server user MONITORUSER MYGROUP v3 \
auth sha MyAuthP@ss priv aes 128 MyPrivP@ss
# SNMPv3 query from monitoring server
snmpwalk -v3 -l authPriv \
-u MONITORUSER \
-a SHA -A MyAuthP@ss \
-x AES -X MyPrivP@ss \
192.168.1.1 sysDescr
# Disable SNMPv1/v2c:
no snmp-server community public ro
no snmp-server community private rwLDAP와 LDAPS 비교
LDAP (Lightweight Directory Access Protocol)(TCP 포트 389)은 기본적으로 디렉터리 서비스(Active Directory, OpenLDAP)를 평문으로 인증하고 조회하므로 자격 증명과 디렉터리 데이터가 노출됩니다. LDAPS(LDAP over SSL/TLS, TCP 포트 636)는 인증서를 사용해 연결을 암호화합니다. StartTLS는 동일한 포트 389를 사용해 기존 LDAP 연결을 TLS로 업그레이드하는 대안입니다. LDAPS와 StartTLS 모두 암호화를 제공하지만, 일반적으로 LDAPS가 더 간단하고 안정적입니다. 조직은 모든 LDAP 사용 애플리케이션이 LDAPS를 사용하도록 구성하고 방화벽에서 포트 389의 평문 LDAP를 차단해야 합니다.
POP3/IMAP과 암호화된 이메일 수신 비교
레거시 이메일 클라이언트는 POP3(포트 110) 및 IMAP(포트 143)을 사용해 평문으로 이메일을 수신합니다. 암호화된 대안으로는 POP3S(포트 995, TLS) 및 IMAPS(포트 993, TLS)가 있습니다. 최신 이메일 플랫폼(Exchange Online, Google Workspace)은 모든 클라이언트 연결에 TLS를 적용하고 비밀번호 대신 OAuth 2.0 토큰 기반 인증을 지원합니다. 조직은 이메일 프로토콜에서 기본 인증을 비활성화해야 합니다. 최신 인증(OAuth 2.0 + MFA)을 요구하면 레거시 이메일 프로토콜의 평문 인증 방식을 악용하는 자격 증명 스터핑 공격을 방지할 수 있습니다.
# Protocol port reference card
Protocol Insecure Port Secure Port Replacement
--------- ------------ ---------- -----------
Telnet 23 22 SSH
FTP 20/21 22 SFTP
HTTP 80 443 HTTPS
SMTP 25 587/465 SMTPS
POP3 110 995 POP3S
IMAP 143 993 IMAPS
LDAP 389 636 LDAPS
SNMP 161/162 161/162 SNMPv3
RDP 3389 3389 RDP+NLA+TLS실제 환경에서의 프로토콜 교체
안전하지 않은 프로토콜을 교체하려면 안전한 버전을 활성화하는 것만으로는 부족하며, 안전하지 않은 버전을 적극적으로 비활성화해야 합니다. 단계는 다음과 같습니다. 기존 프로토콜 사용 현황을 감사하고(Nmap 검사, 방화벽 기록), 애플리케이션과 구성을 안전한 프로토콜로 이전한 뒤, 철저히 검증하고(비즈니스 애플리케이션이 중단될 수 있음), 마지막으로 방화벽과 호스트에서 안전하지 않은 프로토콜을 차단하십시오. 일반적인 주의 사항: 레거시 프린터와 임베디드 장치는 FTP 또는 SNMPv2만 지원하는 경우가 많고, 레거시 산업 시스템은 Telnet에 의존할 수 있습니다. 이런 경우에는 단순한 프로토콜 업그레이드가 아니라 네트워크 격리 또는 공급업체 제품 교체가 필요합니다.
# Audit for insecure protocol usage
# Nmap: find all Telnet listeners on network
nmap -p 23 10.0.0.0/24 --open -sV
# Find FTP listeners
nmap -p 21 10.0.0.0/24 --open
# Find HTTP (not HTTPS) web services
nmap -p 80 --open 10.0.0.0/24
# Check for SNMPv1/v2c community strings
nmap -sU -p 161 --script snmp-info 10.0.0.0/24
# Block Telnet at firewall after migration
iptables -A FORWARD -p tcp --dport 23 -j DROP
iptables -A INPUT -p tcp --dport 23 -j DROP원격 데스크톱 프로토콜 보안
RDP (Remote Desktop Protocol)(포트 3389)은 원격 Windows 관리에 널리 사용되며 주요 공격 대상입니다. 안전하지 않은 RDP 구성에는 포트 3389를 인터넷에 노출하는 것, 비밀번호만으로 인증하는 것, NLA를 비활성화하는 것이 포함됩니다. RDP 강화: 전체 세션이 열리기 전에 인증하여 인증되지 않은 연결을 차단하는 Network Level Authentication (NLA)을 활성화하고, 모든 RDP 세션에 TLS 1.2+를 요구하며, RDP를 인터넷에 직접 노출하지 말고 VPN 또는 RDP 게이트웨이 뒤에 배치하십시오. 또한 무차별 대입을 방지하도록 계정 잠금을 적용하십시오. 많은 랜섬웨어 캠페인은 노출되어 보안이 취약한 RDP를 통해 최초 접근 권한을 확보합니다.
단계적 안전하지 않은 프로토콜 폐기
운영 환경에서 안전하지 않은 프로토콜을 이전하려면 업무 중단을 피하기 위한 신중한 계획이 필요합니다. 단계적 접근 방법은 다음과 같습니다. 1단계 — 발견: Nmap 검사를 실행하고 방화벽 기록을 감사하여 평문 프로토콜의 모든 사용처를 식별합니다. 2단계 — 안전한 대안 활성화: 기존의 안전하지 않은 서비스와 함께 SSH, SFTP, HTTPS를 구성합니다. 3단계 — 사용 주체 이전: 스크립트, 애플리케이션, 모니터링 도구, 사용자 작업 절차를 업데이트하여 안전한 프로토콜을 사용하게 합니다. 4단계 — 비활성화 및 차단: 각 호스트에서 안전하지 않은 서비스를 비활성화하고 방화벽에서 해당 포트를 차단합니다. 각 단계에서 검증을 수행하면 운영 중단을 방지할 수 있습니다.
# Phase 4: Disable and block Telnet permanently
# Disable Telnet service on Linux
systemctl stop telnet.socket
systemctl disable telnet.socket
# Block Telnet at iptables
iptables -A INPUT -p tcp --dport 23 -j DROP
iptables -A OUTPUT -p tcp --dport 23 -j DROP
# Save rules
iptables-save > /etc/iptables/rules.v4
# Block at network firewall (Cisco ASA)
access-list OUTSIDE_IN deny tcp any any eq 23
# Verify: should timeout / connection refused
nc -zv 192.168.1.10 23빠른 확인
이 단원에서 배운 CompTIA Security+ (SY0-701) 개념을 이해했는지 확인해 보십시오.
단원 요약
이 단원에서는 다음을 배웠습니다. 평문 프로토콜(Telnet, FTP, HTTP, SNMPv1/v2c, LDAP)은 네트워크 도청에 자격 증명과 데이터를 노출하므로 교체해야 합니다. 보안 대체 프로토콜(SSH, SFTP, HTTPS, SNMPv3, LDAPS)은 TLS 또는 SSH 암호화를 사용해 동일한 기능을 보호합니다. 또한 프로토콜을 교체하려면 레거시 종속성을 감사한 후 방화벽과 호스트 수준에서 안전하지 않은 버전을 비활성화해야 합니다. 다음으로 TLS 버전, 암호 스위트, 완전 순방향 보안을 살펴보겠습니다.
자주 묻는 질문
“안전하지 않은 프로토콜 교체: Telnet과 SSH, FTP와 SFTP” 강의는 무료인가요?
네 — “안전하지 않은 프로토콜 교체: Telnet과 SSH, FTP와 SFTP” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Security+ Academy 강의 전체를 잠금 해제할 수 있습니다. Security+ Academy 강의에는 총 4개의 강의가 포함되어 있습니다.
“안전하지 않은 프로토콜 교체: Telnet과 SSH, FTP와 SFTP”에서 뭘 배우나요?
Telnet, FTP, HTTP 같은 평문 프로토콜이 자격 증명을 노출하는 이유와 암호화된 대체 프로토콜(SSH, SFTP, HTTPS)이 이러한 문제를 해결하는 방식을 이해합니다. 브라우저에서 직접 실행하는 실습 코드로 Security+ Academy을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.
Security+ Academy을(를) 시작하는 데 경험이 필요한가요?
사전 경험은 필요하지 않습니다. CoddyKit의 Security+ Academy은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 1번째 강의입니다.
“안전하지 않은 프로토콜 교체: Telnet과 SSH, FTP와 SFTP” 강의는 얼마나 걸리나요?
대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.
이 Security+ Academy 강의에서 코드를 작성하고 실행할 수 있나요?
네. 모든 Security+ Academy 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.
이 강의의 모든 강의
- 안전하지 않은 프로토콜 교체: Telnet과 SSH, FTP와 SFTP
- TLS 버전, 암호 스위트 및 완전 순방향 비밀성
- 보안 DNS: DNSSEC 및 HTTPS를 통한 DNS(DoH)
- IPsec, VPN 프로토콜 및 원격 접속 보안