FTP 서버로 가는 길에서 VPN 보호가 끝나는 지점

VPN은 하나의 경로를 보호하며, 모든 경로에는 끝이 있습니다. 터널이 회사 게이트웨이에서 끝나면 파일 전송은 그 지점부터 자체 프로토콜이 제공하는 보호 아래 계속됩니다. 이 차이가 전송이 처음부터 끝까지 보호되는지, 아니면 게이트웨이까지만 보호되는지를 결정합니다. Connected 표시등은 둘 중 어느 것에 대해서도 말해 주지 않습니다.

두 가지 배치, 두 개의 남은 경로

회사 VPN에 접속한 뒤 별도의 내부 서버로 FTP 세션을 여는 노트북을 생각해 보세요. 터널은 게이트웨이에서 멈추고, 게이트웨이에서 그 서버까지의 구간은 터널 밖에 있습니다.

일반 FTP는 패킷이 터널을 통해 도착했다고 해서 암호화를 얻지 않습니다. 남은 구간에서 명령, 자격 증명, 파일 내용은 프로토콜이 정의한 그대로, 즉 평문으로 이동합니다. 그것이 중요한지는 토폴로지와 그 구간을 또 무엇이 지키는지에 달려 있으며, 주소를 사설이라고 부르는 것은 질문에 답하지 않습니다. 서버가 게이트웨이가 한 번 더 건너가 도달하는 클라우드 네트워크에 있을 때도 같은 논리가 반대 방향으로 적용됩니다.

VPN 종단점과 FTP 서비스를 한 대의 머신에 두면 걱정할 다음 구간이 없습니다. 그것은 다른 배치이며, 호스트의 프로세스와 파일, 자격 증명이 안전하다는 증거는 아닙니다.

일반 FTP, FTPS, SFTP는 세 가지 결정입니다

일반 FTP는 비밀번호를 포함해 아무것도 암호화하지 않습니다. FTPS는 FTP에 TLS를 더하므로 제어 채널과 협상된 경우 데이터 채널이 보호됩니다. SFTP는 SSH 안에서 운반되는 다른 프로토콜이며, FTPS의 또 다른 표기가 아닙니다.

서버가 그 선택을 지원해야 합니다. 클라이언트는 존재하지 않는 리스너를 만들어 낼 수 없기 때문입니다. SFTP를 고른다고 FTP 전용 서비스가 SSH 종단점으로 바뀌지 않으며, 북마크 이름을 바꾸거나 포트를 바꾸는 것은 협상된 내용에 대해 아무것도 증명하지 않습니다. 클라이언트 쪽뿐 아니라 서버 쪽에서도 프로토콜을 확인하세요. 파일 관리자의 자물쇠는 세션에 대한 주장이며, 그 뒤의 리스너에 대한 주장이 아닙니다.

전송이 중요할 때는 예상치 못한 신원 변화가 나타나는 마지막 열을 읽으세요.

데이터 연결은 두 번째 연결입니다

FTP는 제어 연결을 열고, 그다음 목록과 전송을 위한 별도의 데이터 연결을 엽니다. 보호된 로그인은 배포가 그 연결들에도 보호를 요구하지 않는 한, 나중에 열리는 연결에 대해 아무것도 말해 주지 않습니다.

FTPS에서는 클라이언트가 특정 명령으로 보호된 데이터 채널을 요청하고, 서버 정책은 평문 대안을 거부할 수 있습니다. 클라이언트 기본값이 충분하다고 가정하지 말고 정책이 그것을 요구하는지 확인하세요. 수동 모드는 두 번째 복잡함을 더합니다. 서버가 데이터 연결을 위한 주소와 포트를 알리기 때문입니다. 그 알림을 다시 쓰거나 차단하는 방화벽이나 NAT 장비가 있으면, 인증은 통과하지만 첫 목록에서 멈추는 세션이 됩니다.

curl -vk ftps://files.corp.example/ --user alice --ftp-ssl-control
openssl s_client -connect files.corp.example:21 -starttls ftp
ss -tnp | grep -E ':21|:990'

두 번째 명령은 어떤 파일도 건드리기 전에 서버가 제어 채널에서 무엇을 제시하는지 보여 줍니다. 세 번째는 데이터 연결이 아예 성립되었는지 보여 주며, 이것이 인증 실패와 수동 모드 실패의 차이입니다.

신원 확인은 터널을 넘어 살아남습니다

FTPS 클라이언트는 TLS 서버의 신원을 검증하고, SFTP 클라이언트는 SSH 호스트 키를 검증합니다. 두 확인 모두 파일 전송 프로토콜에 속하며, 어느 것도 VPN이 수행하지 않습니다.

이 분리는 중간의 무언가가 세션을 들여다보려 할 때 중요합니다. 네트워크 장비가 명령을 읽을 수 있도록 TLS를 끄는 것은 보호 모델을 완성하는 것이 아니라 바꾸는 일입니다. 터널이 올라왔다는 이유로 설명 없는 호스트 키를 받아들이는 것도 마찬가지입니다. 의도한 신뢰 구성을 유지하고 올바른 자료를 운영자에게서 받으세요. 인증을 통과하는 터널은 그 먼 쪽 끝의 서버에 대해 아무것도 말해 주지 않습니다.

이 프로토콜들의 개인 키와 인증서 자료는 VPN 자격 증명과 분리된 또 하나의, 세 번째 비밀입니다.

실제로 무엇을 확인했는지 기록하세요

옮길 권한이 있는 무해한 파일을 골라 어떤 프로토콜이 돌았는지, 상대방의 어떤 신원을 확인했는지, 어떤 경로를 의도했는지, 전송이 끝났는지라는 네 가지 사실을 적으세요.

lftp -u alice -e "set ftp:ssl-protect-data true; ls; bye" ftps://files.corp.example
sftp -v [email protected]

디렉터리 목록, 터널 로그인, 완료된 전송은 세 가지 별개의 관찰이며, 경로가 파일에 대해 작동한다고 말하는 것은 마지막 하나뿐입니다. 남은 홉의 기밀성을 VPN에만 의존하는 설계라면, 그것을 결정으로서 그대로 적으세요. 홉과 그 신뢰 가정을 명시한 승인 메모는 연결된 클라이언트의 스크린샷보다 가치가 있습니다.