1 ファイル転送プロトコル（FTP）とは

1-1 FTPとは

FTPは、File Transfer Protocol の略で、インターネットなどのIPネットワークにおいて異なるコンピュータ間でファイルを転送するためのプロトコルであり、IETFによってRFC 959で定義されている。OSI参照モデルのアプリケーション層に位置し、トランスポート層での通信にはTCPを用いる。
　インターネットでは、作成したWeb用のファイルをWebサーバに転送したり、拠点間でのファイルのやりとりなどで用いられたりする。
　FTPは、HTTPやSMTPなどのプロトコルと同様にTCPコネクションが確立された後は、そのTCPコネクション(仮想的な通り道)を利用してクライアントとサーバの間でデータのやり取りがされる。
　クライアントからサーバへのデータを「コマンド」と呼び、3-4文字の英字でその意味を表す。(USER、PASS、NOOPなど)
　また、サーバからクライアントへのデータをレスポンスと呼び、3桁の数字でその意味を表す。(220、331、230、など)

　

100番台　肯定的な予備応答
　 200番台　肯定的な完了応答　通常の完了を示す
　 300番台　肯定的な中間応答　正常な動作だが、引き続き追加のコマンドを必要としている
　 400番台　一時的な否定応答　一時的な理由で完了されなかった
　 500番台　否定応答 何らかの理由で完了されなかった

　

しかし、HTTPやSMTPなどのプロトコルは1つのTCPコネクションを利用するのに対し、FTPは2つのTCPコネクションを利用する。
　1つ目のTCPコネクションは、制御コネクションと呼ばれ、FTPを制御するためのコネクションであり、ポート番号21(FTP)が用いられる。
　 2つ目のTCPコネクションは、データコネクションと呼ばれ、ファイルやファイル一覧などのデータを転送するためのコネクションである。PORTモードでは、ポート番号20(FTP-DATA)が用いられる。

1-2 FTPの流れ

それでは、実際のFTPのパケットの流れをみてみよう。
　 パケットの内容については、本講座の第1回目から6回目で解説している。
　 FTPクライアント(ノートPC)のIPアドレスは、192.168.11.3で社内ネットワークにある。FTPサーバのIPアドレスは、117.120.49.215でインターネット上にある。

図1 パケット解析結果

図2　コマンドのやり取り

＜パケット1＞では、FTPクライアント(ポート番号:3467)からFTPサーバ(ポート番号:21/FTP)に、コネクション確立要求(SYN)パケットを出している。
　＜パケット2＞で、FTPサーバからFTPクライアントにコネクション確立要求への応答(ACK)と、あらためてFTPサーバからFTPクライアントにコネクション確立要求(SYN)パケットを出している。
　＜パケット3＞で、FTPクライアントからFTPサーバにコネクション確立要求への応答(ACK)パケットを出している。

　

この3つのパケットでFTPクライアント(IPアドレス:192.168.11.3、ポート番号:3467)とFTPサーバ(IPアドレス:117.120.49.215、ポート番号:21/FTP)でTCPコネクション(制御コネクション)が確立した。(3way handshake)

　

＜パケット5＞と＜パケット8＞で、クライアントからサーバにユーザ名とパスワードがコマンドとして送信される。FTPサーバが認証して「ログイン」状態となる。「ログイン」のためのプロトコルには、POP3やTELNETなどがある。このあと＜パケット9＞からは、しばらくFTPクライアントとFTPサーバのやり取りが続く。

コラム：anonymous FTP
anonymousとは匿名という意味で、「anonymous FTP」は、不特定多数にファイルを配布できる。さきほどのパケットをみてきたようなユーザ名、パスワードによる認証を必要としない。公共団体や大学のサイトなどで運用されている。 　基本的にはFTPコマンドを必要とするが、Internet Explorerなど多くのWebブラウザでは、アドレスに「ftp://〜」と記述するだけで、anonymous FTPサイトに直接アクセスして利用できる。

次に、＜パケット19＞をみてみよう。FTPクライアントからFTPサーバへのパケットである。データ部を見ると「PORT 192, 168, 11, 3, 13, 140」とある。PORTコマンドの記述ルールは、以下のとおり。

　

　　　　　　PORT h1,h2,h3,h4,p1,p2

　

このうち"h1,h2,h3,h4"がIPアドレス、"p1,p2"がポート番号となる。

　

