483. 액티브(Active) FTP vs 패시브(Passive) FTP 동작 원리 차이

핵심 인사이트 (3줄 요약)

본질: 고전 FTP는 제어 채널(포트 21) 통과 후 실제 파일을 쏘기 위한 두 번째 데이터 채널을 열 때, **누가 먼저 상대방에게 소켓 접속을 찌르느냐(방향성)**에 따라 액티브 모드와 패시브 모드로 나뉜다.

가치: 액티브(Active) 모드는 서버가 클라이언트 PC(포트 20 ➔ 랜덤 포트)로 역방향 침투를 시도하므로 클라이언트의 공유기(NAT)나 방화벽에 100% 튕기는 치명적 결함을 갖는다. 반면 패시브(Passive) 모드는 클라이언트가 서버 쪽으로(랜덤 ➔ 랜덤) 연결을 주도하게 하여 방화벽 친화적 아키텍처를 완성한다.

융합: 실무 클라우드(AWS, 온프레미스) 방화벽(Security Group, iptables) 세팅 시, 패시브 모드를 위해 서버 측의 데이터 포트 범위(예: 50000~60000)를 대량으로 열어두어야 하는 인프라적 트레이드오프와 딜레마를 유발하는 대표적인 보안 분쟁 포인트다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: FTP 클라이언트와 서버가 파일 목록 조회(LIST)나 다운로드/업로드(RETR/STOR)를 위해 데이터 전송용 파이프라인(Data Connection)을 생성할 때, 접속 스위치(SYN 패킷)를 누르는 주도권에 관한 네트워크 라우팅 규약이다.
필요성: FTP 스펙이 처음 만들어진 1980년대에는 인터넷에 연결된 모든 컴퓨터가 서로를 찌를 수 있는 공인 IP를 갖고 방화벽 없이 살던 평화로운 시대였다. 그래서 서버가 사용자 PC로 거꾸로 접속해 파일을 던져주는 설계(Active Mode)가 전혀 문제 되지 않았다. 그러나 1990년대 이후 해커의 등장으로 집집마다 방화벽이 세워지고, IP 부족 사태로 공유기(NAT, 사설 IP) 안에 사람들이 숨기 시작하자, 서버가 밖에서 집 안쪽(클라이언트)으로 밀고 들어오는 연결은 100% 차단(Drop)되는 비극이 발생했다. 꽉 막힌 현관문을 안쪽에서 밖으로 밀고 나가는 새로운 길(Passive Mode)이 절실하게 필요했다.
💡 비유: 액티브 모드는 짜장면 배달입니다. 내가 중국집(서버 21번)에 전화해서 "저희 집 302호(랜덤 포트)로 배달해 주세요" 하면 오토바이(서버 20번)가 우리 집 아파트 현관으로 밀고 들어옵니다. 하지만 아파트 경비원(방화벽)이 외부 오토바이를 막아버리면 배달에 실패합니다. 패시브 모드는 방문 포장(픽업)입니다. 내가 전화를 걸면 중국집이 "짜장면 다 됐으니 가게 옆 창고 5번 문(서버 랜덤 포트)으로 가지러 오세요"라고 알려주고, 내가 직접 경비원을 뚫고 밖으로 나가서(아웃바운드) 짜장면을 받아오는 방식입니다.
등장 배경:
1. 초기 통신 모델 (Active): 클라이언트가 제어 통로(21번)로 텔넷 명령을 내리면, 서버가 20번 포트에서 나와 클라이언트의 잉여 포트로 돌진하는 전통적 서버 푸시(Push) 철학의 산물.
2. NAT / Firewall의 역습: 클라이언트가 192.168.x.x 같은 사설 IP를 쓸 경우, 클라이언트가 서버에 "나 192.168.0.5 에 있으니 일로 파일 쏴라"라고 PORT 명령을 날리면, 서버는 공인 인터넷 망에서 사설 IP를 찾지 못해 미아가 되어버린다.
3. PASV 스펙의 등장: 이 참사를 해결하기 위해 클라이언트가 PASV 명령어를 치면 서버가 "나의 공인 IP와 임시 포트번호를 알려줄 테니, 네가 날 찔러"라고 응답하는 수동(Passive) 모드가 스펙(RFC 1579)에 추가되었다.

