サーバの脆弱性を管理する際、スキャン対象サーバごとにVulsスキャナをインストールしてスキャンを行う「ローカルスキャン」と、踏み台サーバを経由してスキャンを実施する「リモートスキャン」の2つの方法があります。
それぞれのスキャン方式には、以下のような特徴があります。
| スキャン方式 | Vulsスキャナのインストール場所 | スキャン対象の範囲 | 特徴・メリット |
|---|---|---|---|
| ローカルスキャン | スキャン対象サーバ | インストールしたサーバのみ | セットアップが用意 |
| リモートスキャン | 踏み台サーバ | 複数のスキャン対象サーバ | スキャン対象サーバはエージェントレス |
リモートスキャンは、踏み台となるサーバに一度Vulsスキャナをセットアップすれば、そこからSSH接続を経由して複数のサーバをスキャンできる点が大きなメリットです。個々のサーバにスキャナをインストール・設定する手間が省けます。
さらに、スキャン対象サーバを任意のグループ（例えば、開発環境と本番環境などシステム単位）に分け、1回のスキャン実行でそれぞれの結果を指定したグループへ分けてアップロードすることが可能です。その利点として、グループごとに担当者を割り当て、メンバーのスキャン結果に対するアクセス権や編集権限などを細かく管理するといった、運用が可能になります。
本記事では、この「リモートスキャンを用いて、各サーバのスキャン結果を別々のグループに向けてアップロードする」ことに焦点を当て、具体的な手順をハンズオン形式で解説します。
以下の構成図に基づき、複数のEC2インスタンスに対するリモートスキャンを実施し、その結果をシステム単位でFutureVulsにアップロードする手順を解説します。
上記の構成図では、システムAに2台、システムBに1台のEC2が存在するものとします。踏み台となるEC2を経由して、それぞれのスキャン対象EC2にSSH接続を行い、脆弱性スキャンを実行します。これにより、システムAとシステムBそれぞれのスキャン結果を、FutureVuls上で別々のグループとして管理することが可能になります。
本ハンズオンは、以下の手順に従ってリモートスキャンの設定を行い、スキャン結果をシステムごとにFutureVulsへアップロードすることを目的としています。
手順
注記: すでにEC2環境が構築済みである場合は、「FutureVulsでのグループ作成」から開始してください。
各EC2の設定値は以下の通りです。
| 項目 | 設定値 |
|---|---|
| 台数 | 1台 |
| OS | AL2023 |
| キーペア | 有り（キーペア名: test） |
| IPv4アドレス（Private） | 10.100.4.52 |
| セキュリティグループ | インバウンド：なし アウトバウンド: 0.0.0.0/0 |
| IAMインスタンスプロフィール | 「AmazonSSMManagedInstanceCore」ポリシーが付与されたIAMロール |
| 項目 | システムA（グループA） | システムB（グループB） |
|---|---|---|
| 台数 | 2台 | 1台 |
| OS | RedHat, Ubuntu | AL2023 |
| キーペア | 有り（キーペア名: test） | 同左 |
| IPv4アドレス（Private） | RedHat: 10.100.4.145 Ubuntu: 10.100.4.117 |
10.100.4.68 |
| セキュリティグループ | プロトコル: TCP ポート:22 インバウンド: 10.100.4.52/32 アウトバウンド: 0.0.0.0/0 |
同左 |
| IAMインスタンスプロフィール | なし | なし |
キーペアは、踏み台EC2からスキャン対象のEC2にSSH接続するために必要な認証情報です。OpenSSH形式で使用できるpem形式のキーペアを選択し、EC2作成後にダウンロードしてください。
筆者環境では、Windows Subsystem for Linux (WSL) 上のLinux環境で作業を行っており、ダウンロードしたキーペア(test.pem)は、Windows側のダウンロードフォルダ（/mnt/c/Users/future/Downloads/）に保存しました。WSL環境からWindowsのファイルシステムにアクセスする場合、/mnt/c/のようにパスがマウントされます。
EC2でキーペアを作成する手順の詳細については「AWS公式ドキュメント」をご参照ください。
筆者環境では、SSHのポートを開放せずに踏み台EC2に接続するために、Session Managerを使用しています。
踏み台EC2の設定は以下の通りです。
AmazonSSMManagedInstanceCoreポリシーが付与されたIAMロールを作成し、踏み台EC2にアタッチします。(参考)FutureVulsでは、踏み台EC2を経由してスキャン対象のEC2にスキャン実行する際にSSH接続を行うため、事前に設定が必要です。
踏み台EC2を作成後、ダウンロードしたpemファイル（test.pem）はローカルPCに保存されていると思います。筆者の環境では、以下のダウンロードフォルダ（/mnt/c/Users/future/Downloads/）に保存されています。
踏み台EC2からスキャン対象のEC2にSSH接続する際に、pemファイルが必要となるため、以下の手順でpemファイルの権限を変更し、踏み台EC2に転送します。
踏み台EC2に接続し、管理者権限でpemファイルを/home/vuls-saas/.sshに移動し、権限をvuls-saasに設定します。
これで、pemファイルの権限が適切に設定され、スキャン対象サーバに接続できる準備が整いました。
known_hosts に登録最後に、踏み台EC2からスキャン対象のEC2に手動でSSH接続を行うと、ホストフィンガープリントがknown_hostsに登録されます。
以下は、構成図のシステムBに含まれているAL2023のEC2に対してSSH接続を行うコマンドです。
EC2のデフォルトのユーザー名については「AWS公式ドキュメント」をご参照ください。
SSH接続後、known_hostsに登録されているか確認し、登録がない場合は以下のコマンドで追加します。
スキャン結果をFutureVuls画面でグループごとに管理するために、オーガニゼーション設定 > グループから「グループ作成」ボタンをクリックし、グループを作成できます。
今回は「グループA」「グループB」の2つのグループを作成します。
グループ設定 > スキャナ から、Vulsスキャナのインストールコマンドを取得し、踏み台EC2で管理者権限で実行します。
詳細はマニュアルの「Linuxスキャナのインストール」をご参照ください。
config.tomlの設定Vulsスキャナは、設定ファイルであるconfig.tomlに記述されたサーバをスキャンの対象とします。
スキャン結果のアップロード先を認証する際には、グループIDとトークンが用いられます。そのため、複数のサーバのスキャン結果をグループごとに分けてアップロードしたい場合は、それぞれのグループに対応したグループIDとトークンが設定されたconfig.tomlが必要になります。
グループIDとトークンはグループ設定 > スキャナから確認できます。
詳細はマニュアルの「config.tomlの分割」をご参照ください。
config.group-a.tomlを作成し、システムAに属するEC2の詳細情報を追記します。
config.group-b.tomlを作成し、システムBに属するEC2の詳細情報を追記します。
cron.dの設定指定した時間に自動でスキャンするために、cron.dに以下の設定を追加します。
設定内容:
上記の設定により、毎日日本時間の11:20と11:30に、それぞれ指定されたconfigファイルに定義されたサーバ群に対して自動スキャンが実行されます。
踏み台EC2への負荷は、これらのスキャンが近い時刻に実行されることに加え、各configファイル内に定義されているスキャン対象サーバの台数にも影響されます。特に、多数のサーバを対象とするスキャンが同時に実行された場合、負荷が高まる可能性があります。
運用中の負荷状況や各configファイルで定義されているサーバ台数を考慮し、必要に応じてスキャンの実行時刻を調整することを検討してください。
-configオプションを指定すると、その指定ファイルを参照し、オプションが指定されない場合、同じディレクトリ内にあるconfig.tomlを参照します。config.tomlは、Vulsスキャナをインストールした際に自動生成され、インストールしたサーバの詳細情報が記載されています。-configオプションが未指定の場合、今回ではVulsスキャナをインストールした踏み台サーバがスキャンされ、対象サーバがスキャンされません。
そのため、-configオプションで2つのconfigファイルを指定し、設定した時刻に自動スキャンされるように設定します。
また、-results-dir オプションを指定すると、それぞれのディレクトリにスキャン結果を分割することができ、他グループのサーバのスキャン結果の混在を防ぐことができます。
FutureVulsへのファイルアップロードが失敗した場合のみ、results配下にファイルが残り、ファイルアップロード成功した場合は、このファイルは自動削除されます。
vuls-saas.shの設定作成した2つのconfigファイルのスキャン結果をアップロードするために、vuls-saas.shを修正します。
./vuls saas > report.log 2>&1に、"$@"を追加しました。"$@"は、シェルスクリプト内で引数として渡された全ての値を展開する変数で、スクリプトに渡された複数の引数をそのままコマンドに渡すことができます。
今回の場合、vuls-saas.shに-configや-results-dirオプションを渡して実行すると、以下のように"$@"がそれらを展開してアップロードされます。
cron.dで設定された時刻になると、自動でスキャンが実行されますが、手動でスキャンを実行することも可能です。
スキャンの動作仕様として、-config オプションで指定したconfigファイルをスキャンするため、2つのconfigファイルがある場合、2回スキャンを実行する必要があります。
スキャン実行後、以下のログファイルを確認することで、スキャンの成否やエラーの詳細を把握できます。
/opt/vuls-saas/vuls-saas.log： scan.log と report.log の概要/opt/vuls-saas/scan.log： スキャンの成否/opt/vuls-saas/report.log： レポートの詳細や FutureVuls へのアップロードエラーなどファイルのログ出力についてはマニュアルの「Linuxファイル・ログ出力」をご参照ください。
注意点として、スキャンを実行した場合、上記の3つのファイルが「後に実行されたスキャン結果で上書き」されます。そのため、スキャン結果を別々に保持したい場合は、スキャンを実行する前にこれらのファイルを別の場所にバックアップしておくことをお勧めします。
スキャンが成功すると、グループA・Bそれぞれのconfig.toml が更新され、FutureVuls の「サーバ」にスキャン結果が登録されます。
FutureVulsのサーバ > サーバ詳細タブから、サーバが適切に登録されているかを確認し、これらのサーバがスキャン対象のEC2と一致しているか、双方のUUIDとグループIDを照合します。UUIDはFutureVulsでサーバを識別するためのIDです。
サーバ詳細タブのサーバ情報からグループIDとUUIDが確認できます。
まずは、グループAを確認します。
これらが、config.group-a.tomlに記載されてあるグループIDとUUIDと一致しているかを確認します。
スキャン成功時、各リモートサーバにUUIDが追加されます。
同様にグループBについても確認し、登録されたサーバがスキャン対象のEC2と一致しているか照合します。
設定ファイルの内容と一致しているかを確認します。
それぞれグループIDとUUIDが一致していたので、FutureVulsに正しくサーバが登録されていることが確認できました。
脆弱性×タスクタブを開くと、取得したソフトウェアに対する脆弱性が表示されます。
このように設定することで、リモートスキャンでスキャン結果を別々のグループにアップロードし、脆弱性が管理できます。
本記事では、FutureVulsのリモートスキャンを活用し、スキャン結果をシステム単位で管理する方法について解説しました。
システムごとにスキャン結果を分けて管理することで、それぞれの環境に応じた適切な対応が可能になり、セキュリティ管理の精度と効率が向上します。特に、スキャン対象サーバが多い場合や、異なるシステムの管理を求められる環境では、このアプローチが有効です。
詳細な説明やデモのご要望は「こちら」からお気軽にお問い合わせください。