ポート番号の長さは、送信元・あて先ともに16ビットである。組み合わせでいえば(2の16乗)=65536とおりある。ポート番号は、ほとんどの場合10進数で表記される(0-65535の間)。FTP のPORTコマンドでは、わざわざ2つの数値(p1,p2)に分けて送信するルールになっている。

　

そこで、IPアドレスは、もともと32ビットである。これを2進数表記すると32桁の"0"と"1"の羅列となるのでわかりにくい。16進数表記ならば"0"-"F"の8桁であるがこれも馴染みにくい。そこで、IPアドレスを8ビットずつ4つのブロックに分け、それぞれのブロックを10進数にして表記する方法(例:117.120.49.215)、つまりよく見かけるIPアドレスの形式だが、PORTコマンドではこのように、IPアドレスを10進数表記した4つの数字を"h1,h2,h3,h4"という形にしている。

　

ポート番号は16ビットなのでIPアドレスの10進数表記のルールと同様に8ビットずつ2つのブロックに分け、それぞれのブロックを10進数にして2つの数字を"p1,p2"という形にしている。

　

例　ポート番号　(10進数) "3468"の場合

　

(2進数)とすると "00001011 10001010"となる。

　

上位8ビット00001011→(10進数) →13→p1
　 下位8ビット10001010→(10進数) →140→p2

　

よって計算式は、p1,p2 p1×(16の2乗)＋p2×(16の0乗)となる。

　

改めて＜パケット19＞をみてみると、この場合、IPアドレスは192.168.11.3でFTPクライアント自身のIPアドレス。次の「13, 140」の部分がポート番号だ。先の計算式をあてはめると、

　

13×(16の2乗)＋140×(16の0乗)＝13×256＋140=3468

　

つまりポート番号は「3468」となる。

　

＜パケット21＞で、FTPクライアントからFTPサーバへ「NLST」という、ファイル名の一覧表の要求コマンドを送信している。制御コネクションで、FTPクライアントからFTPサーバに対しFTPサービスへのコマンドが送られると、その都度データコネクションが確立される。コマンドの内容には、ファイル名の一覧表の取得、FTPサーバへのファイルのアップロード、FTPサーバからのファイルのダウンロード、FTPサーバのファイルの削除、FTPサーバのディレクトリの作成・消去などがある。
　＜パケット22＞で、FTPサーバ(ポート番号:20/FTP-DATA)からFTPクライアント(ポート番号:3468)に、コネクション確立要求(SYN)パケットを出している。
　＜パケット23＞で、FTPクライアントからFTPサーバにコネクション確立要求への応答(ACK)と、あらためてFTPクライアントからFTPサーバにコネクション確立要求(SYN)パケットを出している。
　＜パケット25＞で、FTPサーバからFTPクライアントにコネクション確立要求への応答(ACK)パケットを出している。

　

＜パケット22＞から＜パケット25＞までの3つのパケットで、FTPサーバ(IPアドレス:117.120.49.215、ポート番号:20/FTP-DATA)とFTPクライアント(IPアドレス:192.168.11.3、ポート番号:3468)とでTCPコネクション(データコネクション)が確立した。(3way handshake)

　

＜パケット22＞に着目してみよう。TCPを用いるアプリケーション層のプロトコルの多くは、まずクライアントからサーバにコネクション確立要求(SYN)パケットを出す。しかし、FTPのデータコネクションは、サーバからクライアントにコネクション確立要求(SYN)パケットを出している。その際、FTPサーバから見た相手先であるFTPクライアントのIPアドレスやポート番号(3468)は、＜パケット19＞で通知されている。このあとのパケットは省略されているが、FTPサーバがファイル一覧表のデータを送信後、このデータコネクションは切断される。FTPサービスへのコマンドが送られると、あらためてデータコネクションを確立する。

コラム：2つのコネクション
なぜFTPは制御用とデータ用の2つのコネクションを使用するのだろうか？もっと単純化できなかったのだろうか？ 　2つのコネクションを使用することの利点はいくつかあるのだが、代表的なものをあげる。 　 ・FTPサーバを制御するコンピュータとファイル転送するコンピュータが異なってもいい。 ・大規模ファイルの転送中に、制御コネクションを用いてキャンセルすることができる。 　 　制御用とデータ用、それぞれのプロトコルを個別にみると、とても単純である。しかし、この2つのプロトコルが連携しながら目的を遂行(ファイル転送)していく様子は、2つの楽器が奏でるハーモニーのように実に奥深いのである。