┌─────────────────────────────────────────────────────────────┐
│          Active(능동) 모드 vs Passive(수동) 모드의 방화벽 투쟁         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ [ ❌ Active 모드: 방화벽에 충돌하여 폭사하는 서버 ]                   │
│                                                             │
│ [Client PC (방화벽/NAT 굳게 닫힘)]                [FTP Server]│
│   │                                                 │       │
│   │ 1. [TCP 1025 ➔ 21] 나 로그인 완료했어.            │       │
│   │────────────────────────────────────────▶│       │
│   │ 2. [명령] PORT 192,168,0,5, 4, 3 (내 포트는 1027야)│       │
│   │────────────────────────────────────────▶│       │
│   │                                                 │       │
│   │ 3. 서버가 무식하게 클라이언트로 역방향(Inbound) 돌격!    │       │
│ 💥방화벽 ◀────── 차단 (Drop) ───── [TCP 20 ➔ 1027] │       │
│ (외부 연결 거부)                                              │
│                                                             │
│ ----------------------------------------------------------- │
│                                                             │
│ [ ✅ Passive 모드: 방화벽을 우회하는 우아한 클라이언트 아웃바운드 ]   │
│                                                             │
│ [Client PC (방화벽 아웃바운드는 허용됨)]           [FTP Server]│
│   │                                                 │       │
│   │ 1. [TCP 1025 ➔ 21] 나 로그인 완료했어.            │       │
│   │────────────────────────────────────────▶│       │
│   │ 2. [명령] PASV (나 방화벽 있으니까 네가 포트 열어!)   │       │
│   │────────────────────────────────────────▶│       │
│   │ 3. [응답] 227 Entering Passive Mode (서버IP, 195, 80)│       │
│   │◀────────────────────────────────────────│       │
│   │   * 195 * 256 + 80 = 포트 50000 번이 열렸구나!           │
│   │                                                 │       │
│   │ 4. 클라이언트가 자발적으로 밖으로 나감 (Outbound 통과!)  │       │
│ 🚀 방화벽 통과 ───────── [TCP 1028 ➔ 50000] ─────▶│       │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] Active 모드에서 가장 치명적인 순간은 3번 단계다. 서버의 20번 포트에서 클라이언트의 1027번 포트로 치고 들어오려 할 때, 클라이언트 앞단의 공유기나 Windows 방화벽은 "내가 요청하지도 않은 외부의 불법 연결"로 간주하고 무자비하게 패킷을 드롭(Drop)시킨다. 사용자 화면에는 Connecting... 만 무한히 돌다 타임아웃이 난다. 반면 하단의 Passive 모드에서는 클라이언트가 먼저 PASV 명령을 치면 서버가 "내 공인 IP와 랜덤 포트(50000번)를 열어뒀어"라고 대답한다. 그러면 클라이언트가 안에서 밖으로(Outbound) 50000번 포트를 찌르고 나간다. 방화벽의 철칙은 "안에서 밖으로 나가는 트래픽은 기본 허용"이므로 아무런 저항 없이 연결이 성사되고 짐마차(데이터 채널) 파이프가 뚫리게 된다.

📢 섹션 요약 비유: 철통 보안 아파트(NAT)에 사는 내가 피자 배달 오토바이(서버 역방향 접속)를 안으로 들이려다 경비원에게 제지당하는 것이 Active 모드 실패의 전말이고, 내가 직접 1층 주차장(서버 임시 포트)으로 내려가 받아오는 것이 Passive 모드의 해결책입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

포트 계산법 (PORT / PASV 응답 포맷)

FTP가 통신할 때 IP와 포트 번호를 알려주는 규격은 기괴하게도 6개의 숫자를 쉼표(,)로 이은 문자열 형태를 띤다.

포맷 예시: 192,168,0,5, 4, 3
해석: 앞의 숫자 4개는 IP 주소 (192.168.0.5)
뒤의 숫자 2개는 포트 번호를 나타내는 수학 공식: (첫 번째 숫자 × 256) + (두 번째 숫자)
- 위 예시의 포트: (4 × 256) + 3 = 1024 + 3 = 1027번 포트

모드	명령어 (Client ➔ Server)	데이터 채널 방향 (SYN 패킷)	주요 사용 주체	문제점
Active (능동)	`PORT 192,168...`	서버(Port 20) ➔ 클라이언트(임의의 포트 N)	전통적인 유닉스 시스템	클라이언트단 방화벽/NAT 에 가로막힘
Passive (수동)	`PASV` (서버에게 포트 개방 요구)	클라이언트(임의의 포트 N) ➔ 서버(임의의 포트 M)	브라우저 및 현대 FTP 클라이언트 기본값	서버단 클라우드 방화벽(AWS 등) 을 엄청나게 열어둬야 함

