序文

ちょうど XNUMX 週間前、私はタイトルに示したテーマについてエッセイを書いていたのですが、インターネット上には教育情報がそれほど多くないという事実に直面しました。 主に乾いた事実とセットアップ手順。 そこで、本文を少し修正して記事として投稿することにしました。

FTPとは

FTP (File Transfer Protocol) は、ネットワーク上でファイルを転送するためのプロトコルです。 これは、基本的なイーサネット プロトコルの 1971 つです。 959 年に登場し、当初は DARPA ネットワークで活動していました。 現在、HTTP と同様に、ファイル転送は一連の TCP/IP (伝送制御プロトコル/インターネット プロトコル) プロトコルで構成されるモデルに基づいています。 RFC XNUMX で定義されています。

プロトコルでは次のことが定義されています。

• エラーチェックはどのように行われるのでしょうか？
• データのパッケージ化方法（パッケージ化を使用する場合）
• 送信側デバイスはメッセージが終了したことをどのようにして示すのでしょうか?
• 受信デバイスはメッセージを受信したことをどのようにして示すのでしょうか?

クライアントとサーバー間の通信

FTP 操作中に発生するプロセスを詳しく見てみましょう。 接続はユーザーのプロトコル インタプリタによって初期化されます。 交換機は、TELNET 標準の制御チャネルを介して制御されます。 FTP コマンドは、ユーザーのプロトコル インタプリタによって生成され、サーバーに送信されます。 サーバーの応答は、制御チャネル経由でユーザーにも送信されます。 一般に、ユーザーはサーバーのプロトコル インタプリタとの接続を、ユーザーのインタプリタ以外の手段で確立することができます。

FTP の主な特徴は、二重接続を使用することです。 そのうちの 21 つはサーバーにコマンドを送信するために使用され、デフォルトでは TCP ポート XNUMX 経由で行われますが、これは変更可能です。 制御接続は、クライアントがサーバーと通信している限り存在します。 マシン間でデータを転送するときは、制御チャネルが開いている必要があります。 閉じるとデータ送信が停止します。 XNUMX 番目の方法では、直接データ転送が行われます。 クライアントとサーバー間でファイル転送が発生するたびに開きます。 複数のファイルが同時に転送される場合、それぞれのファイルが独自の伝送チャネルを開きます。

FTP はアクティブ モードまたはパッシブ モードで動作でき、どちらを選択するかによって接続の確立方法が決まります。 アクティブ モードでは、クライアントはサーバーとの TCP 制御接続を作成し、その IP アドレスと任意のクライアント ポート番号をサーバーに送信し、サーバーがこのアドレスとポート番号を使用して TCP 接続を開始するのを待ちます。 クライアントがファイアウォールの背後にあり、受信 TCP 接続を受け入れることができない場合は、パッシブ モードを使用できます。 このモードでは、クライアントは制御フローを使用して PASV コマンドをサーバーに送信し、サーバーから IP アドレスとポート番号を受け取ります。その後、クライアントはそれを使用して任意のポートからデータ フローを開きます。

データが XNUMX 台目のマシンに転送される可能性があります。 この場合、ユーザーは XNUMX つのサーバーで制御チャネルを構成し、それらの間の直接データ チャネルを構成します。 制御コマンドはユーザーを介して送信され、データはサーバー間で直接送信されます。

ネットワーク経由でデータを送信する場合、次の XNUMX つのデータ表現を使用できます。

• ASCII – テキストに使用されます。 データは、必要に応じて、送信前に送信ホスト上の文字表現から「XNUMX ビット ASCII」に変換され、(必要に応じて再度) 受信ホスト上の文字表現に変換されます。 特に改行文字が変更されます。 そのため、このモードはプレーン テキスト以上のファイルを含むファイルには適していません。
• バイナリ モード - 送信デバイスは各ファイルをバイト単位で送信し、受信者は受信時にバイト ストリームを保存します。 このモードのサポートは、すべての FTP 実装に対して推奨されています。
• EBCDIC – EBCDIC エンコーディングでホスト間でプレーン テキストを転送するために使用されます。 それ以外の点では、このモードは ASCII モードと似ています。
• ローカル モード - 同一の設定を持つ XNUMX 台のコンピュータが、ASCII に変換せずに独自の形式でデータを送信できるようにします。