2 「Gumblar」攻撃はここにまで！？FTPの問題点

2-1 FTPのセキュリティ

先述のとおり、FTPは、IPネットワークの草創期からある歴史あるプロトコルであり、もともと利用者はごく限られた人数であったため、平文によるパスワード認証はあったが、プロトコル自体のセキュリティ対策は講じられていなかった。しかし、その後のインターネットの爆発的な普及によって、不特定多数の人が利用するようになり、そのためセキュリティ対策を講じる必要が生じてきた。
　FTP自体が持つセキュリティ機能は、前述のとおり、ユーザ名・パスワードによる認証しかない。パスワードは暗号化されていないので容易に解読されてしまうし、ファイルデータそのものの盗聴も難しくない。
　ファイル転送のセキュリティ向上のためには、ワンタイムパスワード(使い捨てパスワード)の利用や、SFTPやSCPといった暗号化プロトコルの利用が可能だ。
　SFTP、SCPともにSSH(Secure SHell)を利用して暗号化通信を行うが、本来のファイルを転送する時間に加えて暗号化／復号するための時間を要するというデメリットもある。SFTP(SSH File Transfer Protocol/Secure File Transfer Protocol)は、FTPコマンドをSSHの機能によって暗号化・復号して、FTPサーバに送信する（図3上）。 SCP(Secure Copy)は、UNIXシェルのファイルコピー機能を用いてファイルのやり取りをする（図3下）。

図3　SFTPとSCPの仕組み

コラム：FTPは要注意！Gumblar攻撃による被害

昨年(2009年)後半より、Gumblar攻撃による被害が増加しており、大手企業サイトが被害にあったという報道が相次いでいる。FTPによってWebサイトの更新を行っているPCもGumblar攻撃の対象となっており、わが国でも被害報告があるので注意が必要だ。 　 　Gumblar攻撃の手口は、以下のとおり。 　 1. 悪意のある者がある一般のWebサイトにウイルスを埋め込む。 2. そのWebサイトを閲覧したPCがウイルスに感染する。 3. ウイルスによって、PCに登録されている自身が管理するWebサイトにFTPでログインするためのユーザ名、パスワードが悪意のあるものに知られてしまう。 4. 悪意のあるものが盗み取ったユーザ名、パスワードでWebサイトを改ざんする。 　 　この1.〜4.を繰り返しながら伝播していく。 　 　いくら暗号化対策を施していても、こういった攻撃には効果がない。Webサイトに「FTP Scanner」というFTPでアクセス元の情報収集をするためのツールを埋め込まれてしまったケースもある。 　Webサイトを管理するPCにもウイルス感染しないよう十分なセキュリティ対策が必要である。 　また、Webサイトにアクセス制限を設けたり、アクセスログを小まめにチェックするなどのセキュリティ対策も必要だ。

2-2 IPデータ部のIPアドレスを正しく変換できない

パケットによっては、IPヘッダ部の送信元IPアドレス、あて先IPアドレスのほかに、IPデータ部にIPアドレスが包含されていることがある。プライベートアドレスの運用やプロキシサーバによって、IPアドレスの変換が行われるが、変換されるのはあくまでもIPヘッダにあるIPアドレスであって、IPデータ部にあるIPアドレスまでは変換されない。
　しかし、近年のアドレス変換をする機器やプロキシサーバなどでは、プロトコルがFTPであって、PORTコマンドの場合、IPヘッダのIPアドレスと一緒にIPデータ部のIPアドレスを変換する機能を持つこともある。また、IPデータ部を暗号化する場合、暗号化装置とアドレスを変換する装置との順番によっては、正しく変換されないことがあるので注意が必要である。

2-3 ファイアウォールによる通信の遮断とPASVモード