공유기와 NAT (Network Address Translation)의 늪

Active 모드가 실패하는 원인을 네트워크 헤더 관점에서 뜯어보면 참담하다. 클라이언트 PC의 실제 IP는 사설망(192.168.0.5)이다. 클라이언트가 FTP 서버에 PORT 192,168,0,5, ... 라고 자기 진짜 주소를 평문 텍스트에 박아서 보낸다. 문제는 이 텍스트가 공유기(NAT)를 거쳐 인터넷으로 나갈 때, 공유기는 IP 헤더의 패킷 주소(공인 IP)는 바꿔주지만, FTP 명령어 텍스트 데이터 덩어리(Payload) 안에 하드코딩된 사설 IP 문자열 192,168,0,5까지는 바꿔주지 않는다. 서버는 이 텍스트를 보고 충실하게 192.168.0.5라는 전 세계에 수천만 개나 존재하는 가짜 주소로 역방향 연결을 시도하다가 허공에 패킷을 쏘고 장렬히 전사한다. 이 문제를 억지로 고치기 위해 나온 방화벽 꼼수가 바로 ALG(Application Layer Gateway) 칩이다.

┌─────────────────────────────────────────────────────────────────┐
│              공유기(NAT)의 ALG 마법이 Active 모드를 살리는 과정               │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│ 클라이언트 (192.168.0.5)                                          │
│   │                                                             │
│   │  [평문 데이터: "PORT 192,168,0,5, 4,3"]                      │
│   ▼                                                             │
│ --------------------- 공유기 (NAT / ALG 가동!) -------------------│
│   │ 공유기가 IP 헤더만 바꾸는 게 아니라, 똑똑하게 FTP 텍스트 속까지 뜯어본다! │
│   │ 💡 "어? FTP 명령어네? 사설 IP 적혀있네? 내 공인 IP로 글자 쓱 지우고 고쳐야지!"│
│   │ "PORT 192,168,0,5" ➔ "PORT 203,243,12,3" 로 위조(Spoofing)  │
│ --------------------------------------------------------------- │
│   │                                                             │
│   ▼                                                             │
│ 서버 (서버는 공유기 공인 IP를 정상적으로 보고 해당 포트로 역방향 연결 성공!)     │
│                                                                 │
│ ⚠️ 치명적 한계: 만약 FTP 통신이 암호화된 FTPS(TLS) 환경이라면?            │
│ 공유기(ALG)가 암호화된 터널 속의 글자를 못 읽어 고칠 수가 없다 ➔ 100% 접속 실패!│
└─────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 초창기 똑똑한 공유기 벤더들은 FTP의 이 바보 같은 문제를 구제해주기 위해, 공유기가 패킷의 OSI 7계층(Payload)까지 뜯어보고 문자열을 강제로 치환해 주는 ALG 기능을 넣었다. 하지만 이는 프로토콜 계층 위반이라는 안티패턴이다. 나아가 보안이 중시되어 FTPS(SSL 얹기)를 쓰는 순간, 텍스트가 암호화되어 공유기가 텍스트를 고쳐줄 수 없게 되면서 Active 모드는 이중의 죽음을 맞이하게 된다.

📢 섹션 요약 비유: 공유기가 멍청한 비서(Active 모드)의 실수(사설 주소 발송)를 몰래 수정액으로 지우고 회사 주소(공인 주소)로 고쳐서 살려주었지만, 비서가 편지를 금고(FTPS)에 잠가버리자 더 이상 수정해 줄 수 없어 결국 우편 배달이 실패하는 구조입니다.

Ⅲ. 융합 비교 및 다각도 분석

딜레마: Active가 죽으면 Passive가 서버 인프라를 괴롭힌다

현대 FTP 클라이언트(FileZilla 등)는 접속 시 무조건 100% Passive 모드로 디폴트(Default) 동작한다. 클라이언트 방화벽을 우회할 유일한 수단이기 때문이다. 하지만 문제는 이 폭탄이 인프라 엔지니어(서버 관리자)에게 통째로 전가된다는 것이다.

