fwknop - シングルパケット認証

はじめに

fwknopは、サービスを強力に隠蔽するためのシングルパケット認証（SPA）と呼ばれる認証スキームを実装しています。SPAは、デフォルトドロップフィルタリングポリシーのファイアウォールの背後に隠されたサービスへのアクセス希望を伝えるために、暗号化され、リプレイ不可能で、HMACによって認証された単一のパケットのみを必要とします。SPAの主な用途は、ファイアウォールを使用してSSHなどのサービスへの接続試行をすべてドロップし、脆弱性（0-dayおよび未パッチコードの両方）の悪用をより困難にすることです。開いているポートがないため、SPAで隠蔽されたサービスはNmapでスキャンすることはできません。fwknopプロジェクトは、Linux、OpenBSD、FreeBSD、Mac OS X上で、iptables、firewalld、PF、ipfwの4つの異なるファイアウォールをサポートしています。また、カスタムスクリプトのサポートもあり、fwknopをipsetやnftablesなどの他のインフラストラクチャに対応させることができます。

SPAは本質的に次世代のポートノッキング（PK）ですが、PKにあった多くの制限を解決しつつ、その中核的な利点を維持しています。PKの制限には、リプレイ攻撃に対する防御が一般的に困難であること、非対称暗号やHMACスキームを確実にサポートすることが通常は不可能であること、PKシーケンス中にネットワーク上を通過する際に追加のパケットを偽装するだけでPKサーバーに対してDoS攻撃を簡単に仕掛けられること（これにより、クライアントが正しいシーケンスを知らないとPKサーバーに信じ込ませる）などがあります。これらの欠点はすべてSPAによって解決されます。同時に、SPAはデフォルトドロップのファイアウォールポリシーの背後にサービスを隠蔽し、SPAデータを受動的に取得し（通常はlibpcapなどを介して）、SPAパケットの認証と暗号化/復号に標準的な暗号操作を実装しています。

fwknopによって生成されるSPAパケットは、暗号化してから認証するモデルでHMACを利用した認証付き暗号化を採用しています。現在、HMACの使用はオプションですが（--use-hmacコマンドラインスイッチで有効化）、以下の3つの理由から強く推奨されます。

HMACがない場合、GnuPGを使用しない限り、fwknopでは暗号論的に強力な認証は不可能ですが、それでもHMACを適用すべきです。
暗号化後に適用されるHMACは、Vaudenay攻撃や関連するトリック（SSLに対する最近の「Lucky 13」攻撃など）のようなCBCモードのパディングオラクル攻撃に対する暗号解析的な防御を提供します。
fwknopdデーモンがHMACを検証するために必要なコードは、SPAパケットを復号するためのコードよりもはるかに単純であるため、適切なHMACがないSPAパケットは復号ルーチンに送られることすらありません。

上記の最後の理由は、SPAパケットがGnuPGで暗号化されている場合でもHMACを使用すべき理由です。これは、HMACのチェックが先に行われない限り、SPAデータがlibgpgme関数を通じて送信されないためです。GnuPGとlibgpgmeは比較的複雑なコードであるため、HMAC操作によって潜在的な攻撃者がこのコードとやり取りする能力を制限することは、より強力なセキュリティ態勢を維持するのに役立ちます。SPA通信のためのHMACを生成するには、通常の暗号鍵に加えて専用の鍵が必要であり、両方とも--key-genオプションで生成できます。

fwknopは、SPAパケットをRijndaelブロック暗号またはGnuPGとそれに関連する非対称暗号のいずれかで暗号化します。対称暗号化方式を選択した場合、通常どおり暗号鍵はクライアントとサーバー間で共有されます（詳細は/etc/fwknop/access.confファイルを参照）。Rijndael暗号化に実際に使用される暗号鍵は、標準のPBKDF1鍵導出アルゴリズムを介して生成され、CBCモードが設定されます。GnuPG方式を選択した場合、暗号鍵はGnuPGキーリングから導出されます。

ユースケース

シングルパケット認証（SPA）またはそのセキュリティ的に劣る従兄弟であるポートノッキング（PK）を使用する人々は、通常、SPA/PKソフトウェアが展開されている同じシステム上で動作するSSHDにアクセスします。つまり、ホスト上で動作するファイアウォールが、すべての着信SSH接続に対してデフォルトドロップポリシーを適用してSSHDをスキャン不可にしている一方で、SPAデーモンがファイアウォールを再構成して、受動的に認証されたSPAクライアントに一時的にアクセスを許可します。

SPA-basic-access-SSHD "SSHDにアクセスするための基本的なSPAの使用方法"

