【実務・中級編】ポート21(FTP)およびポート20におけるデータ流出の経路制御 – サイバーセキュリティとプライバシー保護実践ガイド

21番ポートの亡霊を葬れ：FTPによるデータ流出を封じ込めるゼロトラストの鉄則

「まだFTPを使っているのか？」

夜中の2時、原因不明のトラフィック急増で呼び出されたデータセンターの運用室。パケットキャプチャを眺めていた私の目に飛び込んできたのは、古い友人のような、そして現代においては「招かれざる客」である TCP 21 番ポートの通信でした。

暗号化すらされていない平文のパケットが、社内のDBサーバーから得体の知れない外部IPへと流れていく。これこそが、多くのインフラエンジニアが軽視しがちな「穴」であり、ランサムウェアや攻撃者が機密情報を窃取する際の古典的かつ強力な出口（エグレス）なのです。

今回は、今さら聞けないFTPの挙動と、それをネットワークレベルで叩き潰すための防衛術を深掘りします。

1. なぜ「FTP」がデータ流出の温床になるのか

FTP（File Transfer Protocol）は、RFC 959で定義された古き良きプロトコルです。しかし、現代のセキュリティ基準から見れば「致命的な欠陥」を抱えています。

制御とデータの分離: 21 番ポートでコマンドをやり取りし、20 番ポート（またはランダムなハイポート）でデータを転送するこの仕組みは、ファイアウォール越しでは非常に厄介な存在です。
平文通信: 認証情報もデータもすべて平文。中継経路で盗聴され放題です。
複雑なステートフル検査: 戻りの通信を予測できないため、ステートフル・インスペクションを通過させるためにセキュリティポリシーを甘くせざるを得ないケースが多く、攻撃者にとって「穴」になりやすいのです。

特に、侵害されたサーバー内で curl や python を使って「とりあえず外に投げる」際、FTPは検知をすり抜けるための隠れ蓑として利用されます。

2. FTPの「通信シーケンス」という弱点

FTPには「アクティブモード」と「パッシブモード」がありますが、データ流出において脅威となるのは、サーバー側から能動的に接続を開始する挙動です。

1. 制御接続 (21): クライアント（攻撃者/侵害サーバー）がサーバーへ接続し、認証。
2. PORTコマンド: クライアントが「このポートで待機しているから、お前の方から繋いできな」と指示。
3. データ接続 (20 またはランダム): サーバーがクライアントの指定したポートへ接続を開始。

この「内側から外側への接続開始」を許しているファイアウォール設定こそが、データ流出の最大の原因です。境界防御においては、「サーバーから外部へのアウトバウンド通信は、原則すべて拒否（Deny All）」が鉄則です。

3. 実践：インフラレベルでの遮断と監視

まずは、Webサーバーやアプリサーバーから「不用意なアウトバウンド」を発生させないための設定例を見てみましょう。

iptables / nftables での出口制限

サーバー自体が外部へFTP通信を開始するのを物理的に遮断します。

# 21番ポート(FTP)へのアウトバウンドをすべて破棄
iptables -A OUTPUT -p tcp --dport 21 -j DROP

# 20番ポート(FTPデータ)へのアウトバウンドも確実に遮断
iptables -A OUTPUT -p tcp --dport 20 -j DROP

# もしFTPを使う必要があるなら、特定の信頼できるサーバーへのみ許可する
iptables -A OUTPUT -p tcp -d 192.168.10.50 --dport 21 -j ACCEPT

Pythonでの「意図しない通信」の検知（開発者向け）

アプリケーションコードの中に、バックドア的な通信が混入していないか確認する際のデバッグ手法です。ライブラリの呼び出しをフックし、FTPが使われていないかログを残す実装例です。

import socket
import logging

# 簡易的な通信監視ロガー
logging.basicConfig(level=logging.INFO)

def monitor_socket(host, port):
    if port in [20, 21]:
        logging.warning(f"警告: 機密情報がFTPポート({port})経由で送出されようとしています！ 接続先: {host}")
        # ここで例外を投げてプロセスを落とすのがゼロトラストの作法
        raise PermissionError("禁止されたポートへのアウトバウンド接続が検知されました。")

# 実際の通信前処理に注入するイメージ
# monitor_socket("malicious-c2-server.com", 21)

4. 現代的な代替手段とセキュリティの考え方

もし、あなたが設計者として「データの転送」を実装する必要があるなら、FTPは即座に捨ててください。

SFTP (SSH File Transfer Protocol): 22 番ポートのみを使用。通信はすべてSSHで暗号化されるため、ファイアウォールでの制御が非常に容易です。
HTTPS (REST API): 443 番ポートを使用。TLS 1.3により強力に保護され、WAFやプロキシによる詳細なコンテンツ検査も可能です。

curl でのテスト

開発時に「サーバーから外への通信が本当に制限されているか」を確認するコマンドです。

# FTP経由でファイルを転送しようとする（失敗することを確認する）
curl -v ftp://external-server.com/upload.txt -T local_file.txt

# 成功するなら、それは「穴」が空いている証拠。ただちにファイアウォールを見直してください。

最後に：境界防御は「性格」が出る

ネットワークセキュリティの世界では、魔法の杖はありません。あるのは「泥臭いフィルタリングの積み重ね」と「疑う心」だけです。

「とりあえず繋がるようにしておこう」という安易な設定が、数ヶ月後の大規模インシデントの引き金になります。21 番ポートを閉じることは、単なる設定変更ではなく、「境界防御の思想を現代化する」という意思表示なのです。

もし、あなたの環境で未だに 21 番ポートがフルオープンになっているなら――今夜、その設定を修正することをお勧めします。それが、凄腕エンジニアへの第一歩ですから。