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

FTPという「亡霊」が運ぶリスク:ゼロトラスト時代におけるポート20/21の終焉と制御

ネットワークエンジニアの端くれとして、深夜のパケットキャプチャを眺めているときほど、哀愁を感じる瞬間はない。画面を流れる平文のFTPパケット――USER、PASS、そしてPORTコマンド。まるで1990年代のネットワークが、現代の洗練された攻撃者たちの「格好の獲物」として、亡霊のように浮遊しているのだ。

今回は、エンタープライズの境界防御において、もはや「負債」でしかないポート 21 (FTP Control) とポート 20 (FTP Data) の流出リスクについて、現場レベルの泥臭い知見を共有したい。

—

1. なぜ「ポート20/21」はセキュリティの死角なのか

FTPの最大の問題は、そのプロトコル仕様の古さではない。「データチャネルの動的生成」という、ステートフル・インスペクションをいとも簡単に骨抜きにする仕様にある。

ActiveモードのFTPでは、クライアントが PORT コマンドで接続先IPと待受ポートを通知し、サーバー側が 20 番ポートからクライアントのそのポートへ再接続を試みる。この挙動は、境界型防御におけるファイアウォールの「内側からの接続なら許可する」という原則を逆手に取り、C2サーバーへのデータ送出を容易にする。

現代のゼロトラストアーキテクチャにおいて、この古いプロトコルを透過させていること自体が、設計上の敗北と言っても過言ではない。

—

2. パケットレベルで見る「流出」のメカニズム

機密情報が流出する際、攻撃者は多くの場合、FTP のペイロードに TCP セグメントを詰め込み、MSS (Maximum Segment Size) を意図的に小さく設定する。これは、IDS/IPSのシグネチャによる検知を逃れるための古典的だが有効なテクニックだ。

ネットワーク層での対策:iptables / nftables による徹底排除

そもそも、社内LANからインターネットへの 20 および 21 ポートの通信は、原則として DROP すべきである。もし業務上不可避な場合でも、プロキシサーバーを介した強制的なTLS化が必須だ。

# nftablesによるFTPアウトバウンドの全面禁止(緊急避難的アプローチ)
table inet filter {
    chain output {
        type filter hook output priority filter; policy accept;
        # FTP制御・データポートへのアウトバウンドを即座に破棄
        tcp dport { 20, 21 } drop comment "FTPの利用を組織的に禁止"
    }
}

—

3. パフォーマンスとセキュリティの二律背反を調律する

もし、どうしてもセキュアな転送が必要な場合、FTP を捨て SFTP (SSH File Transfer Protocol) へ完全移行することが唯一の解だ。しかし、ネットワークの遅延(RTT)が激しい環境では、SSH のフロー制御がボトルネックとなり、転送速度が劇的に低下することがある。

ここでインフラアーキテクトが手を入れるべきは、TCP バッファのチューニングだ。

カーネルパラメータによる転送効率の最適化

高遅延環境においてパケットロスが発生すると、TCP の輻輳制御アルゴリズムは CWND (Congestion Window) を縮小し、スループットを激減させる。これを防ぐために、受信バッファを拡大し、BBR (Bottleneck Bandwidth and RTT) を有効にするのが現代の定石だ。

# /etc/sysctl.conf への追記例
# 輻輳制御アルゴリズムをBBRに設定
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# TCPウィンドウサイズを拡大し、高RTT環境での帯域利用率を向上
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

—

4. ゼロトラスト的アプローチ:可視化と検知

境界でパケットを止めるだけでなく、内部で「何が」起きているかを把握する必要がある。例えば、TLS で暗号化された通信であっても、SNI (Server Name Indication) や証明書の不一致から、不正な宛先を特定できる。

以下は、不審なFTP/SFTPトラフィックの接続先をトラッキングするための簡易的なPythonによる監視ロジックの概念だ。

import socket

def monitor_outbound_connections():
    # 実際にはscapy等でパケットの宛先ポートをリアルタイム監視する
    # ポート21へのSYNパケットを検知した場合にログを吐き出す
    print("WARNING: FTP outbound attempt detected via monitoring agent.")

# ゼロトラスト環境下では、エンドポイントのプロセスとネットワークを紐づける
# 「どのユーザーがどのプロセスを使ってポート21を叩いたか」が全て

—

最後に:エンジニアとしての矜持

ポート 21 を開けっ放しにしていることは、鍵の壊れた玄関に「ご自由にお入りください」という張り紙をしているのと同じだ。

我々スペシャリストに求められているのは、単にファイアウォールを閉じることではない。プロトコルの挙動を理解し、その上で「なぜその通信が必要なのか」「代替手段はないのか」という問いを突き詰め、インフラの深層で徹底的にガードレールを敷くことだ。

ネットワークは嘘をつかない。パケットは、構築した人間の設計思想を雄弁に物語る。今日の設計が、明日の脆弱性にならないよう、常にプロトコルの「裏側」を意識してほしい。

コメント

タイトルとURLをコピーしました