요약

  • FTP는 명령과 파일 데이터를 분리했습니다. 클라이언트가 제어 연결을 열었지만, 일반적인 액티브 방식에서는 서버가 클라이언트가 지정한 데이터 포트로 두 번째 연결을 되돌아 걸었습니다.
  • 패킷 필터 방화벽은 이 콜백을 요청받지 않은 인바운드 호출처럼 보았습니다. RFC 1579는PASV를 권고했습니다. 서버가 수신 대기하고 포트를 보고하면, 클라이언트가 경계를 넘어 데이터 연결을 시작하는 방식입니다.
  • RFC 2428의EPSV는 포트만 반환하고 제어 피어의 주소를 재사용하여 NAT가 재작성해야 할 내용을 줄였습니다. 그러나 방향이 곧 신원은 아니었습니다. 바운스 공격과 패시브 포트 탈취를 막으려면 엔드포인트가 대상을 제한하고 데이터 피어를 제어 세션에 결합해야 했습니다.

파일 전송 하나, 두 개의 대화

RFC 959의 구조는 사용자가 하나의 FTP 세션으로 보기 때문에 잘못 기억하기 쉽습니다. 프로토콜은 두 개의 연결을 봅니다. 제어 연결은 명령과 응답을 전달합니다. 데이터 연결은 디렉터리 목록, 파일의 일부, 파일 전체 또는 여러 파일을 전달합니다. 제어 대화가 살아 있는 동안 데이터 경로는 사라질 수 있습니다.

이 분리는 유용했습니다. 명령은 작고 수명이 길었고, 데이터는 클 수 있고 일시적이었습니다. 표현 방식, 전송 모드, 파일 시스템 작업은 제어 경로에서 협상하되, 실제 운반은 별도의 전이중 경로가 담당할 수 있었습니다. 그러나 이 분리는 로그인이 네트워크 작업을 끝내지 않는다는 뜻이기도 했습니다. 모든 전송에는 여전히 두 번째 질문에 대한 답이 필요했습니다. 누가 수신 대기하고, 누가 전화를 거는가?

원래의 답은 비대칭이었습니다. 사용자 프로토콜 인터프리터가 제어 연결을 시작했습니다. 데이터에 대해서는 통상 사용자 측이 수신 대기하고 서버의 데이터 전송 프로세스가 연결을 시작했습니다.PORT는 클라이언트가 다른 호스트와 포트를 지정할 수 있게 했고, 이는 주목할 만한 삼자 구성도 지원했습니다. 사용자가 두 서버를 제어하며 한 서버에게 다른 서버로 직접 보내라고 요청할 수 있었습니다.

이는 명세에 숨겨진 결함이 아니었습니다. 역할의 명시적 배분이었습니다. 클라이언트는 엔드포인트를 서술했고, 서버는 그 서술에 따라 행동했습니다. 호스트가 연결을 받아들일 수 있는 네트워크에서 콜백은 평범한 장치였습니다.

필터는 문 앞의 낯선 이를 보았다

1994년 2월까지 Steven Bellovin의RFC 1579는 다른 운영 세계를 서술하고 있었습니다. 클라이언트는 전송마다 새로운 데이터 포트를 선택해PORT로 보내는 것이 일반적이었습니다. 클라이언트를 보호하는 패킷 필터 방화벽은 FTP 서버가 예측 불가능한 높은 번호의 포트로 새 인바운드 TCP 연결을 시작하는 것을 보게 됩니다.

필터에는 맥락이 거의 없었습니다. 알려진 공개 서비스를 허용하거나, 승인 번호가 있는 패킷을 기존 흐름에 속하는 것으로 추론할 수는 있었습니다. 그러나 인증된 제어 연결이 어딘가 존재한다는 이유만으로 모든 임시 클라이언트 포트를 열어두는 것은 안전하지 않았습니다. 두 번째 연결은 FTP에는 의미가 있었지만 전송 계층 규칙을 적용하는 장치에는 요청받지 않은 호출처럼 보였습니다.

불일치는 방화벽이 인터넷을 이해하지 못해서가 아니었습니다. 두 시스템이 권한을 서로 다르게 나눴습니다. FTP는 클라이언트가 인바운드 엔드포인트를 지명하도록 허용했고, 방화벽 정책은 보호 대상 클라이언트가 새 대화를 시작해야 한다고 가정했습니다. 각 규칙은 개별적으로는 일관적이었습니다. 그 조합이 실패했습니다.

PASV는 액티브 오픈을 옮겼다