항목	서버 측 방화벽 세팅 (인바운드 룰)	클라우드 보안 그룹(AWS SG) 관리 고통도
Active 서버 세팅	포트 21번 하나만 열어두면 끝.	매우 낮음. 서버는 들어오는 제어 채널만 받고 20번 포트로 알아서 밖으로 나가면 되니까 아웃바운드 룰만 널널하면 끝.
Passive 서버 세팅	포트 21번 + 수천 개의 랜덤 데이터 포트 통째 오픈 필요.	지옥 수준. 서버가 클라이언트를 기다려야 하니, 50000~60000번대 포트 1만 개를 싹 다 인바운드로 뚫어두고 데몬 설정에도 이 범위를 픽스해야 함.

클라우드 시대에 "방화벽 인바운드를 1만 개 열어둬라"라는 것은 보안팀의 뒷목을 잡게 하는 미친 짓이다. 랜섬웨어와 포트 스캐닝의 놀이터가 되기 십상이다. 결국 양쪽 다 고통스러운 이 구식 프로토콜 아키텍처는 SFTP 22번 단일 포트 터널링이라는 구세주에게 자리를 통째로 내주게 된다.

과목 융합 관점

보안 (Security) & 인프라: 클라우드 보안 그룹(SG)에서 Passive FTP를 띄우려면 포트 범위를 좁히는 튜닝(예: pasv_min_port=50000, pasv_max_port=50100)을 반드시 거쳐야 한다. 그렇지 않으면 서버 OS 커널이 임의의 하이포트(High Port)를 1024~65535 사이에서 랜덤으로 뱉어버려, AWS 콘솔에서 전부 닫혀있는 포트에 계속 연결 타임아웃만 뜨는 지옥을 맛보게 된다.
📢 섹션 요약 비유: 액티브 모드가 '손님(클라이언트) 문이 닫혀서 배달이 실패'하는 문제라면, 패시브 모드는 '손님이 오게 만들었더니 식당(서버)이 어느 문으로 들어올지 몰라 식당 셔터 1만 개를 다 열어두고 벌벌 떨어야 하는' 보안 딜레마다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — AWS EC2에 FTP 서버 배포 후 LIST 명령어 먹통: SI 신입 개발자가 EC2 인스턴스에 vsftpd를 설치하고 21번 포트를 열었다. FTP 클라이언트로 접속하면 230 Login successful까지는 잘 뜨는데, 파일 목록을 보는 LIST 명령을 치면 Entering Passive Mode (13,125,55,10, 203,45) 응답이 오고 클라이언트 창이 하얗게 멈춰버린다.
- 판단: 100% Passive Mode 랜덤 포트 방화벽 차단 문제다. 서버 데몬이 무작위 포트 (203 * 256) + 45 = 52013번 포트로 들어오라고 던졌으나, AWS Security Group에는 52013번 포트가 닫혀있어 클라이언트의 SYN 찌르기가 허공에 소멸한 것이다. 해결책은 vsftpd.conf에 pasv_min_port=50000, pasv_max_port=50100을 픽스하고, AWS SG에 50000-50100 대역을 TCP 인바운드로 열어주는 것이다. 추가로 사설 IP가 클라이언트에게 전달되는 것을 막기 위해 pasv_address=내EC2공인IP 설정도 박아주어야 완벽히 해결된다.
시나리오 — 구형 사내 망 시스템의 Active FTP 연동 장애: 대기업의 구형 발주 시스템이 Active 모드로 강제 설정된 상태로 우리 회사망에 접속해 들어온다. 그런데 우리 회사가 공유기(NAT) 장비를 최신 방화벽으로 교체한 뒤부터 연결이 끊기기 시작했다.
- 판단: 신규 방화벽 장비에서 FTP ALG(Application Layer Gateway) 기능이 기본 비활성화되어 있거나 패킷 치환 로직을 차단했기 때문이다. 방화벽 엔지니어에게 "Active FTP 지원용 ALG 모듈을 활성화해주세요"라고 요청해야 간신히 사설 IP 치환이 동작하며 통신이 복구된다. 하지만 진짜 아키텍트라면 이딴 짓을 하지 않고 당장 파트너사에게 SFTP 연동으로 인터페이스를 교체하라고 공문을 띄워야 한다.

  ┌─────────────────────────────────────────────────────────────┐
  │         실무 아키텍처: 클라우드 환경 Passive FTP 장애 극복기         │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │ [문제 분석: 사설 IP 유출과 방화벽 차단의 이중고]                   │
  │                                                             │
  │ 클라이언트 ──(PASV 요청)──▶ [ AWS EC2 사설망 (172.31.0.5) ]      │
  │                                                             │
  │  ❌ 실패 1: 서버가 "내 사설IP(172.31.0.5)로 들어와"라고 대답함.       │
  │  ➔ 인터넷 클라이언트가 "172.31.0.5"를 찾아갈 방법이 없어 통신 폭망.       │
  │                                                             │
  │  ❌ 실패 2: 서버 커널이 "59483번 포트로 들어와"라고 마음대로 던짐.     │
  │  ➔ AWS 보안 그룹은 21번만 열어뒀으니 클라이언트가 튕겨 나감.              │
  │                                                             │
  │ [완벽한 해결책: vsftpd.conf 강제 제어 아키텍처]                     │
  │                                                             │
  │ 1) pasv_address = 3.3.3.3 (EC2의 고정 탄력적 EIP 강제 명시!)   │
  │ 2) pasv_min_port = 50000  (보안 그룹에 뚫어둔 범위만 쓰도록 강제!)│
  │ 3) pasv_max_port = 50100                                    │
  │                                                             │
  │ 클라이언트 ──(PASV 요청)──▶ [ 설정 완료된 AWS EC2 ]              │
  │ 클라이언트 ◀──(응답) "3.3.3.3의 50020 포트로 들어와!" ───── 서버  │
  │ ✅ 결과: 완벽한 공인 라우팅과 방화벽 허용 대역 통과로 파일 업/다운로드 성공!│
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 클라우드(퍼블릭 클라우드)에서 가장 흔히 터지는 FTP 장애의 바이블이다. 클라우드 인스턴스는 태생이 NAT 뒤에 숨어있는 사설망 자원이므로 자기가 자기 진짜 공인 IP를 모른다. Passive 응답을 날릴 때 자신의 로컬 사설 IP인 172.x.x.x 대역을 던져버리는 어처구니없는 응답이 발생한다. 따라서 관리자가 데몬(Daemon) 설정 파일에 "너의 밖에서 보이는 진짜 IP는 이거야"라고 하드코딩(pasv_address)을 해줘야만 이 거대한 미로 게임이 해결된다. 이것만 보더라도 FTP가 현대 클라우드 네이티브 생태계와 얼마나 지독하게 안 맞는 낡은 프로토콜인지 체감할 수 있다.