FTPのデータコネクションは、FTPサーバからFTPクライアントに対しコネクション確立要求を行う。たいていのFTPクライアントは、社内ネットワークにある。またFTPサーバはインターネットを介して存在する。
　インターネットと社内ネットワークの間にファイアウォールを設置する。多くの場合、ファイアウォールの初期設定では、内部ネットワークのコンピュータから外部(インターネット)のコンピュータへのコネクション確立要求パケットは許可するが、外部(インターネット)から内部へのコネクション確立要求パケットは遮断する。したがって、ファイアウォールが原因で、制御コネクションが確立してもデータコネクションが確立できないケースが出てくるので、注意が必要だ。
　この問題は、次に述べるPASVモードで解決できる。

図4　FTP使用時のファイアウォールの仕組み

図5　パケット解析結果

図6　コマンドのやり取り

図5のパケットを見てほしい。＜パケット1＞で、FTPクライアント(ポート番号:3423)からFTPサーバ(ポート番号:21/FTP)に、コネクション確立要求(SYN)パケットを出している。
　＜パケット2＞で、FTPサーバからFTPクライアントにコネクション確立要求への応答(ACK)と、あらためてFTPサーバからFTPクライアントにコネクション確立要求(SYN)パケットを出している。
　＜パケット3＞で、FTPクライアントからFTPサーバにコネクション確立要求への応答(ACK)パケットを出している。
　この3つのパケットでFTPクライアント(IPアドレス:192.168.11.3、ポート番号:3423)とFTPサーバ(IPアドレス:117.120.49.215、ポート番号:21/FTP)でTCPコネクション(制御コネクション)が確立した。(3way handshake)
　＜パケット5＞と＜パケット8＞で、クライアントからサーバにユーザ名とパスワードがコマンドとして送信される。FTPサーバが認証して「ログイン」状態となったあと、しばらく、FTPクライアントとFTPサーバのやり取りが続く。

　

次に＜パケット20＞をみてみよう。FTPクライアントからFTPサーバへのパケットである。データ部を見ると「PASV」とある。
　PASVコマンドは、データコネクションをFTPサーバからFTPクライアントに確立するのではなく、FTPクライアントからFTPサーバに確立するモード(PASSIVE MODE)の宣言である。
　＜パケット21＞は、FTPサーバからFTPクライアントへのパケットである。データ部を見ると「227 Entering Passive Mode (117, 120, 49, 215, 159, 89)」とある。これは、レスポンスコード「227」に続いて、このあとデータ転送用のコネクションに使用するIPアドレスとポート番号を指定している。この場合、IPアドレスは117. 120. 49. 215で、FTPサーバ自分自身のIPアドレスである。
　ポート番号は、続く「159, 89」の部分は、計算が必要である。

　

159×(16の2乗)＋89×(16の0乗)＝159×256＋89=40793

　

これらの情報をFTPクライアントに送っている。
　＜パケット22＞で、FTPクライアントからFTPサーバへ「NLST」ファイル名の一覧表の要求コマンドを送信している。
　＜パケット23＞で、FTPクライアント(ポート番号:3424)からFTPサーバ(ポート番号:40793)に、コネクション確立要求(SYN)パケットを出している。
　＜パケット24＞で、FTPサーバからFTPクライアントにコネクション確立要求への応答(ACK)と、あらためてFTPサーバからFTPクライアントにコネクション確立要求(SYN)パケットを出している。
　＜パケット25＞で、FTPクライアントからFTPサーバにコネクション確立要求への応答(ACK)パケットを出している。
　＜パケット23＞から＜パケット25＞の3つのパケットで、FTPクライアント(IPアドレス:192.168.11.3、ポート番号:3424)とFTPサーバ(IPアドレス:117.120.49.215、ポート番号:40793)とでTCPコネクション(データコネクション)が確立した。(3way handshake)
　ほかのTCPを用いるアプリケーション層のプロトコルと同様に、クライアントからサーバにコネクション確立要求(SYN)パケットを出している。これをPASSIVE MODEまたはACTIVE MODEと呼ぶ。

【次回予告】 現在一般に使われているIPv4のアドレス長は32ビットである。理論的には約40億通りの組み合わせが可能だが、現状のインターネットの普及のペースを見るとアドレスの枯渇は時間の問題である。プライベートアドレス、CIDRなどの運用でこれまでなんとか凌いできたが、アドレス枯渇問題の一番の切り札はIPv6である。 　なかなか普及が進まなかったが、近年のIP電話の普及などで、IPv6の普及が加速化してきた。次回は、IPv6の基本、IPv4との違いなどについて解説する。

取材協力 ： アイテック