スキャナ全般のFAQ

スキャン可能なOS

脆弱性スキャンが可能なOSはこちらです。

通信要件

FutureVulsサービスからスキャン対象環境への通信は発生しません。 認証やスキャン結果アップロード時にスキャン対象環境からFutureVulsへのoutgoingの通信が発生します。 スキャン対象環境にて「外向きの通信」が制限されている場合は「FAQ>通信要件」を参照し、該当するFQDNへのoutgoingを許可してください。

Amazon S3のエンドポイントからスキャナをインストールする場合

スキャナのインストールはAWS S3に配置されているバイナリをインストールします。AWS環境上のサーバにて、S3への通信が制限されている場合は、該当するエンドポイントのポリシーにおいて、““arn:aws:s3:::installer.vuls.biz/*“リリースへの"s3:GetObject"アクションを許可ください。

  • ポリシー例
{
    "Version": "2012-10-17",
    "Id": "XXXXXXXXXX",
    "Statement": [
        {
            "Sid": "XXXXXXXXXXXX",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::installer.vuls.biz/*"
        }
    ]
}

Amazon S3のエンドポイントからスキャン結果をアップロードしたい場合

該当するエンドポイントのポリシーにおいて、“arn:aws:s3:::vuls-results-tmp-prd/*“リリースへの"s3:PutObject"アクションを許可ください。

  • ポリシー例
{
    "Version": "2012-10-17",
    "Id": "XXXXXXXXXX",
    "Statement": [
        {
            "Sid": "XXXXXXXXXXXX",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::vuls-results-tmp-prd/*"
        }
    ]
}

スキャン結果が反映されない

のスキャン方法にて、次の場合は、スキャナが構成情報の同期処理に失敗している可能性があります。

  • 新しく登録したはずのサーバが画面に表示されない
  • 既に登録されているサーバの詳細ページで「Out of sync」の警告が表示される
    • 最後に同期された時刻(構成同期時刻)時点での構成情報を元に脆弱性を検知しているため、その後構成情報に変更があった場合は誤検知や検知漏れの恐れがあります

image

各ログファイルを確認し、対応してください。

スキャナの実行に失敗しているはずなのにスキャン履歴に成功履歴が表示される

定期スキャンにより、サーバ上のスキャナが正しく動作していない場合にも、グループ設定>スキャン履歴 に成功と表示される場合があります。

通常、FutureVulsのスキャン処理は大まかに次の2ステップに分けられます。

  1. サーバ上にインストールされたスキャナが構成情報をFutureVulsに同期する
  2. FutureVulsに登録されている構成情報と脆弱性DBの情報とを突合し、脆弱性の検知結果を更新する

スキャナによるスキャンは1日1回起動し、上記の1,2ステップにて処理が実行されます。 一方、定期スキャンでは1日数回上記のステップ2のみを実行します。 スキャン履歴の結果が定期スキャンによるものか否かは、「スキャナ名」列の値が「FutureVulsManual」であるか否かで判断可能です。

プロキシ環境内のサーバのスキャン

『インストール時』・『スキャン結果のアップロード時』に、スキャン実行サーバからインターネットへのアクセスが発生します。

プロキシ環境内のサーバをスキャンする際には プロキシ設定 のページを併せてご覧ください。

プロキシ環境下でログファイルにエラーが出てスキャン結果が反映されない

スキャン時に下記のエラーがでた場合は、環境変数から HTTPS_PROXY を削除して再度実行してください。

"Failed to report. err: Post https://auth.vuls.biz/one-time-auth: proxyconnect tcp: tls: first record does not look like a TLS handshake"

スキャンエラーメールが送信され続ける

件名: [FutureVuls] [ScanAuth]スキャンの認証でエラーが発生しました

解約、退会するためには下記ページの作業をすべて実行してください。

トライアル期間終了後に上記メールが送付され続ける場合は、 まだどこかのサーバにスキャナがインストールされたままであり、 FutureVulsにデータをアップロードし続けている状態です。

スキャン対象サーバ上にて特権ユーザでコマンドを実行ください。 スキャナの削除が完了するとメールは送付されなくなります。

スキャナの更新時にダウンタイムは発生しますか

いいえ。FutureVulsのスキャナはスケジュールされたタイミングでスキャンを実行します。 何らかのプロセスが常駐しているわけではなく、スキャナの更新がアプリケーションの通信を阻害することはありません。

スケーラブル環境のスキャンライセンスはどうなりますか

FutureVulsでは、UUIDを用いてサーバを一意に識別しています。 スケーラブル環境にて、同一構成が保証されているサーバの脆弱性管理をFutureVuls上で1つのサーバとしてまとめて問題ない場合は、代表サーバ一台にのみスキャナをインストールするか、環境内のすべてのサーバで同じUUIDを設定してください。

UUIDの設定ファイル

  • Linux: /opt/vuls-saas/config.toml
  • Windows: C:\Program Files\vuls-saas\config.toml

スケーラブル環境においても別のサーバとして識別したい場合は、それぞれのサーバでインストールコマンドを実行し、別のUUIDを割り当ててください。 (UUIDはスキャナをインストールしたあと、初回スキャン時に自動で生成されます)

AWS AMIを使った例

クラウドなどでスケーラブルな環境の脆弱性を管理する場合は、ライセンスの節約の観点から次の方法がおすすめです。

  1. AMIの元となる代表インスタンスにスキャナをインストールします。
  2. /opt/vuls-saas/config.tomlにUUIDを生成するために一度スキャンを実行します。(スケールアウトされたサーバをFutureVulsで個別に管理したい場合はスキップ)
  3. 代表インスタンスからAMIを作成します。
  4. スケールアウト時は3.で作成したAMIを使用してください。 各インスタンス間でUUIDは重複しますが、FutureVulsサービス側では1台のサーバとして扱います。AMIの脆弱性管理という観点からは問題ありません

FutureVulsに登録された構成情報が異なる複数のサーバのUUIDを間違えて重複してしまった場合の対応方法

複数のサーバが同じUUIDを共有してスキャン(FutureVulsへUpload)された場合、サーバのOS情報、パッケージ情報、脆弱性などの関連情報が混在して正確に管理できなくなります。 この場合、重複したUUIDを廃棄し、各サーバに新しいUUIDを割り当てる必要があります。

具体的な方法は以下のとおりです。

  1. FutureVulsの画面上で、重複したUUIDを持つサーバを削除する
  2. 各サーバのconfig.tomlファイルに、uuidgenコマンドなどを用いて新しいUUIDを定義する
  3. 各サーバを再度スキャンして、情報を更新する