도입 체크리스트

기술적: 브라우저나 FileZilla 같은 클라이언트 로그 창을 유심히 살펴보았는가? 227 Entering Passive Mode 텍스트 뒤에 괄호로 찍힌 IP가 사설 IP 대역(192, 172, 10)인지, 진짜 공인 IP 대역인지 패킷 구조를 해독할 줄 아는가?
운영·보안적: 오픈된 100개의 Passive 고포트(High Port) 대역이 다른 백도어 트로이목마 서비스에 의해 선점되어 사용되고 있지 않은지 netstat으로 시스템 무결성을 모니터링하고 있는가?

안티패턴

FTP 무지성 방화벽 전체 개방 (Any Any Open): Passive 포트 범위가 왜 막히는지 윈인 파악도 안 해보고, 홧김에 AWS 인바운드 룰에 0.0.0.0/0 포트 범위를 1024~65535 전체 다 뚫어버리는 정신 나간 아키텍처. 이는 대문 옆에 커다란 셔터를 24시간 활짝 열어놓고 해커들을 환영하는 백기 투항과 같다.
📢 섹션 요약 비유: 이삿짐센터(클라이언트)가 길을 잃지 않게 하려면, 우리 집(서버)의 정확한 '도로명 주소(공인 IP)'와 '비워둔 주차 구역 번호 10개(지정된 포트 범위)'를 정확히 쪽지에 적어 보내야 짐이 안전하게 도착합니다. 주소를 잘못 적어주거나 주차장 전체를 무료 개방하면 대혼란이 열립니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	Active Mode 환경 유지	Passive Mode + 튜닝 적용	개선 효과
정량	개인 공유기(NAT) 사용자 접속 차단율 99%	클라이언트 아웃바운드 연결 허용	불특정 다수 대민 서비스 접속 성공률 100% 도달
정량	포트 Any 오픈 시 포트스캔 피격률 폭증	최소화된 지정 포트(50000~50100) 오픈	클라우드 인스턴스 해킹 피격 표면적 90% 이상 감축
정성	"목록이 안 뜹니다" CS 폭주 지연 해결 불가	서버 측 데몬 통제로 원천 해결	네트워크 엔지니어와 개발팀 간의 장애 핑퐁 제거 및 신뢰성 확보

