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 スキャンで正確な検知が可能です。