FTP와 SFTP 차이 완전정복

FTP는 어디서 왔나

위키백과(File Transfer Protocol)에 따르면 FTP의 최초 명세는 아베이 부샨(Abhay Bhushan)이 쓴 RFC 114로, 1971년 4월 16일에 발표되었습니다. 당시에는 TCP/IP가 아니라 ARPANET의 NCP 위에서 동작했고, 1980년 6월의 RFC 765가 이를 TCP/IP로 옮겼으며, 현재 기준이 되는 명세가 1985년 10월의 RFC 959(J. Postel, J. Reynolds)입니다. RFC 959에서 제어 연결은 Telnet 프로토콜을 따르고, 데이터 연결은 필요할 때만 맺어지는 "전이중(full duplex) 연결"로 정의됩니다. RFC 959는 비밀번호가 민감한 정보이므로 화면에 표시하지 않는 것이 바람직하다고 언급하지만 전송 구간을 암호화하는 방법은 정하지 않았습니다.

세 프로토콜 비교표

FTPS에서 흔히 놓치는 점이 하나 있습니다. RFC 4217에 따르면 AUTH TLS는 기본적으로 제어 연결만 보호하며, 데이터 연결까지 보호하려면 PBSZ와 PROT 명령으로 보호 수준(P=private)을 지정해야 하고 초기값은 평문(Clear)입니다. RFC도 이 방식이 모든 세션과 전송이 안전함을 보장하지는 않는다고 적고 있습니다. 따라서 "FTPS를 쓰고 있다"와 "파일 내용까지 암호화되고 있다"는 서버 설정에 따라 다를 수 있습니다.

실제 기록으로 보는 사례

사례 1: FTP 바운스 공격 (RFC 2577, 1999년 5월)

M. Allman과 S. Ostermann이 작성한 정보성(Informational) 문서 RFC 2577 「FTP Security Considerations」는 FTP 명세 자체가 가진 약점을 정리합니다. 대표적인 것이 "바운스 공격"으로, FTP가 클라이언트의 요청에 따라 서버가 제3의 호스트로 데이터를 보낼 수 있게 허용하는 점을 악용합니다. 공격자는 PORT 명령으로 다른 호스트의 서비스(예: SMTP, NNTP) 주소를 지정해 서버가 대신 그 서비스에 명령을 전달하게 만들 수 있고, 이는 공격 출처를 숨기거나 주소 기반 접근 통제를 우회하는 데 쓰일 수 있다고 문서는 설명합니다. 문서가 제시한 완화책은 1024 미만 포트로의 데이터 연결 요청을 거부하는 것(응답 코드 504), 또는 PORT 명령을 비활성화하는 것입니다. 교훈은 프로토콜의 "편리한 기능"이 보안 약점이 되기도 한다는 점이며, 서버 소프트웨어를 최신으로 유지하고 불필요한 기능을 끄는 습관과 연결됩니다.

사례 2: 비밀번호가 평문으로 오가는 문제 (RFC 2577)

같은 문서는 6절에서 "모든 데이터와 제어 정보(비밀번호 포함)가 암호화되지 않은 형태로 네트워크를 지나간다"고 명시하고, FTP 보안 확장(RFC 2228) 같은 더 강한 인증·암호화를 권고합니다. 또한 서버가 비밀번호 시도를 무제한 허용하면 무차별 대입에 노출되므로 3~5회 실패 후 연결을 끊고 잘못된 PASS 응답을 5초 늦추는 방안을 제안하되, 공격자가 병렬 연결로 우회할 수 있다는 한계도 함께 적습니다. 이 사례는 "암호화 없는 프로토콜 + 약한 비밀번호"의 조합이 왜 위험한지를 표준 문서 수준에서 보여 줍니다.

사례 3: 웹 브라우저의 FTP 지원 중단 (2021년)

위키백과(File Transfer Protocol) 기준으로 구글 크롬은 88 버전에서 FTP 지원을 완전히 제거했고, 이는 마이크로소프트 엣지 같은 크로미움 기반 브라우저에도 영향을 주었습니다. 파이어폭스는 88 버전에서 FTP를 기본 비활성화한 뒤 90 버전에서 제거했으며 모두 2021년의 일입니다. 브라우저 주소창에 ftp:// 로 파일을 받던 방식이 더 이상 기본 경로가 아니게 되었다는 뜻이므로, 전송 방식을 선택할 때 전용 클라이언트와 암호화 방식을 고려해야 합니다.