データ転送は、次の XNUMX つのモードのいずれかで実行できます。

• ストリーム モード - データは連続ストリームとして送信され、FTP による処理の実行が不要になります。 代わりに、すべての処理は TCP によって実行されます。 ファイルの終わりインジケーターは、データをレコードに分割する場合を除いて必要ありません。
• ブロック モード - FTP はデータをいくつかのブロック (ヘッダー ブロック、バイト数、データ フィールド) に分割し、TCP に送信します。
• 圧縮モード – データは単一のアルゴリズムを使用して圧縮されます (通常はランレングスをエンコードすることによって)。

FTP サーバーは、ファイル転送プロトコルを使用する機能を提供するサーバーです。 従来の Web サーバーとは異なるいくつかの機能があります。

• ユーザー認証が必要です
• すべての操作は現在のセッション内で実行されます
• ファイル システムでさまざまなアクションを実行する機能
• 接続ごとに別のチャネルが使用されます

FTP クライアントは、FTP 経由でリモート サーバーに接続し、ファイル システムの要素を使用してリモート サーバー上で必要なアクションを実行できるようにするプログラムです。 クライアントはブラウザである可能性が高く、そのアドレス バーには、一般的な URL ブロック図に従って、リモート サーバー上の特定のディレクトリまたはファイルへのパスであるアドレスを入力する必要があります。

ftp://user:pass@address:port/directory/file

ただし、このコンテキストで Web ブラウザを使用すると、目的のファイルの表示またはダウンロードのみが可能になります。 FTP の利点をすべて最大限に活用するには、クライアントとして専用のソフトウェアを使用する必要があります。

FTP 認証では、ユーザー名/パスワード スキームを使用してアクセスを許可します。 ユーザー名は USER コマンドでサーバーに送信され、パスワードは PASS コマンドで送信されます。 クライアントによって提供された情報がサーバーによって受け入れられると、サーバーはクライアントに招待を送信し、セッションが開始されます。 サーバーがこの機能をサポートしている場合、ユーザーは資格情報を提供せずにログインできますが、サーバーはそのようなセッションに対して限定的なアクセスしか許可できません。

FTP サービスを提供するホストは、匿名 FTP アクセスを提供できます。 ユーザーは通常、ユーザー名として「anonymous」(一部の FTP サーバーでは大文字と小文字が区別される場合があります) を使用してログインします。 通常、ユーザーはパスワードの代わりに電子メール アドレスの入力を求められますが、実際には検証は行われません。 ソフトウェア更新を提供する多くの FTP ホストは、匿名アクセスをサポートしています。

プロトコル図

FTP 接続中のクライアントとサーバーの対話は、次のように視覚化できます。

セキュアFTP

FTP は当初、複数の軍事施設や機関間の通信を目的としていたため、安全性を確保することを目的としたものではありませんでした。 しかし、インターネットの発展と普及に伴い、不正アクセスの危険性は何倍にも高まっています。 さまざまな種類の攻撃からサーバーを保護する必要がありました。 1999 年 2577 月、RFC XNUMX の作成者は、脆弱性を次の問題リストにまとめました。

• 隠し攻撃（バウンス攻撃）
• スプーフィング攻撃
• ブルートフォース攻撃
• パケットキャプチャ、スニッフィング
• ポート盗用

通常の FTP には暗号化された形式でデータを転送する機能がないため、ユーザー名、パスワード、コマンド、その他の情報が攻撃者によって簡単かつ簡単に傍受される可能性があります。 この問題に対する通常の解決策は、脆弱なプロトコル (FTPS) の「安全な」TLS で保護されたバージョン、またはほとんどの Secure Shell プロトコル実装で提供される SFTP/SCP などのより安全な別のプロトコルを使用することです。

