요약

  • FTP는 제어 연결에서 명령을 협상하고, 파일 내용은 별도의 데이터 연결로 전송했다.
  • RFC 1579는 기존 PASV 명령을 사용해 데이터 연결을 여는 쪽을 뒤집어, 클라이언트 측 패킷 필터를 통과하기 쉽게 만들면서 인바운드 포트 문제를 서버 쪽으로 옮겼다.

FTP는 파일 자체를 전송하지 않는 연결에서 “이 파일을 보내라”라고 말할 수 있었다. 이 분리는 프로토콜 설계에 처음부터 내재된 것이었다. 동시에 이는 로그인과 성공적인RETR명령이 곧바로 바이트가 통과한다는 보장이 되지 않음을 의미했다. FTP가 선택한 방향으로 두 번째 TCP 연결을 맺어야만 했다.

1985년 FTP 명세인 RFC 959는 명령과 응답을 위한 제어 프로세스, 전송을 위한 데이터 프로세스를 설명한다. 일반적인 구성에서 클라이언트는 서버로 제어 연결을 열며, 보통 21번 포트를 사용한다. 전송 전에 클라이언트는 자신의 주소와 수신 대기할 포트를 담은PORT명령을 보낼 수 있었다. 그러면 서버가 클라이언트 쪽으로 데이터 연결을 시작했다. 데이터 소켓은 명령 소켓과 별개였으므로, 첫 연결을 허용하는 방화벽이 두 번째 연결까지 자동으로 허용하지는 않았다.

FTP에는 이미 다른 구성도 존재했다.PASV를 사용하면 클라이언트가 서버의 데이터 프로세스에 비기본 포트에서 수신 대기하도록 요청한다. 서버는 주소와 포트를 반환하고, 클라이언트가 그 주소로 데이터 연결을 연다. 파일은 여전히 두 번째 연결로 전송되었지만, 발신자가 바뀐 것이다. 즉, 패시브 모드는 패킷 필터를 위한 권장 우회 방법이 되기 훨씬 전부터 프로토콜에 존재했다.

1994년경에는 실제 운용 패턴이 원래 기본값과 항상 일치하지 않았다. Steven Bellovin의 RFC 1579에 따르면 당시 클라이언트들은 대체로 전송마다 새 데이터 연결을 열고, TCP의 TIME-WAIT 지연을 피하려 새 클라이언트 포트를 선택한 뒤 이를PORT로 공지했다. 패킷 필터는 이를 예측 불가능한 포트로 들어오는 호출로 볼 수 있었다. 방화벽은 특정 인바운드 서비스를 허용하면서 이런 호출을 거부하는 경우가 많았는데, 사용자가 제어 연결에서 이미 인증을 마친 경우에도 그러했다.

RFC 1579는 Gopher 프록시 에이전트를 포함한 FTP 클라이언트 제조사들이PORT대신PASV를 사용하도록 바꿀 것을 권고했다. 그러면 클라이언트의 데이터 연결은 발신 호출이 된다. 클라이언트 측 방화벽 논리에서는 무작위 클라이언트 포트로 들어오는 원치 않는 연결보다 발신 시작을 허용하는 쪽이 더 쉬웠다. 이 메모는 새로운 유선 프로토콜을 제안하지 않았다. 명령은 이미 존재했고, 어느 쪽이든 클라이언트와 서버는 전송 전에 유사한 설정 명령을 주고받았다.

이 변경은 어려운 경계를 제거한 것이 아니라 옮긴 것이었다. 패시브 모드의 서버는 전송용으로 지정된 포트에서 들어오는 데이터 호출을 받아야 했다. RFC 1579 자체도 이 답안이 서버 측 방화벽 문제를 만들 수 있음을 인정했다. 그 논거는 행정적이었다. 서버는 클라이언트보다 수가 적고, 운영자는 서버의 데이터 포트 범위를 제한할 수 있다는 것이었다. 이는 노출을 어디서 관리할지에 대한 제안이었으며, 모든 서버나 방화벽이 이를 채택했다는 증명이 아니었다.

표준 문서 기록은 요구되는 기능과 실제 동작을 구분하는 데 도움이 된다. 1989년에 발표된 RFC 1123은 FTP 서버가PASV를 구현하도록 요구하고 응답 해석 방식을 명확히 했으며, 응답 형식이 완전히 표준화되지 않았다는 점도 언급했다. RFC 1579는 이후 독립적으로 수정된 클라이언트가 최소 두 개 존재한다고 밝혔다. 어느 진술도 몇 명의 사용자나 사이트가 모드를 바꿨는지는 측정하지 않는다. 1994년 메모는 권고와 제한된 구현 사례를 기록한 것이지 보편적 전환을 기록한 것이 아니다.

이 구분이 중요한 이유는 FTP에 두 개의 운용 지점이 있었기 때문이다. 제어 연결은 자격 증명, 명령, 성공 응답을 실을 수 있었고, 데이터 연결은 디렉터리 목록이나 파일을 실었다. “데이터 연결을 여는 중”과 같은 제어 채널 응답은 파일 자체가 아니며, 로그인 성공은 전송이 완료되었다는 증거가 아니었다. 문제 해결은 양쪽 소켓을 모두 추적하고 어느 엔드포인트가 각 연결을 시작하도록 설계되었는지 확인해야 했다.

RFC 1579의 교훈은 “방화벽이 FTP를 망가뜨렸다”는 말보다 더 좁다. FTP에는 이미 데이터 연결 방향의 선택지가 있었다. 필터링이 그 선택을 중요하게 만든 것이다. PASV는 클라이언트가 자신의 방화벽 정책이 허용하기 쉬운 쪽에 발신 호출을 두고, 서버 운영자에게는 한정된 인바운드 포트 집합을 관리하도록 요청할 수 있게 했다. 프로토콜 자체는 그대로였고, 운용 부담의 위치만 바뀐 것이다.

출처