프로토콜에는 이미 탈출구가 있었습니다.PASV는 서버 데이터 전송 프로세스가 기본이 아닌 포트에서 수신 대기하고, 전송 명령 뒤에 연결을 시작하는 대신 기다리도록 요청합니다. 서버는 자신이 수신 대기 중인 주소와 포트를 반환하고, 클라이언트가 액티브 오픈을 수행합니다.

이 반전은 경계를 넘는 내용을 바꾸었습니다. 수명이 긴 제어 연결과 일시적 데이터 연결 모두 이제 클라이언트 쪽에서 시작됩니다. 따라서 RFC 1579는 방화벽 환경 외부에서조차 벤더가 클라이언트를PORT대신PASV를 사용하도록 만들 것을 권고했습니다.

이 변경의 경제성이 중요합니다. FTP는 두 개의 평면을 병합할 필요가 없었습니다. 방화벽이 응용 대화의 보편적 해석자가 될 필요도 없었습니다. 패시브 전송은 반드시 왕복을 하나 더하는 것이 아니었습니다. 클라이언트는 이미 전송 전에PORT를 보내고 있었기 때문입니다. 누가 전화를 거는가에 대한 작은 선택이 기존 구조를 흔한 로컬 정책과 호환되게 만들었습니다.

그러나 권고가 발표되었다고 현실이 된 것은 아니었습니다. 일부 서버는PASV를 이해하지 못했고, 클라이언트는 오류를 받고 액티브 모드로 폴백할 수 있었습니다. 네트워크가 허용하는 곳에서는 기존 상호운용성이 보존되었지만, 폴백은 콜백을 거부하는 방화벽을 통과할 수 없었습니다. 채택은 서버 지원, 클라이언트 기본값, 배포된 규칙 속에 살아 있었습니다.

RFC 1579는 별도의 요청 없이 모든 전송을 패시브로 만들었을APSV명령도 논의했습니다. 알려진 구현은 없다고 명시했습니다. 구현되지 않은 아이디어는 유용한 증거입니다. 문서는 미래를 이름 지을 수 있지만, 실행 중인 참여자만이 그것을 운영 관습으로 만들 수 있습니다.

EPSV는 주소 광고를 멈췄다

고전적인PORT와PASV는 IPv4 주소와 TCP 포트를 인코딩했습니다. IPv6가 도입되고 NAT가 양 끝 사이에서 주소를 바꾸면서 이것이 부담이 되었습니다. 변환기는 FTP 제어 페이로드를 검사하고 명령을 인식하고 응용 데이터 안에 박혀 있는 네트워크 주소를 재작성해야 할 수 있었습니다.

RFC 2428이 확장 쌍을 제공했습니다.EPRT는 주소 패밀리 번호, 네트워크 주소, 포트를 담을 수 있어 IPv4, IPv6 및 이후 패밀리를 위한 액티브 구성을 보존합니다.EPSV는 패시브 아이디어를 더 밀어붙입니다. 그 응답에는 수신 대기 중인 TCP 포트만 담깁니다. 데이터 연결은 제어 연결과 동일한 네트워크 프로토콜과 피어 주소를 사용합니다.

주소를 제거한 것은 단순한 문법 이상이었습니다. 제어 연결이 이미 클라이언트가 도달한 서버가 누구인지 확립했습니다. 평범한 두 기계 전송에서 네트워크 주소를 반복하는 것은 NAT가 수리해야 하고 클라이언트가 해석해야 할 또 하나의 주장을 만들었습니다.EPSV는 메시지를 클라이언트가 실제로 필요로 하는 새로운 사실, 즉 임시 포트로 좁혔습니다.

EPSV ALL은 세션 경계를 명시적으로 만들었습니다. 서버가 이를 수락하면 그 제어 세션에 대해EPRT,PORT,PASV및 기타 데이터 설정 대안을 거부해야 합니다. 이후 삼자 전송이 필요해진 클라이언트는 새 FTP 세션을 열어야 합니다. 이 선택은 강력하지만 국소적이며 명확한 경계에서 되돌릴 수 있습니다. 네트워크상의 다른 모든 세션을 재작성하지는 않습니다.

좌표는 자격 증명이 아니었다

방향을 바꾸는 것은 도달 가능성 문제를 해결했습니다. 그러나 누가 어느 엔드포인트를 점유할 자격이 있는가라는 질문에는 답하지 않았습니다.