FTPS

FTPS (FTP + SSL) は、標準のファイル転送プロトコルの拡張機能であり、その基本機能に SSL (Secure Sockets Layer) プロトコルを使用した暗号化セッションの作成が追加されています。 現在、保護はより高度なアナログ TLS (Transport Layer Security) によって提供されています。

SSL

SSL プロトコルは、インターネット接続のセキュリティとプライバシーを確​​保するために、1996 年に Netscape Communications によって提案されました。 このプロトコルはクライアントとサーバーの認証をサポートし、アプリケーションに依存せず、HTTP、FTP、および Telnet プロトコルに対して透過的です。

SSL ハンドシェイク プロトコルは、サーバー認証とオプションのクライアント認証の XNUMX つの段階で構成されます。 最初の段階で、サーバーは証明書と暗号化パラメーターを送信することでクライアントの要求に応答します。 次に、クライアントはマスター キーを生成し、サーバーの公開キーで暗号化し、サーバーに送信します。 サーバーは、秘密キーを使用してマスター キーを復号化し、クライアントのマスター キーによって認証されたメッセージを返すことによってクライアントに対してサーバー自身を認証します。

後続のデータは、このマスター キーから派生したキーを使用して暗号化され、認証されます。 XNUMX 番目のステップ (オプション) では、サーバーがクライアントにリクエストを送信し、クライアントは独自のデジタル署名と公開キー証明書を含むリクエストを返すことでサーバーに対して自身を認証します。

SSL はさまざまな暗号化アルゴリズムをサポートしています。 通信の確立中に、RSA 公開キー暗号化システムが使用されます。 キー交換後、RC2、RC4、IDEA、DES、TripleDES などのさまざまな暗号が使用されます。 メッセージ ダイジェストを作成するアルゴリズムである MD5 も使用されます。 公開キー証明書の構文は X.509 で説明されています。

SSL の重要な利点の XNUMX つは、ソフトウェア プラットフォームから完全に独立していることです。 このプロトコルは移植性の原則に基づいて開発されており、その構築のイデオロギーはそれが使用されるアプリケーションに依存しません。 さらに、SSL プロトコルの上に他のプロトコルを透過的にオーバーレイできることも重要です。 ターゲットの情報フローの保護の度合いをさらに高めるか、SSL の暗号化機能を他の明確に定義されたタスクに適応させるためです。

SSL接続

SSL によって提供される安全なチャネルには、次の XNUMX つの主要なプロパティがあります。

• チャンネルはプライベートです。 秘密鍵を決定するための簡単な対話の後、すべてのメッセージに暗号化が使用されます。
• チャネルは認証されています。 会話のサーバー側は常に認証されますが、クライアント側はオプションで認証されます。
• チャンネルは信頼できます。 メッセージのトランスポートには、(MAC を使用した) 整合性チェックが含まれます。

FTPSの特徴

FTPS には、セキュリティを提供する異なる方法を使用する XNUMX つの実装があります。

• 暗黙的な方法では、データを送信する前に標準の SSL プロトコルを使用してセッションを確立する必要があるため、通常の FTP クライアントおよびサーバーとの互換性が失われます。 FTPS をサポートしないクライアントとの下位互換性のために、TCP ポート 990 が制御接続に使用され、989 がデータ転送に使用され、FTP プロトコルの標準ポート 21 が維持されます。 この方法は時代遅れであると考えられています。
• Explicit の方がはるかに便利です。標準の FTP コマンドを使用しますが、応答時にデータが暗号化されるため、FTP と FTPS の両方で同じ制御接続を使用できます。 クライアントはサーバーからの安全なデータ転送を明示的に要求し、暗号化方法を承認する必要があります。 クライアントが安全な転送を要求しない場合、FTPS サーバーは安全でない接続を維持するか閉じる権利を持ちます。 認証およびデータ セキュリティ ネゴシエーション メカニズムが、新しい FTP AUTH コマンドを含む RFC 2228 に基づいて追加されました。 この標準はセキュリティ メカニズムを明示的に定義していませんが、クライアントが上記のアルゴリズムを使用して安全な接続を開始する必要があることを指定しています。 サーバーが安全な接続をサポートしていない場合は、エラー コード 504 が返される必要があります。FTPS クライアントは、FEAT コマンドを使用して、サーバーがサポートするセキュリティ プロトコルに関する情報を取得できますが、サーバーは、どのセキュリティ レベルを公開する必要はありません。サポートします。 最も一般的な FTPS コマンドは AUTH TLS と AUTH SSL で、それぞれ TLS と SSL セキュリティを提供します。

