NetCrunch Server のハードニング
サーバー自体の攻撃対象を小さくするように NetCrunch を展開する方法 — サーバーが行うべきことと行うべきでないこと、使用するアカウント、そして監視をサーバーではなくプローブに配置する理由について説明します。
!!! NetCrunchのセキュリティ機能では、NetCrunch が保持するデータを保護する方法について説明しています。ここでは、その周辺の展開方法、つまり、そもそも到達可能な範囲を減らすためにサーバーをどのように運用するかを説明します。
これらすべての背景にある考え方は同じです。監視サーバーは、環境内の多くの認証情報を保持し、他の何も到達できないマシンにも到達できる可能性があります。そのマシン上で実行されるものはすべて、その立場を引き継ぎます。
以下は強制事項ではなく、ガイダンスです。NetCrunch は現在、これらのいずれもブロックしません — サーバーのプローブから監視することも、サーバー上でスクリプトセンサーを実行することも妨げません。ここで示すのは、インストールを防御可能な状態にするための選択肢であり、それを適用するのはお客様です。
サーバーの役割を 1 つに限定する
サーバーでは NetCrunch だけを実行します。それ以外のサービスやアプリケーション、汎用的な用途には使用しません。
これはリソースの問題ではありません。監視サーバーは、すでにインフラストラクチャへの認証情報を持つマシンです。そこに追加されるプロセスはすべて、それらの認証情報への侵入経路を増やすことになります。
サーバーではなくプローブから監視する
別のマシンに Monitoring Probe をインストールし、そこから環境を監視することを推奨します。分散監視を参照してください。
サーバーのプローブでは、NetCrunch 自体だけを監視します。
この分離によって、上記のアドバイスを実行可能にできます。監視ではデバイスに接続し、デバイスが返す内容を解析し、構成によってはそのためにコードを実行します。これをプローブから実行すれば、認証情報データベースを保持するマシンから、その処理と、処理中に発生する可能性のある問題を切り離せます。
service-account
サービスアカウント
NetCrunch は Local Service として実行できません。これはハードニング上の方針ではなく、製品がそのようには動作しないためです。
理由は 2 つあり、どちらもそれだけで十分な理由になります。
- Local Service アカウントにはネットワーク ID がないため、他の Windows マシンに対して認証できません。Windows monitoring と Active Directory monitoring はどちらも動作しなくなります。
- NetCrunch は構成を
HKEY_LOCAL_MACHINEの下に保存しますが、このアカウントにはそこへの書き込み権限がありません。
Local Service を使用したい理由が、監視プロセスから到達できる範囲を制限することである場合、その目的を実現するためにサポートされている方法はプローブです。probe を、監視に実際に必要な権限を持つ別のマシン上で実行し、サーバーを監視処理から除外します。
サーバーアカウントに必要な権限を減らす作業は現在進行中であるため、今後のバージョンではこの状況が改善される見込みです。現在は、プローブを使用することで実現できます。
NetCrunch が実行されるアカウントは、data folder へのアクセス権も決定します。サービスが LocalSystem として実行されない場合、そのアカウントには SYSTEM およびローカルの Administrators グループとともに data tree へのアクセス権が付与されます。!!! NetCrunchのセキュリティ機能を参照してください。
startup-script
スタートアップスクリプト
NetCrunch はサーバーの起動中、監視が開始される前にスタートアップスクリプトを実行します。これは、ネットワークドライブのマッピングなど、監視が依存するものを準備する場合に便利です。
SettingsNetCrunch SystemServerStartup Script
スクリプトをコンソールから選択することはできません。サーバーマシン上に自分で配置する、単一の固定ファイルです。
StartupScript.cmd- NetCrunch の installation ディレクトリ内に配置します。data directory ではありません。ファイル名は完全一致であり、検索は行われません。スクリプトが実行された理由、または実行されなかった理由を確認するためのファイルは 1 つだけです。存在しない場合、スタートアップはそのまま続行されます。
これは意図された動作であり、理解しておくべきセキュリティ特性です。サーバー起動時に実行する内容を定義するには、現在では installation directory への書き込みアクセスが必要です。これは、そのマシンのローカル管理者権限をすでに意味します。リモートの呼び出し元が設定できるものではありません。
これはこのバージョンで変更されました。以前のリリースでは、スクリプトをリモートから選択できたため、管理クライアントがサーバーで実行する内容を選択できました。現在、ネットワーク経由で送信されるのは待機時間だけです。
待機時間
設定項目は、NetCrunch がスタートアップを続行する前にスクリプトを待機する時間だけです — 最大 300 秒で、デフォルトは 30 です。
0 に設定すると、スクリプトを開始した直後に待機せず、スタートアップを続行します。待機時間が経過した時点でスクリプトがまだ実行中の場合、NetCrunch はスタートアップを再開し、スクリプトは実行を継続します。
出力は StartupScript.log に書き込まれます — ただし、スクリプトの隣ではありません。ログは NetCrunch の data directory にある Logs フォルダーに書き込まれます。デフォルトのインストールでは、data directory は C:\ProgramData\AdRem\NetCrunch\ の下にあります。
スクリプトとそのログは 2 つの異なる場所にあります。スクリプトは installation directory に、ログは data directory に配置されます。この分離は、ここで説明する他のすべてと同じルールに従っています。installation directory は、書き込みに管理者権限が必要な特権ディレクトリであり、NetCrunch はそこにログを書き込みません。
code-execution
サーバー上で実行されるコード
一部の監視では、単に値を読み取るのではなく、コードを実行します。たとえば、スクリプトセンサーやプログラムを起動するアラートアクションなどです。サーバーのプローブ上では、このコードはサーバーの権限で NetCrunch server 上で実行されます。
ハードニングされたインストールでは、次のようにします。
- サーバーのプローブに対して script sensors を実行しない
- サーバー上でプログラムを実行するアクションを構成しない
これは機能上の制限ではありません。どちらも便利な機能であり、どちらも別のマシン上のプローブで使用すべきです。そうすれば、同じスクリプトで同じ処理を実行しながら、認証情報データベースの隣で実行することを避けられます。