fwknopは上記の機能をサポートするだけでなく、さらに進んでNAT（iptables/firewalldファイアウォール向け）を堅牢に活用します。結局のところ、重要なファイアウォールは通常、単独のホストに展開されるのではなく、ネットワーク間のゲートウェイです。NATは、そのようなファイアウォールで（少なくともIPv4通信では）一般的に使用され、RFC 1918アドレス空間上の内部ネットワークにインターネットアクセスを提供したり、外部ホストが内部システムでホストされているサービスにアクセスできるようにしたりします。

fwknopはNATと統合されているため、外部インターネット上のユーザーは、ファイアウォールを通して内部サービスにアクセスするためにSPAを活用できます。これは従来のネットワークでも多くの用途がありますが、Amazon AWSなどのクラウドコンピューティング環境でもfwknopをサポートします。

SPA-Amazon-AWS-cloud "Amazon AWSクラウド環境でのSPAの使用方法"

ユーザーインターフェース

公式のクロスプラットフォームfwknopクライアントユーザーインターフェース fwknop-gui (ダウンロード, github) はJonathan Bennettによって開発されています。NATリクエスト、HMACおよびRijndael鍵（GnuPGはまだサポートされていません）、fwknoprcスタンザの保存など、主要なクライアント側SPAモードのほとんどがサポートされています。現在、fwknop-guiはLinux、Mac OS X、Windowsで動作します。以下はOS Xのスクリーンショットです。 fwknop-gui-OS-X-screenshot "Mac OS X上のfwknop-gui" 同様に、更新されたAndroidクライアントも利用可能です。

チュートリアル

fwknopに関する包括的なチュートリアルはこちらにあります。

http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html

機能

以下は、fwknopプロジェクトがサポートする全機能のリストです。

Linux上のiptablesおよびfirewalldファイアウォール、*BSDおよびMac OS X上のipfwファイアウォール、OpenBSD上のPFを中心としたシングルパケット認証を実装します。
fwknopクライアントはLinux、Mac OS X、*BSD、Cygwin上のWindowsで動作します。さらに、SPAパケットを生成するAndroidアプリもあります。
SPAパケットの暗号化/復号にRijndael方式とGnuPG方式の両方をサポートします。
RijndaelとGnuPGの両方でHMAC認証付き暗号化をサポートします。操作順序は暗号化してから認証であり、さまざまな暗号解析上の問題を回避します。
リプレイ攻撃は、有効な着信SPAパケットのSHA-256ダイジェスト比較によって検出され、阻止されます。他のダイジェストアルゴリズムもサポートされていますが、SHA-256がデフォルトです。
SPAパケットはlibpcapを介してワイヤから受動的に収集されます。fwknopdサーバーは、別のイーサネットスニファ（例：tcpdump -w <file>）によって書き込まれるファイル、iptables ULOG pcapライター、または--udp-serverモードでのUDPソケット経由で直接パケットデータを取得することもできます。
iptablesファイアウォールの場合、fwknopによって追加されたACCEPTルールは、カスタムiptablesチェーンに追加され、設定可能なタイムアウト後に削除されるため、fwknopはシステムに既にロードされている既存のiptablesポリシーに干渉しません。
認証されたSPA通信に対するインバウンドNAT接続をサポートします（現時点ではiptablesファイアウォールのみ）。つまり、fwknopを設定してDNATルールを作成し、オープンインターネットからRFC 1918 IPアドレス上の内部システムで動作するサービス（SSHなど）に到達できるようにします。SNATルールもサポートされており、これによりfwknopdを事実上、内部ネットワークからインターネットにアクセスするためのSPA認証ゲートウェイに変えます。
fwknopサーバーは複数のユーザーをサポートし、各ユーザーに独自の対称鍵または非対称暗号鍵を/etc/fwknop/access.confファイルを介して割り当てることができます。
外部IPアドレスの自動解決：https://www.cipherdyne.org/cgi-bin/myip を介して解決します（これはfwknopクライアントがNATデバイスの背後から実行される場合に便利です）。このモードでは外部IPアドレスが各SPAパケット内で暗号化されるため、インラインデバイスがSPAパケットを傍受し、アクセスを得るために異なるIPからのみ転送するMan-in-the-Middle（MITM）攻撃を阻止します。
SPAパケットの宛先ポート、およびiptables NAT機能を介したフォローオン接続のポートに対するポートランダム化をサポートします。後者は、内部サービスへの転送接続とfwknopdが動作するシステム上のローカルソケットへのアクセス許可に適用されます。
Torとの統合（このDefCon 14プレゼンテーションで説明されています）。TorはトランスポートにTCPを使用するため、Torネットワークを介してSPAパケットを送信するには、各SPAパケットを確立されたTCP接続上で送信する必要があるため、技術的には「シングルパケット認証」の「シングル」の側面が破られます。ただし、Torは一部の展開ではこの考慮事項を上回る匿名性の利点を提供します。
SPA通信のためのバージョン管理されたプロトコルを実装しているため、新しいSPAメッセージタイプを提供し、同時に古いfwknopクライアントとの後方互換性を維持するようにプロトコルを拡張するのが容易です。

