ネットワークの前提条件を再現可能にチェックする

このプロジェクトはAnsibleを使用して、ネットワークインフラストラクチャに関するセキュリティ前提条件を検証するBATSテストファイルを生成します。テストはプローブマシン（"プローバノード"）から実行され、Proberがデプロイされます。

このツールは、自社ネットワークの再現可能で自動化されたテストを目的としています。テストを実行する複数のプローバノードをサポートし、それぞれがプローブ対象ネットワークの異なるビューを持ちます。例えば、外部ゾーンからのビュー、内部ゾーンからのビュー、DMZ内部からのビューなどです。

許可されていないネットワークをProberでプローブすることは違法となる可能性があります。

要件

テストをプローバノードにデプロイするAnsibleマスター上:

• ansible（当たり前！）
• python*-netaddr（GNU/Linuxの場合）/ py*-netaddr（FreeBSDの場合）

プローバノード自体:

• bash
• ssh
• nmap
• dig/kdig
• testssl
• およびAnsibleロールによってインストールされるその他の依存関係

結果（*.tapファイル）をレビューするシステムでは、tappyをインストールするとよいでしょう。結果は各プローバノード上のローカルgitリポジトリに保存され（デフォルトでは/var/run/prober/results/、以下の設定オプションを参照）、各スキャン実行が完了した日付でタグ付けされたコミットが履歴と簡単な比較のために保持されます。

操作

Ansibleを使用してプローバノードにテストを生成します。プローバノードは、Proberの依存関係をインストールできる限り、FreeBSDまたはGNU/Linuxホストであれば何でも構いません。テスト専用である必要はありませんが、推奨されます。適度な規模のネットワークのスキャンには数時間かかり、多くのCPUを使用し、かなりのトラフィックを生成します。

複数の異なるマシンにProberをデプロイして、ネットワークがさまざまな視点（例：内部ネットワーク、DMZ、インターネット）からどのように見えるかを確認することは理にかなっています。

プローバノード上のテストディレクトリには、テストの実行を容易にするためにrun-tests.shスクリプトが作成されます。テストは、常に<simultaneous_tests_count>個のテストが同時に実行されるように実行されます。この変数は、プローブスキャンが使用するリソース量と必要な帯域幅を制御する主な方法です。

テスト結果はローカルgitリポジトリに保存され、各実行が完了した日付（一部の長いプローブ実行では開始日とは異なる場合があります）でタグ付けされたコミットが作成されます。

少数のホストを超えるインフラストラクチャを扱う場合は、Mitogenのようなツールを使用してテスト生成を大幅に高速化するとよいでしょう。

クイックスタート

1. DebianまたはFreeBSDサーバーをプローバノード（prober.example.com と呼びましょう）として準備し、SSHでアクセスでき、sudoが使用できることを確認します。

2. サンプルインベントリをinventories/test/としてコピーします。

3. そのtestインベントリで:

   1. group_vars/all.ymlを編集し、zone_nameserver、zone_domains、address_blocksをお好みに設定します。ここではプローブ対象の唯一のドメインとしてexample.comを追加したと仮定します。
   2. hostsファイルを編集し、[prober-nodes]セクションでprober.example.comプローバノードを設定します。tested_zoneを****に設定したとします。

これで、プローバノードにsshでログインし、/opt/prober/に生成されたテストを確認できます。満足したら、/opt/prober/run_tests.shを実行してテストを実行できます。結果は/var/run/prober/resultsに保存されます。

設定

設定変数（probers.ymlで定義）:

• tests_directory（デフォルト: /opt/prober）:
  プローバノード上でテストファイル（*.batsファイル）が生成されるディレクトリ。

• results_repo_directory（デフォルト: /var/run/prober/results） テスト結果（*.tapファイル）のリポジトリのディレクトリ。そこにgitリポジトリが初期化され、実際の結果用にtap/サブディレクトリが作成されます。結果はgitリポジトリにコミットされ、コミットはyyyy-mm-dd形式の日付でタグ付けされます（2020年3月19日に完了したテストの結果を含むコミットは、例えば2020-03-19とタグ付けされます）。

• simultaneous_tests_count（デフォルト: 20）:
  同時に実行されるテストの数。

• prober_dev（デフォルト: 未定義）: 開発マシンでは意味をなさない特定のタスク（やの設定など）をスキップします。

ゾーン

ゾーンは./data/<zone_name>.ymlファイルで定義され、最上位キーは文字列"tested_zone_settings"であり、その中には以下のキーが含まれます:

• name: ゾーンの名前。ファイル名（拡張子を除く）と一致します。例："internal"、"external"、"dmz"
• default（オプション）: このゾーン内のすべてのホストのデフォルト設定
• 複数のFQDNに一致する正規表現キー（必ず"^"文字で始まる）
• 明示的な設定が必要な各FQDNごとのキー

defaultキー、各正規表現キー、各ドメインキーには、以下のキーを含めることができます:

• resolve: ホストが該当するIPアドレスに解決されるべきかどうか（ブール値true/false、または文字列"skip"）
• ping: ホストがpingに応答するべきかどうか（ブール値true/false、または文字列"skip"）
• ports: オープンが許可されるTCPおよびUDPポートのリスト（サブキー"tcp"および"udp"。それぞれオープンが許可されるポートを定義する整数の配列、または文字列"skip"）、およびTLS対応ポート（詳細検査対象）のリスト（tlsサブキー。ポート番号をキーとし、TLSサービスの種類または文字列"skip"を値とする辞書）
  ports: "skip" は以下の省略形です: TLSサービスの種類は、がオプションでサポートするもの、""（HTTPSテスト（ヘッダーを含む））、または""（汎用TLSテスト）です。 : キーでポートがオープンとしてマークされていない限り、TLSテストは実行されません。

