FutureVuls Blog

リモートスキャン活用術:複数サーバのスキャン結果をグループごとに分けて管理する方法

はじめに

サーバの脆弱性を管理する際、スキャン対象サーバごとにVulsスキャナをインストールしてスキャンを行う「ローカルスキャン」と、踏み台サーバを経由してスキャンを実施する「リモートスキャン」の2つの方法があります。
それぞれのスキャン方式には、以下のような特徴があります。

スキャン方式 Vulsスキャナのインストール場所 スキャン対象の範囲 特徴・メリット
ローカルスキャン スキャン対象サーバ インストールしたサーバのみ セットアップが用意
リモートスキャン 踏み台サーバ 複数のスキャン対象サーバ スキャン対象サーバはエージェントレス

リモートスキャンは、踏み台となるサーバに一度Vulsスキャナをセットアップすれば、そこからSSH接続を経由して複数のサーバをスキャンできる点が大きなメリットです。個々のサーバにスキャナをインストール・設定する手間が省けます。
さらに、スキャン対象サーバを任意のグループ(例えば、開発環境と本番環境などシステム単位)に分け、1回のスキャン実行でそれぞれの結果を指定したグループへ分けてアップロードすることが可能です。その利点として、グループごとに担当者を割り当て、メンバーのスキャン結果に対するアクセス権や編集権限などを細かく管理するといった、運用が可能になります。

本記事では、この「リモートスキャンを用いて、各サーバのスキャン結果を別々のグループに向けてアップロードする」ことに焦点を当て、具体的な手順をハンズオン形式で解説します。

ハンズオン: リモートスキャンでスキャン結果を別々のグループにアップロードする

以下の構成図に基づき、複数のEC2インスタンスに対するリモートスキャンを実施し、その結果をシステム単位でFutureVulsにアップロードする手順を解説します。
リモートスキャン構成図

上記の構成図では、システムAに2台、システムBに1台のEC2が存在するものとします。踏み台となるEC2を経由して、それぞれのスキャン対象EC2にSSH接続を行い、脆弱性スキャンを実行します。これにより、システムAとシステムBそれぞれのスキャン結果を、FutureVuls上で別々のグループとして管理することが可能になります。

本ハンズオンは、以下の手順に従ってリモートスキャンの設定を行い、スキャン結果をシステムごとにFutureVulsへアップロードすることを目的としています。

手順

  1. EC2の設定
  2. SSH接続の設定
  3. FutureVulsでのグループ作成
  4. スキャナインストール
  5. config.tomlの設定
  6. cron.dの設定
  7. vuls-saas.shの設定
  8. スキャン実行

注記: すでにEC2環境が構築済みである場合は、「FutureVulsでのグループ作成」から開始してください。


EC2の設定

各EC2の設定値は以下の通りです。

  • 踏み台EC2
    項目 設定値
    台数 1台
    OS AL2023
    キーペア 有り(キーペア名: test)
    IPv4アドレス(Private) 10.100.4.52
    セキュリティグループ インバウンド:なし
    アウトバウンド: 0.0.0.0/0
    IAMインスタンスプロフィール 「AmazonSSMManagedInstanceCore」ポリシーが付与されたIAMロール
  • システムA(グループA)とシステムB(グループB)
    項目 システム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の設定は以下の通りです。

  • IAMロールの作成と付与
    AmazonSSMManagedInstanceCoreポリシーが付与されたIAMロールを作成し、踏み台EC2にアタッチします。(参考)
  • SSMエージェントの設定と登録
    対象のAWS環境に合わせてSSMエージェントをインストールします。今回使用するAL2023はプリインストールされているため、特に設定は不要です。(参考)

SSH接続の設定

FutureVulsでは、踏み台EC2を経由してスキャン対象のEC2にスキャン実行する際にSSH接続を行うため、事前に設定が必要です。

  1. pemファイルを踏み台EC2に転送

踏み台EC2を作成後、ダウンロードしたpemファイル(test.pem)はローカルPCに保存されていると思います。筆者の環境では、以下のダウンロードフォルダ(/mnt/c/Users/future/Downloads/)に保存されています。
踏み台EC2からスキャン対象のEC2にSSH接続する際に、pemファイルが必要となるため、以下の手順でpemファイルの権限を変更し、踏み台EC2に転送します。

1
2
3
4
5
6
7
8
# pemファイルを~/.ssh/に移動(Session ManagerでSSH接続するため)
$ sudo mv /mnt/c/Users/future/Downloads/test.pem ~/.ssh/

# pemファイルの権限を変更
$ sudo chmod 600 ~/.ssh/test.pem

# 踏み台EC2のtmpディレクトリに転送(xxxはインスタンスID)
$ scp -i ~/.ssh/test.pem ~/.ssh/test.pem ec2-user@xxx:/tmp/
  1. 転送したpemファイルの権限を変更