ライセンス

fwknopプロジェクトはオープンソースソフトウェアとして、GNU General Public License (GPL v2) または（利用者の選択により）それ以降のバージョンの条件の下でリリースされています。最新リリースは以下にあります。 http://www.cipherdyne.org/fwknop/

現状

このREADMEファイルは、2013年7月に行われた2.5リリース時点のfwknopプロジェクトの現状を説明しています。現在、Firewall Knock Operatorライブラリ libfko、ならびにfwknopクライアントおよびサーバーアプリケーションの実装があります。このライブラリは、他のfwknopコンポーネントが使用するシングルパケット認証（SPA）データを管理するためのAPIとバックエンド機能を提供します。また、SPA機能を必要とする他のプログラムでも使用できます（例として、perlディレクトリのFKO perlモジュール、pythonディレクトリのpythonバインディングを参照）。

アップグレード

古いバージョンのfwknop（元のperl実装も含む）からアップグレードする場合は、以下のリンクを読んで、fwknop-2.5以降へのスムーズな移行を確認してください。

http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html#backwards-compatibility

その他

fwknopに関する質問やコメントは、fwknopメーリングリストで受け付けています。
静的解析のために、fwknopはCLANG静的アナライザーと強力なCoverity Scanツールを使用しています。

fwknopのビルド

この配布物はビルドのセットアップにGNU autoconfを使用しています。autoconfの基本的な使い方については、INSTALLファイルを参照してください。

fwknopに固有の「configure」オプションがいくつかあります。これらは（./configure --help から抜粿）:

  --disable-client        Do not build the fwknop client component. The
                          default is to build the client.
  --disable-server        Do not build the fwknop server component. The
                          default is to build the server.
  --with-gpgme            support for gpg encryption using libgpgme
                          [default=check]
  --with-gpgme-prefix=PFX prefix where GPGME is installed (optional)
  --with-gpg=/path/to/gpg Specify path to the gpg executable that gpgme will
                          use [default=check path]
  --with-firewalld=/path/to/firewalld
                          Specify path to the firewalld executable
                          [default=check path]
  --with-iptables=/path/to/iptables
                          Specify path to the iptables executable
                          [default=check path]
  --with-ipfw=/path/to/ipfw
                          Specify path to the ipfw executable [default=check
                          path]
  --with-pf=/path/to/pfctl
                          Specify path to the pf executable [default=check
                          path]
  --with-ipf=/path/to/ipf Specify path to the ipf executable [default=check
                          path]

例:

./configure --disable-client --with-firewalld=/bin/firewall-cmd
./configure --disable-client --with-iptables=/sbin/iptables --with-firewalld=no

注意事項

Perl版fwknopからの移行

現在Perl版を使用しており、このバージョンに移行する予定の方は、いくつか注意すべき点があります。

Perlベースのfwknopのすべての機能と機能性がこの実装に移植されたわけではありません。C版を可能な限り軽量かつシンプルに保つことが重要だと考えました。省略された機能/関数のほとんど（メールアラートなど）は、他の手段（例：外部スクリプトを使用してログファイルを監視し、適切なログメッセージに基づいてアラートを送信する）で実現できます。
fwknopの設定ファイルとアクセスファイルのディレクティブおよび値にはいくつかの違いがあります。その中にはかなり微妙なものもあります。これらのファイルのドキュメントとコメントに注意深く注意を払う必要があります。

fwknop開発者向け

この配布物をgitからプルする場合は、autogen.shスクリプトを実行してautoconfファイルを生成してください。不足しているディレクトリやファイルに関するエラーが発生した場合は、autogen.shをもう一度実行してみてください。その後、設定を再生成したいときにautoreconf -iを実行できます。何らかの理由でautoreconfが機能しない場合は、autogen.shスクリプトで十分です。

fwknopおよびfwknopdのmanページのnroffソースは、それぞれのディレクトリ（clientおよびserver）に含まれています。これらのnroffファイルは、docsディレクトリのasciidocソースから派生しています。詳細については、docsのREADMEを参照してください。

fwknop

人気