방화벽에서 FTP가 까다로운 이유

능동 모드에서는 클라이언트가 PORT 명령으로 자신의 주소·포트를 알리면 서버가 20번 포트에서 클라이언트로 되접속합니다. 방화벽이나 NAT가 이 외부발 접속을 막으면 데이터 전송이 실패합니다. 패시브 모드(PASV)는 서버가 알려 준 포트로 클라이언트가 접속하므로 방화벽 환경에서 널리 쓰이며, 위키백과에 따르면 RFC 1579(1994)가 이 "방화벽 친화적" 방식을 소개했습니다. 방화벽 쪽에서도 NIST SP 800-41 Rev.1은 FTP가 최소 두 개의 포트를 쓰고 그중 하나는 예측하기 어렵다고 적습니다. 반면 SFTP는 SSH의 22번 포트 하나로 모든 통신이 이뤄져 규칙이 단순합니다. 방화벽의 일반 개념은 방화벽 기초 가이드를 참고하세요.

직접 확인해 보기: 어떤 방식을 쓰고 있나

• 접속 설정의 프로토콜 항목이 "FTP"인지 "FTP over TLS(명시적/암묵적)"인지 "SFTP(SSH)"인지 확인합니다.
• FTPS라면 서버가 데이터 연결도 보호(PROT P)하도록 설정되어 있는지 호스팅 업체 문서에서 확인합니다.
• SFTP는 SSH 접속 정보를 그대로 쓰므로, 비밀번호 대신 공개키 인증을 쓸 수 있는지 확인합니다.
• 방화벽이나 공유기에서 FTP 포트를 열어 두었다면 필요한 포트 범위만 열었는지 점검합니다.

흔한 오해와 정정

• 오해: SFTP는 FTP에 SSL을 붙인 것이다. 실제: FTP에 TLS를 붙인 것은 FTPS입니다. SFTP는 SSH 위에서 새로 설계된 별개 프로토콜이며 FTP 서버와는 서로 통신할 수 없습니다(위키백과 기준).
• 오해: IANA 목록에 sftp가 있으니 SFTP는 공식 표준 포트가 따로 있다. 실제: IANA의 "sftp" 115번은 구형 Simple File Transfer Protocol 등록이고, SSH 기반 SFTP는 ssh의 22번 포트를 씁니다.
• 오해: SFTP는 RFC로 표준화된 프로토콜이다. 실제: 명세는 draft-ietf-secsh-filexfer-13(2006년 7월 갱신)으로, IETF가 보증하지 않는 만료된 인터넷 초안 상태입니다. 그럼에도 OpenSSH 등에서 널리 구현되어 쓰입니다.
• 오해: FTPS를 켰으니 파일도 항상 암호화된다. 실제: RFC 4217은 데이터 연결의 기본값이 평문이며 PROT 설정이 필요하다고 설명합니다.

한계와 더 알아볼 점

세 방식 모두 "전송 구간"의 안전을 다룰 뿐, 서버 소프트웨어의 취약점이나 약한 비밀번호, 잘못된 파일 권한까지 해결해 주지는 않습니다. 또 SFTP는 표준 문서 상태가 완전히 공식화되지 않았기 때문에 구현체마다 지원하는 기능이 조금씩 다를 수 있습니다. 새 환경을 구성할 때는 사용 중인 서버·클라이언트의 공식 문서를 확인하세요. SSH 자체의 동작은 SSH 프로토콜 가이드에서 볼 수 있습니다.

SFTP의 바탕이 되는 SSH가 궁금하다면

SFTP가 기대는 SSH 프로토콜 자체의 동작 원리가 궁금하다면 SSH(시큐어 셸) 프로토콜이란?를 확인해보세요.

TLS 암호화 원리가 궁금하다면

FTPS가 사용하는 TLS 암호화의 동작 원리가 궁금하다면 TLS 핸드셰이크로 알아보는 HTTPS 연결 원리도 참고해보세요. 서버 공개 포트가 궁금하다면 포트 번호 정리도 함께 볼 수 있습니다.

자주 묻는 질문