踏み台EC2に接続し、管理者権限でpemファイルを/home/vuls-saas/.sshに移動し、権限をvuls-saasに設定します。

1
2
3
4
5
6
7
8
9
10
11
# /home/vuls-saas/.ssh に移動
[root@ip-10-100-4-52 ~]# mv /tmp/test.pem /home/vuls-saas/.ssh

# test.pem の所有者とグループを変更
[root@ip-10-100-4-52 ~]# chown vuls-saas:vuls-saas /home/vuls-saas/.ssh/test.pem

# 権限が変更されたか確認
[root@ip-10-100-4-52 ~]# ls -ll /home/vuls-saas/.ssh
total 20
-rw-r--r--. 1 vuls-saas vuls-saas 6071 Mar 6 11:07 known_hosts
-rw-------. 1 vuls-saas vuls-saas 1678 Mar 6 07:24 test.pem

これで、pemファイルの権限が適切に設定され、スキャン対象サーバに接続できる準備が整いました。

  1. 手動でSSH接続し、known_hosts に登録

最後に、踏み台EC2からスキャン対象のEC2に手動でSSH接続を行うと、ホストフィンガープリントがknown_hostsに登録されます。
以下は、構成図のシステムBに含まれているAL2023のEC2に対してSSH接続を行うコマンドです。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[root@ip-10-100-4-52 ~]# ssh -i /home/vuls-saas/.ssh/test.pem ec2-user@10.100.4.68

A newer release of "Amazon Linux" is available.
Version 2023.6.20250303:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_
~\_ ####_ Amazon Linux 2023
~~ \_#####\
~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
Last login: Thu Mar 6 09:03:44 2025 from 10.100.4.52
[ec2-user@ip-10-100-4-68 ~]$

EC2のデフォルトのユーザー名については「AWS公式ドキュメント」をご参照ください。

SSH接続後、known_hostsに登録されているか確認し、登録がない場合は以下のコマンドで追加します。

1
[root@ip-10-100-4-52 ~]# ssh-keyscan -p 22 10.100.4.68 >> /home/vuls-saas/.ssh/known_hosts

FutureVulsでのグループ作成

スキャン結果をFutureVuls画面でグループごとに管理するために、オーガニゼーション設定 > グループから「グループ作成」ボタンをクリックし、グループを作成できます。
今回は「グループA」「グループB」の2つのグループを作成します。
グループ作成


スキャナインストール

グループ設定 > スキャナ から、Vulsスキャナのインストールコマンドを取得し、踏み台EC2で管理者権限で実行します。
スキャナインストール

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[root@ip-10-100-4-52 ~]# curl -s https://installer.vuls.biz/vuls-installer.sh | VULS_SAAS_GROUPID='15672' VULS_SAAS_TOKE
N='XXXXX' VULS_SCAN_MODE='fast-root' AUTO_REFRESH_BINARY=true bash -s inst
2025/03/06 09:04:10 [START ]: Install scanner.
2025/03/06 09:04:10 [SUCCESS ]: Check root user.
2025/03/06 09:04:10 [SUCCESS ]: Check distribution. [OS: amazon]
2025/03/06 09:04:10 [SUCCESS ]: Check Architecture [arch: x86_64]
2025/03/06 09:04:11 [SUCCESS ]: Install package. [yum-utils lsof cronie]
2025/03/06 09:04:11 [SUCCESS ]: Create group. [group: vuls-saas]
2025/03/06 09:04:12 [SUCCESS ]: Create user. [user: vuls-saas]
2025/03/06 09:04:12 [SUCCESS ]: Create directory. [/opt/vuls-saas]
2025/03/06 09:04:12 [SUCCESS ]: Create directory. [/var/log/vuls]
2025/03/06 09:04:14 [SUCCESS ]: Download binary. [/opt/vuls-saas/vuls type: linux_x86_64]
2025/03/06 09:04:14 [SUCCESS ]: Download script. [/opt/vuls-saas/vuls-saas.sh]
2025/03/06 09:04:14 [SUCCESS ]: Create config. [/opt/vuls-saas/config.toml]
2025/03/06 09:04:14 [SUCCESS ]: Create sudoers. [/etc/sudoers.d/vuls-saas]
2025/03/06 09:04:14 [SUCCESS ]: Create cron. [/etc/cron.d/vuls-saas-scan]
2025/03/06 09:04:14 [END ]: Install scanner finish.

詳細はマニュアルの「Linuxスキャナのインストール」をご参照ください。


config.tomlの設定

