요약

  • 1985년 FTP는 명령을 주고받는 연결과 파일 데이터 연결을 분리했다. 사용자는 PORT로 다른 데이터 목적지를 지정해 두 서버가 파일을 직접 주고받게 할 수 있었다.
  • 1999년 RFC 2577은 같은 목적지 지정이 FTP 서버를 무관한 서비스로 보내는 바운스 공격에 쓰일 수 있음을 설명했다.

A 창고에서 B 창고로 상자를 옮길 때 주문자의 집을 경유할 이유는 없다. 집으로 가는 길이 특히 느리다면 더 그렇다. FTP는 파일에도 이 간단한 물류를 적용했다. 사용자가 두 서버에 지시하고 서버들이 직접 운반한다. 그런데 운송장 주소를 주문자가 마음대로 쓸 수 있었다. 그 주소가 B 창고가 아닌 엉뚱한 건물이라면, 주문자는 남의 트럭을 다른 집 앞에 세운 셈이다.

1985년 10월 발표된 FTP 명세 RFC 959는 제어용 대화와 데이터 이동을 별도 연결로 다뤘다. 사용자는 FTP 서버 두 대에 각각 제어 연결을 열고 한쪽을 기다리게 한 뒤 다른 쪽이 연결해 파일을 보내게 할 수 있었다. PORT는 평소와 다른 데이터 주소와 포트를 알려 주는 명령이었다. 명세는 제삼자 호스트나 먼 곳의 라인 프린터까지 가능한 용도로 들었다. 느린 사용자 회선을 파일이 두 번 통과하지 않아도 된다는 장점은 분명했다.

이 설계는 선택과 실행을 갈랐다. 목적지는 사용자가 적고, 실제 네트워크 연결은 서버가 열었다. 정상적인 서버 간 전송에서는 목적지가 다른 FTP 서버다. 아무 주소나 받아들이는 서버라면 다른 서비스의 주소와 포트로도 향할 수 있다. 상대 서비스 눈에는 FTP 서버가 방문자로 보인다. 주소를 적어 넣은 사람은 제어 연결 저편에 남아 있다.

Steve Bellovin의 1994년 2월 RFC 1579는 같은 연결 구조가 방화벽에서 만든 불편을 짚었다. 능동 FTP는 서버가 사용자 쪽 포트에 새 연결을 걸기 때문에 패킷 필터가 예기치 않은 인바운드 호출을 처리해야 했다. Bellovin은 클라이언트가 PASV를 쓰도록 권했다. 서버가 기다리고 클라이언트가 바깥으로 데이터 연결을 시작하는 방식이다. APSV라는 구상도 소개했지만 당시 자신이 아는 구현은 없다고 밝혔다. 누가 먼저 연결하는지는 운영자가 열어야 할 문을 바꿨다.

주소 체계가 커지자 1998년 9월 RFC 2428은 IPv6와 주소 변환 환경을 위해 EPRT와 EPSV를 정했다. EPRT는 네트워크 주소 계열, 주소, TCP 포트를 담는다. EPSV ALL을 선언한 세션은 두 당사자 사이의 전송에 묶이며, 나중에 세 당사자 전송이 필요하면 새 세션을 열어야 한다. 주소 칸이 넓어지고 전송 형태도 더 분명해졌다. 그러나 목적지 이름을 서버가 받아들일 권한이 있는지는 여전히 운영 정책의 몫이었다.

1999년 5월의 RFC 2577은 이를 바운스 공격으로 설명했다. 사용자가 PORT에 제삼자 기계의 서비스 주소와 포트를 쓰고 FTP 서버에 데이터를 보내라고 한다. 그 데이터가 상대 서비스가 알아듣는 명령이라면, FTP 서버가 사용자를 대신해 그 서비스에 말을 건 셈이다. 문서의 예는 SMTP 명령이 든 파일을 올린 뒤 서버를 통해 제삼자 메일 서비스로 전달하는 것이다. 파일을 만든 사람은 그 서비스에 직접 연결하지 않는다. 서버의 네트워크 위치를 잠시 빌린다.

대책은 각각 값을 치러야 했다. RFC 2577은 1024 미만의 TCP 포트로 데이터 연결을 열지 말고 그런 PORT 요청에는 504로 답하라고 제안했다. 높은 포트에서 대기하는 서비스는 여전히 남는다. 파일 권한을 잘 설정하면 명령 파일을 올려 두었다가 다른 곳으로 보내는 길을 막을 수 있다. PORT 자체를 끄면 서버 사이 직송 기능도 잃는다. 저자들은 일반 파일 전송의 대부분은 PASV로 가능하다고 봤다. 어떤 목적지까지 서버를 보내 줄지 결정하는 사람은 서버의 비용을 부담하는 운영자여야 했다.

FTP의 직송은 멋진 지름길이었다. 방화벽은 연결 방향을 따져 보게 했고, 새 주소 형식은 운송장을 다시 쓰게 했다. 1999년의 질문은 그 운송장에 누가 승인 도장을 찍느냐였다. 손님은 주소를 제안할 수 있다. 운전대를 맡길지는 차주가 정한다.