RFC 2577은 액티브 측의 가장 인상적인 악용을 문서화합니다.PORT는 제3자를 지명할 수 있었기 때문에, 클라이언트는 FTP 서버에게 다른 기계와 서비스에 연결하여 공격자가 고른 바이트를 보내도록 요청할 수 있었습니다. 이 "바운스"는 시작자를 가리고 주소 기반 제한을 회피할 수 있었습니다. 제안된 방어에는 TCP 포트 1024 미만의 액티브 데이터 대상 거부, 서버 간 전송이 불필요한 곳에서의PORT비활성화, 접근 정책이 위치에 의존할 때 제어와 데이터 주소를 모두 확인하는 방법이 있었습니다.

패시브 모드는 노출된 수신자를 폐지한 것이 아니라 옮겼습니다. 이제 서버가 임시 포트를 열었습니다. 공격자가 다음 포트를 예측하고 먼저 연결할 수 있다면, 정당한 전송을 거부하거나, 다른 누군가를 위한 파일을 받아가거나, 인증된 클라이언트에서 올 것으로 기대되는 스트림에 위조 파일을 주입할 수 있었습니다. RFC 2577은 임의의 로컬 데이터 포트를 권고했습니다. 더 근본적으로, 엔드포인트는 데이터 피어가 제어 세션에 속하는지 여부를 스스로 판단해야 했습니다.

이 구분이 역사적 주장을 정직하게 유지합니다.PASV는 연결 방향을 클라이언트 방화벽에 더 우호적으로 만들었습니다.EPSV는 좌표를 IPv6와 NAT에 더 우호적으로 만들었습니다. 어느 명령도 FTP를 기밀로 만들거나, 파일 스트림을 인증하거나, 수신 대기 중인 포트에 도달한 첫 프로세스가 로그인한 당사자임을 증명하지 않았습니다.

작은 확장이 작업을 재분배했다

이 이야기는 흔히 "패시브 FTP는 방화벽을 통과한다"로 축소됩니다. 그러나 남아 있던 것은 그 밑바닥의 배분이었습니다.

공유 프로토콜은 한 쪽이 수신자를 알리고 다른 쪽이 경로를 열기에 충분한 것만 정의했습니다. 클라이언트는 패시브 동작을 요청할지 선택했습니다. 서버는 포트를 고르고 어떤 설정 명령과 대상을 허용할지 결정했습니다. 방화벽은 새 인바운드 흐름에 대한 자기 로컬 규칙을 유지했습니다. 구현체는 두 전송 연결을 하나의 보안 컨텍스트에 연관시킬 의무를 보유했습니다.

이것은 최소 공통 장치가 국소적 미래 선택을 만들어내는 정확한 사례입니다. 오래된 액티브 구현은 양 끝과 네트워크가 수용하는 곳에서 계속할 수 있었습니다. 클라이언트와 서버는 중앙 전환 없이 패시브 모드를 채택할 수 있었습니다. EPSV는 더 깔끔한 양자 프로필이 되는 한편 EPRT는 예외적인 삼자 기능을 보유했습니다. 비호환은 실패한 명령이나 연결로 나타났지, 기관이 한 참여자를 무효로 선언하는 방식으로 나타나지 않았습니다.

한계도 똑같이 국소적이었습니다. 서버는PORT를 비활성화할 수 있고, 클라이언트는EPSV를 고집할 수 있고, NAT는 페이로드 재작성을 피할 수 있고, 보안 정책은 제어 피어와 일치하지 않는 데이터 피어를 거부할 수 있습니다. 각 결정은 그 참여자의 호환성 표면을 바꾸었습니다. 그중 어느 것도 포트 번호를 보편적 권한으로 바꿀 필요가 없었습니다.

출처와 한계

두 연결 모델, 통상적인 서버 시작 데이터 연결,PORT와PASV는RFC 959에서 옵니다. 방화벽 분석과 클라이언트 측 패시브 동작을 기본으로 만들라는 권고는RFC 1579에서 옵니다.EPRT,EPSV, 주소 패밀리 지원, 주소 생략,EPSV ALL은RFC 2428에 규정되어 있습니다. 바운스 공격, 주소 확인, 패시브 포트 탈취는RFC 2577에 서술되어 있습니다.

이 문서들은 현재의 FTP 배포를 측정하거나 모든 방화벽, NAT, 프록시, 클라이언트 또는 서버가 권고대로 동작함을 증명하지 않습니다. 이들은 패시브 FTP를 안전한 전송으로 만들지 않습니다. 이들이 뒷받침하는 것은 더 좁은 역사입니다. 서버 콜백이 새 경계와 충돌했을 때, FTP는 클라이언트가 두 번째 연결을 시작하도록 하고 남은 신뢰 결정을 실제 동작 중인 시스템에 유지함으로써 살아남았다는 역사입니다.