Vulsスキャナは、設定ファイルであるconfig.tomlに記述されたサーバをスキャンの対象とします。
スキャン結果のアップロード先を認証する際には、グループIDとトークンが用いられます。そのため、複数のサーバのスキャン結果をグループごとに分けてアップロードしたい場合は、それぞれのグループに対応したグループIDとトークンが設定されたconfig.tomlが必要になります。
グループIDとトークンはグループ設定 > スキャナから確認できます。
詳細はマニュアルの「config.tomlの分割」をご参照ください。

  • グループAの設定

config.group-a.tomlを作成し、システムAに属するEC2の詳細情報を追記します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
version = "v2"

[saas]
GroupID = 15672 # グループAのグループID
Token = "XXXXX" # グループAのスキャナトークン
URL = "https://auth.vuls.biz/one-time-auth"

[default]
port = "22" # リモートログイン先のポート番号
keyPath = "/home/vuls-saas/.ssh/test.pem" # pemファイルの配置場所
scanMode = ["fast-root"]

[servers]
[servers.ip-10-100-4-145_RedHat] # リモートサーバ名
user = "ec2-user" # リモートログインに使用するユーザ名
host = "10.100.4.145" # リモートログイン先サーバ:IPアドレスまたは名前解決できるサーバ名

[servers.ip-10-100-4-117_Ubuntu] # リモートサーバ名
user = "ubuntu" # リモートログインに使用するユーザ名
host = "10.100.4.117" # リモートログイン先サーバ:IPアドレスまたは名前解決できるサーバ名
  • グループBの設定

config.group-b.tomlを作成し、システムBに属するEC2の詳細情報を追記します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
version = "v2"

[saas]
GroupID = 17883 # グループBのグループID
Token = "YYYYY" # グループBのスキャナトークン
URL = "https://auth.vuls.biz/one-time-auth"

[default]
port = "22" # リモートログイン先のポート番号
keyPath = "/home/vuls-saas/.ssh/test.pem" # pemファイルの配置場所
scanMode = ["fast-root"]

[servers]
[servers.ip-10-100-4-68_AL2023] # リモートサーバ名
user = "ec2-user" # リモートログインに使用するユーザ名
host = "10.100.4.68" # リモートログイン先サーバ:IPアドレスまたは名前解決できるサーバ名

cron.dの設定

指定した時間に自動でスキャンするために、cron.dに以下の設定を追加します。

1
[root@ip-10-100-4-52 ~]# vim /etc/cron.d/vuls-saas-scan

設定内容:

1
2
20 11 * * * vuls-saas /opt/vuls-saas/vuls-saas.sh -config config.group-a.toml -results-dir /opt/vuls-saas/results/group-a >/dev/null 2>&1
30 11 * * * vuls-saas /opt/vuls-saas/vuls-saas.sh -config config.group-b.toml -results-dir /opt/vuls-saas/results/group-b >/dev/null 2>&1

上記の設定により、毎日日本時間の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を修正します。

1
2
3
4
5
6
7
8
9
10
# バックアップ作成
[root@ip-10-100-4-52 vuls-saas]# cp vuls-saas.sh vuls-saas.sh.bak
# vuls-saas.sh を編集
[root@ip-10-100-4-52 vuls-saas]# vim vuls-saas.sh
# 編集内容を確認
[root@ip-10-100-4-52 vuls-saas]# diff vuls-saas.sh*
65c65
< ./vuls saas "$@" > report.log 2>&1
---
> ./vuls saas > report.log 2>&1

./vuls saas > report.log 2>&1に、"$@"を追加しました。
"$@"は、シェルスクリプト内で引数として渡された全ての値を展開する変数で、スクリプトに渡された複数の引数をそのままコマンドに渡すことができます。
今回の場合、vuls-saas.sh-config-results-dirオプションを渡して実行すると、以下のように"$@"がそれらを展開してアップロードされます。

1
2
./vuls saas -config config.group-a.toml -results-dir /opt/vuls-saas/results/group-a > report.log 2>&1
./vuls saas -config config.group-b.toml -results-dir /opt/vuls-saas/results/group-b > report.log 2>&1

スキャン実行

cron.dで設定された時刻になると、自動でスキャンが実行されますが、手動でスキャンを実行することも可能です。
スキャンの動作仕様として、-config オプションで指定したconfigファイルをスキャンするため、2つのconfigファイルがある場合、2回スキャンを実行する必要があります。

1
2
[root@ip-10-100-4-52 ~]# /opt/vuls-saas/vuls-saas.sh -config config.group-a.toml -results-dir /opt/vuls-saas/results/group-a >/dev/null 2>&1
[root@ip-10-100-4-52 ~]# /opt/vuls-saas/vuls-saas.sh -config config.group-b.toml -results-dir /opt/vuls-saas/results/group-b >/dev/null 2>&1