SFTP

SFTP (Secure File Transfer Protocol) は、安全なチャネル上で実行されるアプリケーション層のファイル転送プロトコルです。 同じ略語を持つ (Simple File Transfer Protocol) と混同しないでください。 FTPS が単に FTP の拡張である場合、SFTP は SSH (Secure Shell) を基礎として使用する別個の関連性のないプロトコルです。

セキュアシェル

このプロトコルは、Secsh と呼ばれる IETF グループの 14 つによって開発されました。 新しい SFTP プロトコルの実用的なドキュメントは正式な標準にはなりませんでしたが、アプリケーション開発に積極的に使用され始めました。 その後、プロトコルの 2006 つのバージョンがリリースされました。 しかし、機能が徐々に増加したため、XNUMX 年 XNUMX 月 XNUMX 日に、プロジェクトの主要なタスク (SSH 開発) が完了し、機能が不足しているため、プロトコルの開発作業を中止することが決定されました。本格的なリモート ファイル システム プロトコルの開発に進むのに十分な専門家レベルを備えています。

SSH は、オペレーティング システムのリモート制御と TCP 接続のトンネリング (ファイル転送など) を可能にするネットワーク プロトコルです。 Telnet プロトコルや rlogin プロトコルと機能的には似ていますが、それらとは異なり、送信されるパスワードを含むすべてのトラフィックが暗号化されます。 SSH では、さまざまな暗号化アルゴリズムを選択できます。 SSH クライアントと SSH サーバーは、ほとんどのネットワーク オペレーティング システムで使用できます。

SSH を使用すると、セキュリティで保護されていない環境でも、他のほぼすべてのネットワーク プロトコルを安全に転送できます。 したがって、コマンド シェルを使用してコンピュータ上でリモート作業できるだけでなく、暗号化されたチャネルを介してオーディオ ストリームやビデオ (Web カメラなどから) を送信することもできます。 SSH は、後続の暗号化のために送信データの圧縮を使用することもできます。これは、たとえば、X WindowSystem クライアントをリモートで起動する場合に便利です。

プロトコルの最初のバージョンである SSH-1 は、ヘルシンキ工科大学 (フィンランド) の研究者 Tatu Ulönen によって 1995 年に開発されました。 SSH-1 は、rlogin、telnet、rsh プロトコルよりも優れたプライバシーを提供するために作成されました。 1996 年に、プロトコルのより安全なバージョンである SSH-2 が開発されましたが、これは SSH-1 とは互換性がありません。 このプロトコルはさらに人気を博し、2000 年までに約 2 万人のユーザーを抱えていました。 現在、「SSH」という用語は通常 SSH-2006 を意味します。 このプロトコルの最初のバージョンは、重大な欠点があるため、現在では実際には使用されていません。 XNUMX 年に、このプロトコルは IETF ワーキング グループによってインターネット標準として承認されました。

SSH には、プライベート商用と無料のオープンソースという 2006 つの一般的な実装があります。 無料の実装は OpenSSH と呼ばれます。 80 年までに、インターネット上のコンピュータの XNUMX% が OpenSSH を使用しました。 この独自の実装は、Tectia Corporation の完全子会社である SSH Communications Security によって開発されており、非営利目的での使用は無料です。 これらの実装には、ほぼ同じコマンドのセットが含まれています。

