Linux のローカルスキャン#

ここでは FutureVuls の Linux OS のスキャンの仕組みや設定方法などを解説します。

OSパッケージスキャンの仕組み#

Linux のパッケージはバックポートの仕組みでアップデートが提供されます。 FutureVuls では、Linux ディストリビューターが提供する Security Tracker や OVAL を用いて検知処理を実施します。これらの脆弱性 DB は、各 OS に対応する「実際にバックポートされたバージョン番号」が書かれているため、正確に検知できます。

各スキャン方法の詳細な検知ロジックは OSS のソースコードを参照してください。

また、「OS やパッケージの CPE を登録して正確に脆弱性を検知できますか」という質問を受ける場合があります。こちらについては、誤検知が多発するためOSパッケージはCPEスキャンでは非推奨 です。詳細は OSパッケージのCPE登録を参照してください。

Linux でのスキャン方法・スキャン結果確認方法#

スキャナは1日1回自動でスキャンを実行します。任意のタイミングでスキャナを実行したい場合は、以下の「スキャン方法」に従ってください。

スキャン方法#

vuls-saas ユーザ権限で /opt/vuls-saas/vuls-saas.sh を次のように実行してください。

sudo で vuls-saas ユーザとして実行する場合

root@scan01:~# sudo -H -u vuls-saas /opt/vuls-saas/vuls-saas.sh >/dev/null 2>&1

vuls-saas ユーザにスイッチして実行する場合

root@scan01:~# su - vuls-saas
vuls-saas@scan01:~$ /opt/vuls-saas/vuls-saas.sh

スキャン結果の確認方法#

スキャン終了後、しばらくすると WEB 画面に反映されます。数分待ってもスキャン結果が反映されない場合や、スキャンに失敗した場合は、以下のログファイルを見て原因を確認して下さい。

/opt/vuls-saas/scan.log
- スキャンの成否が記載されています。
- スキャンが失敗している場合、レポート情報は FutureVuls にアップロードされません。
/opt/vuls-saas/report.log
- scan 結果のレポートと、FutureVuls へのアップロードエラーなどが記載されます。
- アップロードに失敗している場合、proxy 等が原因の場合があります。

スキャン設定の記載箇所#

スキャン時の設定は、以下のように /opt/vuls-saas/config.toml に記載されます。

$ cat /opt/vuls-saas/config.toml

version = "v2"

[saas]
  GroupID = 0000
  Token = "xxxx-xxxxxxxx-xxxx-xxxxxx-xxxxxxxxx"
  URL = "https://xxxxxxxxxxxx"

[default]

[servers]

  [servers.server1]
    user = "vuls-saas"
    host = "localhost"
    port = "22"
    scanMode = ["fast-root"]
    [servers.server1.uuids]
      server1 = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx"

OSパッケージのCPE登録#

OS 自体や、OS からインストールしたパッケージのCPE登録は可能です。

ただし、以下の理由による誤検知が想定されるため、利用は推奨しておりません。

CPE スキャンは実機にアクセスしないのでバージョンアップに気づかず誤検知が発生する
CPE スキャンで利用する NVD はバックポートに対応していないので誤検知が発生する

各ケースについて、詳細を解説します。

CPEスキャンは実機にアクセスしないのでバージョンアップに気づかず誤検知が発生する#

OS の CPE を登録すると、NVD に登録済みのその OS とバージョンに紐付けられたすべての脆弱性が検知されます。OS のパッケージは日々の運用で継続的にアップデートされますが、CPE スキャンは実機にはアクセスしないので、あるソフトウェアがアップデートされたことを知りません。このため、ソフトウェアアップデートにより解消済みの脆弱性は Fvuls 上で検知され続けます。

具体的に説明します（バージョンは適当です）

RHEL7リリース時に Apache 2.0.0-a が同梱された
その後、Apache 2.0.0-a に CVE-2021-0001が公開され、NVD に登録された
この時点で RHEL7を CPE スキャンすると CVE-2021-0001が検知された
Apache を 2.0.0-b にアップデートする
実機アクセスしない CPE スキャンは 2.0.0-b へのアップデートに気づかないので CVE-2021-0001 が検知され続ける

上記のような過検知が発生するため、OS の CPE スキャンは実質使い物になりません。

CPEスキャンで利用するNVDはバックポートに対応していないので誤検知が発生する#

また「パッケージマネージャ管理のソフトウェア」の CPE スキャンは誤検知が発生します。 RHEL, Ubuntu, Debian など主要な Linux ディストリビューションはバックポートの仕組みでアップデートが提供されます（参考：RHELのバックポーティング）

パッケージマネージャ管理化のソフトウェアの脆弱性検知には、バックポートに対応した脆弱性 DB を使用しなければなりません。

CPE スキャンで利用する脆弱性 DB は NVD です。NVD には、ある CVE に影響するソフトウェアのバージョンとしてアップストリームのバージョンが記載されています。 (NVD はバックポートのバージョンが書かれていない点に注意)

このため rpm -qa などで取得した全パッケージのバージョンを CPE に変換して CPE スキャンしても誤検知が発生します。

RHEL での CVE-2021-3450の例で具体的に解説します。

上記のページには以下のように書かれています。

NVD では、CVE-2021-3450 はアップストリームのバージョンである 1.1.1h - 1.1.1k が影響を受ける
RHEL では、CVE-2021-3450 は RHEL のバックポートにて openssl-1.1.1g-15 で修正された

つまり、同じ CVE-ID でも情報ソースごとに異なる修正バージョンとして登録されています。 RHEL のパッケージマネージャ配下の場合は、 RHEL のバージョン情報が正しいです。 NVD のバージョンを用いて判定すると誤検知します。

このように、すべてのパッケージを個別で CPE 登録、CPE スキャンしても技術的に誤検知が発生してしまいます。 OS とパッケージマネージャ管理下のソフトウェアは CPE スキャンではなく、スキャナ経由（OVAL を用いたスキャン）での検知が正確です。

なお「自分で tar.gz をダウンロードしビルドしたソフトウェア」の場合は、アップストリームから取得したソースコードですので、CPE スキャンで正確な検知が可能です。