미래 전망

보안과 관리의 난해함으로 인한 퇴출: Active와 Passive의 이 지긋지긋한 포트 방향성 싸움은 네트워크 엔지니어들의 10년짜리 골칫거리였다. 이 논쟁은 단일 포트(22번) 위에서 제어와 데이터가 모두 캡슐화되어 흐르는 SFTP 아키텍처로 넘어가면서 종지부를 찍었다. SFTP는 방화벽에 구멍 하나만 뚫으면 되므로 액티브/패시브라는 개념 자체가 존재하지 않는다.
현대 인프라의 교훈: 비록 FTP는 사라져 가지만, "명령(제어)과 실제 거대한 데이터 채널의 물리적 분리"라는 설계 사상은 현대 화상회의(WebRTC)의 시그널링(제어) 서버와 미디어(데이터) 서버 분리 아키텍처 등 고성능 네트워크 설계의 영원한 영감으로 남아있을 것이다.

참고 표준

RFC 1579: Firewall-Friendly FTP (Passive Mode의 공식 등장을 알린 역사적 스펙)
RFC 2428: FTP Security Extensions (보안과 방화벽의 충돌 지점 명세)

"누가 뚫고 들어갈 것인가." 액티브 모드와 패시브 모드의 대결은 단순히 FTP 설정 메뉴 속 클릭 한 번의 문제가 아니다. 인터넷이 공공의 평화로운 망(NAT 없음)에서 살벌한 각자도생의 방어망(공유기, 클라우드 SG)으로 쪼개져 온 인터넷 30년 방화벽 진화사를 그대로 축약해 놓은 역사적 유물이다. 포트가 열리고 닫히는 방향성(Inbound vs Outbound)의 철학을 뼛속 깊이 깨닫게 해주는 가장 훌륭한 네트워크 교육 교재라 할 수 있다.

📢 섹션 요약 비유: 옛날엔 모두 담장 없는 초가집이라 마당까지 차가 쑥쑥(액티브) 들어왔지만, 지금은 집마다 철문(공유기)과 아파트 경비원(방화벽)이 생겨 배달원과 내가 중간 지점에서 만나야 하는(패시브) 팍팍한 보안의 시대로 세상이 변한 씁쓸한 흔적입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
NAT (Network Address Translation)	공유기에서 1개의 공인 IP를 수백 개의 사설 IP로 변환해 주는 기술로, Active FTP 서버가 사설망 유저를 찌르지 못하게 길을 막아버린 원흉이다.
ALG (Application Layer Gateway)	NAT 라우터가 똑똑하게 FTP 명령어 패킷 페이로드 안의 사설 IP 텍스트를 공인 IP로 수정액 지우듯 지우고 조작해 주는 방화벽의 오지랖 기능이다.
Inbound / Outbound 방화벽 룰	클라우드(AWS SG 등)에서 서버를 지키는 룰로, 보통 아웃바운드는 전부 열어두지만 인바운드는 굳게 닫혀있어 액티브 모드 서버 공격을 무력화시킨다.
SFTP (SSH FTP)	이 액티브/패시브 포트 지옥을 끝장내기 위해, 암호화된 TCP 22번 포트 단 1개 통로 안에 모든 제어와 데이터를 밀어버린 구원자 아키텍처다.
Data Connection (포트 20)	명령이 오가는 제어 채널(21)과 달리, 실제 순수 1GB 덩어리가 찌꺼기 없이 흘러가도록 설계된 FTP만의 철학인 파이프 채널이다.

👶 어린이를 위한 3줄 비유 설명

FTP로 파일을 받는 건 피자 배달이랑 똑같아요. 액티브 모드는 우리 집에 "직접 갖다 주세요" 하는 건데, 아파트 경비 아저씨(우리 집 방화벽)가 잡상인 출입 금지라며 오토바이를 막아버리면 굶어야 해요.
그래서 생긴 패시브 모드는 내가 경비 아저씨를 뚫고 1층 주차장으로 "가질러 나가는(아웃바운드)" 방법이에요! 안에서 밖으로 나가는 건 경비 아저씨도 안 막거든요.
하지만 이 방법은 피자집(서버) 문을 이리저리 다 열어둬야 해서, 피자집 도둑(해커)이 들까 봐 사장님(서버 관리자)이 문단속(방화벽 설정)하느라 엄청 머리가 아프답니다!