TFTP の仕組みとファイアウォール設計上の考慮点

1. 概要

TFTP（Trivial File Transfer Protocol）は、ネットワーク上でファイルを転送するための軽量なアプリケーション層プロトコルです。「Trivial（取るに足らない）」という名前の通り、TFTP はシンプルさと効率を重視して設計されており、ユーザー認証や暗号化などの付加機能を持ちません。

TFTP は RFC 1350 で定義され、UDP（User Datagram Protocol）上で動作します。これは、信頼性よりも転送速度を優先する通信方式であり、パケット再送や順序制御といった機能を持たない点で、TCP ベースの FTP（File Transfer Protocol）とは大きく異なります。

TFTP 自身がアプリケーション層で簡易的な確認応答（ACK）を行うことで、最小限の信頼性を確保します。

1.1. 特徴

TFTP は、通信の初期段階でサーバーの UDP ポート 69 にリクエストを送信しますが、以降の実際のデータ転送では別のコネクションとしてサーバーが別の高番ポートを使用します。これが、ステートフルファイアウォール環境で通信制御を行う際に考慮すべき最も重要な特性です。

1.2. 利用シーンと設計思想

TFTP は、「速度が重要で、多少の損失が許容される環境」で使用されることを前提としています。代表的な利用シーンには以下のようなものがあります。

• ネットワーク機器のファームウェア更新や設定ファイル転送
• PXE（Preboot eXecution Environment）によるネットワークブート
• 組込みデバイスの初期化・ログ転送

これらの用途では、通信が信頼できるローカルネットワーク内で行われるため、TFTPの「認証なし」「再送制御なし」「UDP 単発応答」という性質がむしろ利点となります。

1.3. 概念的な位置づけ

TFTP は、よく「しょぼい FTP」や「UDP 版 FTP」と表現されます。この言い方は軽妙ながら本質を突いており、FTP が“確実さ”を重視するプロトコルであるのに対し、TFTP は“手軽さ”と“スピード”を優先する設計思想を持っています。

言い換えるなら、TFTP は「信頼できる小規模ネットワークで、短いファイルをさっと渡すための簡易プロトコル」です。

この特性を正しく理解することが、後続のトラフィック分析やファイアウォール設計の前提になります。

1.4. 注意事項

• TFTP には認証・暗号化が存在しないため、インターネット経由での使用は推奨されません。
• ローカル LAN または VPN 環境など、外部から隔離されたセグメントで使用してください。
• UDP 通信であるため、途中のパケットロスがそのまま転送失敗につながります。
• ステートフルファイアウォール環境では、サーバー側からの高番ポート通信を明示的に許可する必要があります。

2. トラフィックフロー

TFTP 通信を正しく理解するには、アプリケーション層（プロトコル）とネットワーク層（UDP フロー）を切り分けて捉える必要があります。TFTP は UDP ベースのステートレスな通信であるため、通信の開始方向とその後のデータ転送方向が異なる点が重要です。

2.1. TFTP レイヤ

TFTP は非常に単純な構造を持ちます。ファイル転送は、次の 5 種類のメッセージで構成されます。

転送は非常にリズミカルで、「DATA → ACK → DATA → ACK」 の繰り返しで進みます。TCP のような再送制御は存在しないため、アプリ層での ACK 応答が唯一の信頼性確保手段です。

2.2. TCP/IP レイヤ

TFTP 通信の本質的な特徴は、UDP ポート 69 は初回リクエスト時にしか使われないという点です。その後のデータ転送は、サーバーがランダムな高番ポートを使用して行います。

以下に、典型的な通信シーケンスを示します。

2.2.1 GET: RRQ

このケースでは、初回通信がクライアント発、以降の通信はサーバー発となります。つまり、ファイアウォール視点では「新しい通信方向」が発生します。

2.2.1 PUT: WRQ

PUT の場合も同様に、サーバー → クライアント方向の新規フローが生じます。これにより、サーバーからクライアントへの高番ポート通信を明示的に許可しないと転送が途中で失敗します。

2.3. ファイアウォール観点から見た同一セッション構造

ステートフルファイアウォールは、「通信の 5 タプル（送信元 IP, 宛先 IP, プロトコル, 送信元ポート, 宛先ポート）」をもとにセッションを追跡します。

TFTP では、データ転送段階で **送信元ポートが変化する（69 → 動的ポート）**ため、同一セッションとして扱われないケースがあります。つまり、UDP/69 のリクエストが通っても、後続のデータ転送がブロックされる可能性があります。

ファイアウォール設計上は以下を考慮する必要があります。

2.4. 図解イメージ（通信シーケンス）

(1) Request Phase (UDP/69)
Client(53000) -> Server(69)

(2) Transfer Phase (dynamic port)
Server(35000)  →  Client(53000)

3. ネットワークセキュリティの考慮

TFTP は UDP 上で動作するため、TCP のようなセッション管理や暗号化、認証を持ちません。このため、ネットワーク設計上はシンプルさと安全性のバランスを取ることが重要です。

3.1. 運用原則

• TFTP は閉域網専用とする（インターネット越しでは使用しない）。
• 通信範囲は固定されたクライアントとサーバー間のみに限定する。
• ファイアウォールでは、UDP/69 および サーバー発高番ポート の通信を許可する。
• （オプション）サービスは 必要時のみ有効化 し、普段は停止しておく。
• 送受信ディレクトリのアクセス権限は tftpユーザー専用 に限定する。

3.2. ファイアウォール設定指針

一般的なステートフルファイアウォールの設定指針です。わかりやすくするため、ヘルパーモジュールなどの個々に依存した機能はない前提とします。

3.2.1. クライアント側ファイアウォール設定

3.2.1. サーバー側ファイアウォール設定

3.2.2. ヘルパーモジュール

Linux の iptables では TFTP 用のヘルパーモジュールが存在しており、これを有効化している場合、UDP:69 を許可していれば、関連通信を動的に許可することができるため、セキュリティ的に優れます。

他のメーカー系ファイアウォールも同様の機能があると思います。

4. まとめ

TFTP は現代では主にシステムメンテナンス用途で使用されます。

設計上シンプルである反面、通信制御を外部の仕組みに委ねる性質を持つため、システム内部の管理セグメント内で限定的に運用されることが一般的であり、インターネット経由での利用は避けます。

必要に応じてファイアウォールで通信範囲を明示的に制御し、環境に応じて常時運用または必要時のみ有効化する形で管理するのが望ましいといえます。

Related posts:

SNMPv2 のセキュリティ形骸化と使われない SNMPv3 OSPF の扱いづらさについての考察 Ubuntu 22.04 tftpd-hpa TFTP サーバー構築 Ubuntu 22.04 TFTP クライアント