サンプル設定はこちらで確認できます。

グローバルデフォルトはprobers.ymlで定義されています。プローブ対象の各ホストについて、これらは該当するゾーンデフォルトとcombineされ、次に特定のホスト名に一致する正規表現キーと、最後に特定のホスト設定と結合されます。

つまり、特定のゾーン内の特定のホスト設定は、正規表現一致キーの設定よりも優先され、その正規表現一致キーの設定はゾーンデフォルトよりも優先され、ゾーンデフォルトはグローバルデフォルトよりも優先されます。

portsキーは特別に扱われます。設定継承チェーンのどこかで特定のポートがリストされている場合、チェーンの下位でそれらのポートをリストから削除することはできず、追加のポート番号を追加するか、特定のプロトコルのすべてのポートのテストを"skip"することのみ可能です。

ゾーンファイルは、各プローバノードに設定されたtested_zone変数に基づいて選択されます。

IP単位のテストとホスト名単位のテスト

一部のテストは、解決先のドメイン/ホスト名の数に関係なく、個々のIPアドレスのコンテキストで意味を持ちます。例えば、特定のポートがオープンかどうかの確認です。例として、a.example.comとb.example.comが同じIPアドレスを指しているとします。上記の設定例では、ポート8080/tcpと8443/tcpの両方がオープンであるべきであり、8443/tcpでHTTPSが期待されることを意味します。

一部のテストは、特定のドメイン/ホスト名とIPアドレスの組み合わせのコンテキストで意味を持ちます。例えば、特定のIPアドレス上の特定のドメイン名に対して提示されるTLS証明書が有効かどうかなどです。

これらの2種類のテストは、2つの別々のターゲットリストを生成することで実装されます:

• IP単位のリスト: 各要素は次の形式:
  <ip-address> <hostname1> (<hostname2> <hostname3> ... <hostnameN>)
  IPアドレスはこのリスト内で重複してはいけません。
• ホスト名単位のリスト: 各要素は次の形式:
  <ip-address> <hostname>
  IPアドレスはこのリスト内で繰り返し出現する可能性があります。

一部のテストファイルは最初のリストのターゲットに対してのみ生成され（例：オープンポートのテスト）、一部は2番目のリストのターゲットに対してのみ生成されます（例：TLS関連のテスト）。

ポートとテスト

特定のポートがオープンでない場合、一部のテストは意味をなしません。TLS関連のテストは、該当するゾーンで関連するTCPポートがopenとして設定されている場合にのみ、特定のホストに対して生成されます。

デフォルトでは、よく知られたTLS対応ポートのいずれかがports.tcpキーでオープンとして設定されている場合、それらのポートに対してTLSテストが生成されます。よく知られたTLS対応ポートのリストは、default_host_settings変数で定義されています。

FAQ

一般的に、Proberと他の類似ツールやサービスの違いは、通常、以下の組み合わせに要約されます:

• セルフホスト型であり、Proberノードをインフラストラクチャの内外の任意の場所にデプロイできること。
• 明確に定義され設定可能な前提条件を検証する、定期的で再現可能なスキャンに焦点を当てていること。
• テスト実行のスケジュールを制御でき、生のスキャン結果にアクセスできること。

Shodanとの違いは？

Shodanは露出したシステムを見つけるためにインターネットをクロールします。Proberは、必要な数の視点から、自社インフラストラクチャに関する前提条件を検証するために自社インフラをクロールします。明確に定義されたテストと定期的なスケジュール実行による結果の再現性に焦点を当て、テストされた各前提条件に対して真偽値の「合格/不合格」結果を提供しようとします（完全なスキャン結果データは調査のために利用可能です）。

BitSightとの違いは？

BitSightは、スキャンが正確にいつ行われるかについての制御や情報を提供せず、生のスキャンデータも提供しないまま、彼らのインフラストラクチャに関する妥当な前提条件のアイデアを検証します。Proberは、あなたのインフラストラクチャに関するあなたの前提条件を検証し、あなたのスケジュールで実行し、完全な生のスキャンデータを調査のために提供します。

Natlasとの違いは？

NatlasはShodan（露出したホストを見つけるためのクロール、クエリに応じて結果を表示）に近いように見えますが、セルフホストする機能があります（したがって、Proberノードのように、インフラストラクチャの内外の異なる場所でNatlasエージェントを実行することもできます）。Proberは、設定で表現された、あなたのインフラストラクチャに関するあなた自身の前提条件を検証するために、定期的なスキャンを実行します。

大きな課題

• より強力なテストシステムへの移行？
  • BATSには煩わしい制限がある。例えば、条件付きテスト（「テストAが失敗した場合、テストBをスキップする」など）を行う方法がない。
  • テストシステムを完全に廃止する？
    • https://docs.ansible.com/ansible/latest/reference_appendices/test_strategies.html
    • https://github.com/benwebber/ansible-tap
• IPv6フルブロックスキャンは千年以内に完了することは不可能
  • スキャンするIPを選択するヒューリスティック（ランダム、設定された「ステップ」で下から開始、など）を設定する方法を提供する？

謝辞

ロゴは、The Noun Project経由の虫眼鏡（verry obito, ID 作; CC-By）とネットワーク（Creative Stall, PK 作; CC-By）に基づいています。