SSH-2 プロトコルは、Telnet プロトコルとは異なり、トラフィック盗聴攻撃 (「スニッフィング」) には耐性がありますが、中間者攻撃には耐性がありません。 SSH-2 プロトコルは、すでに確立されているセッションに参加したりハイジャックしたりすることができないため、セッション ハイジャック攻撃にも耐性があります。

キーがクライアントにまだ知られていないホストに接続するときの中間者攻撃を防ぐために、クライアント ソフトウェアはユーザーに「キー フィンガープリント」を表示します。 クライアント ソフトウェアによって表示される「キー スナップショット」と、できれば信頼できる通信チャネルを通じてまたは直接取得したサーバー キー スナップショットを注意深く確認することをお勧めします。

SSH サポートはすべての UNIX 系システムで利用でき、ほとんどのシステムには標準ユーティリティとして ssh クライアントとサーバーが含まれています。 非 UNIX OS 用の SSH クライアントの実装は数多くあります。 このプロトコルは、重要なノードを管理するための安全でない Telnet プロトコルの代替ソリューションとして、トラフィック アナライザーとローカル ネットワークの運用を中断する方法が広く開発された後、非常に人気を得ました。

SSHを使用した通信

SSH 経由で動作するには、SSH サーバーと SSH クライアントが必要です。 サーバーはクライアント マシンからの接続をリッスンし、接続が確立されると認証を実行し、その後クライアントへのサービスを開始します。 クライアントは、リモート マシンにログインしてコマンドを実行するために使用されます。

FTPSとの比較

SFTP が標準の FTP および FTPS と異なる主な点は、SFTP がすべてのコマンド、ユーザー名、パスワード、およびその他の機密情報を完全に暗号化することです。

FTPS プロトコルと SFTP プロトコルはどちらも、非対称アルゴリズム (RSA、DSA)、対称アルゴリズム (DES/3DES、AES、Twhofish など)、およびキー交換アルゴリズムの組み合わせを使用します。 認証には、FTPS (より正確には、FTP 上の SSL/TLS) は X.509 証明書を使用しますが、SFTP (SSH プロトコル) は SSH キーを使用します。

X.509 証明書には、公開キーと所有者の証明書に関するいくつかの情報が含まれています。 一方、この情報を使用すると、証明書自体の整合性、証明書の信頼性、所有者を検証できます。 X.509 証明書には対応する秘密キーがあり、通常、セキュリティ上の理由から証明書とは別に保存されます。

SSH キーには公開キーのみが含まれます (対応する秘密キーは別に保存されます)。 キーの所有者に関する情報は含まれません。 一部の SSH 実装では認証に X.509 証明書を使用しますが、実際には証明書チェーン全体を検証するわけではなく、公開キーのみが使用されます (このような認証は不完全になります)。

まとめ

FTP プロトコルは、古くからあるにもかかわらず、ネットワーク上の情報の保存と配布において依然として重要な役割を果たしているのは間違いありません。 これは便利で多機能な標準化されたプロトコルです。 多くのファイル アーカイブはこれに基づいて構築されており、これがなければ技術的な作業はそれほど効果的ではありません。 さらに、セットアップが簡単で、サーバーおよびクライアント プログラムは、現在およびそれほど最新ではないほぼすべてのプラットフォームに対応しています。

さらに、その保護されたバージョンは、現代社会における保存および送信データの機密性の問題を解決します。 どちらの新しいプロトコルにも長所と短所があり、役割が少し異なります。 ファイル アーカイブが必要な領域では、特に従来の FTP がすでに使用されている場合は、FTPS を使用することをお勧めします。 SFTP は古いプロトコルと互換性がないためあまり一般的ではありませんが、リモート管理システムの一部であるため、安全性が高く、より多くの機能を備えています。

ソースのリスト

• 概要「FTP プロトコル。 一般的な情報と機能」
• 要約「SSH、CMIP、Telnet プロトコル」
• レポート「SSL/TLS」

出所： habr.com