スキャン実行後、以下のログファイルを確認することで、スキャンの成否やエラーの詳細を把握できます。

  • /opt/vuls-saas/vuls-saas.logscan.logreport.log の概要
  • /opt/vuls-saas/scan.log: スキャンの成否
  • /opt/vuls-saas/report.log: レポートの詳細や FutureVuls へのアップロードエラーなど

ファイルのログ出力についてはマニュアルの「Linuxファイル・ログ出力」をご参照ください。

注意点として、スキャンを実行した場合、上記の3つのファイルが「後に実行されたスキャン結果で上書き」されます。そのため、スキャン結果を別々に保持したい場合は、スキャンを実行する前にこれらのファイルを別の場所にバックアップしておくことをお勧めします。

スキャンが成功すると、グループA・Bそれぞれのconfig.toml が更新され、FutureVuls の「サーバ」にスキャン結果が登録されます。

  1. Futurevulsでのサーバ確認

FutureVulsのサーバ > サーバ詳細タブから、サーバが適切に登録されているかを確認し、これらのサーバがスキャン対象のEC2と一致しているか、双方のUUIDとグループIDを照合します。UUIDはFutureVulsでサーバを識別するためのIDです。

サーバ詳細タブのサーバ情報からグループIDとUUIDが確認できます。
まずは、グループAを確認します。

  • RedHatサーバ
    グループA(RedHat)
  • Ubuntuサーバ
    グループA(Ubuntu)

これらが、config.group-a.tomlに記載されてあるグループIDとUUIDと一致しているかを確認します。
スキャン成功時、各リモートサーバにUUIDが追加されます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
[root@ip-10-100-4-52 ~]# cat /opt/vuls-saas/config.group-a.toml

version = "v2"

[saas]
GroupID = 15672
Token = "XXXXX"
URL = "https://auth.vuls.biz/one-time-auth"

[default]
port = "22"
keyPath = "/home/vuls-saas/.ssh/test.pem"
scanMode = ["fast-root"]

[servers]

[servers.ip-10-100-4-145_RedHat]
user = "ec2-user"
host = "10.100.4.145"
[servers.ip-10-100-4-145_RedHat.uuids]
ip-10-100-4-145_RedHat = "1ad76f4f-0b98-4466-f057-68437fb4674c" # 追加されたUUID
[servers.ip-10-100-4-145_RedHat.windows]
serverSelection = 0

[servers.ip-10-100-4-117_Ubuntu]
user = "ubuntu"
host = "10.100.4.117"
[servers.ip-10-100-4-117_Ubuntu.uuids]
ip-10-100-4-117_Ubuntu = "8e1bba35-f735-e99e-54df-636729224a0a" # 追加されたUUID
[servers.ip-10-100-4-117_Ubuntu.windows]
serverSelection = 0

同様にグループBについても確認し、登録されたサーバがスキャン対象のEC2と一致しているか照合します。

グループB

設定ファイルの内容と一致しているかを確認します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
[root@ip-10-100-4-52 ~]# cat /opt/vuls-saas/config.group-b.toml

version = "v2"

[saas]
GroupID = 17883
Token = "YYYYY"
URL = "https://auth.vuls.biz/one-time-auth"

[default]
port = "22"
keyPath = "/home/vuls-saas/.ssh/test.pem"
scanMode = ["fast-root"]

[servers]

[servers.ip-10-100-4-68_AL2023]
user = "ec2-user"
host = "10.100.4.68"
[servers.ip-10-100-4-68_AL2023.uuids]
ip-10-100-4-68_AL2023 = "ad15c2a7-efeb-83f0-4f80-b0f738355573" # サーバUUID
[servers.ip-10-100-4-68_AL2023.windows]
serverSelection = 0

それぞれグループIDとUUIDが一致していたので、FutureVulsに正しくサーバが登録されていることが確認できました。

  1. 検知された脆弱性の確認

脆弱性×タスクタブを開くと、取得したソフトウェアに対する脆弱性が表示されます。

  • RedHatサーバ
    RedHatの脆弱性
  • Ubuntuサーバ
    Ubuntuの脆弱性
  • AL2023サーバ
    AL2023の脆弱性

このように設定することで、リモートスキャンでスキャン結果を別々のグループにアップロードし、脆弱性が管理できます。

おわりに

本記事では、FutureVulsのリモートスキャンを活用し、スキャン結果をシステム単位で管理する方法について解説しました。
システムごとにスキャン結果を分けて管理することで、それぞれの環境に応じた適切な対応が可能になり、セキュリティ管理の精度と効率が向上します。特に、スキャン対象サーバが多い場合や、異なるシステムの管理を求められる環境では、このアプローチが有効です。

詳細な説明やデモのご要望は「こちら」からお気軽にお問い合わせください。