背景
今年もvulsを使う時期が来まして、去年の自分のメモを見ながら作業していたのですが、、見覚えのないエラーが。
備忘録です。
先に結論
scanMode に "offline"をつけてなかったから。
...でも、offlineをつけてもダメなケースはある。
地味にいやらしいんですよ。。
背景と経緯
背景
１年位前に実施した際は、確かofflineをつけずに動作したと記憶しています。
で、今年もその設定流用してみたら、以下のような症状が、、
- インタネットにつなぎ、脆弱性情報をDL（fetch_all.sh）
- インタネット接続を切ってスキャン対象のNWに移動し、構成スキャン(scan.sh）を実行
- エラーがちょこちょこでる(後に気づく)
- 処理自体は進み、resultsは配下に通常通りjsonファイル軍ができる
- 脆弱性情報と構成情報の突合（report.sh）を実行したら、CVE情報が表示されず（古いOSのはずなんだけど、、）
- エラーも出てる。。
エラー内容
[Mar 11 22:25:21] INFO [remotehost] Using Port Scanner: Vuls built-in Scanner
[Mar 11 22:25:21] INFO [container@remotehost] Scanning OS pkg in fast mode
[Mar 11 22:25:31] ERROR [localhost] Error on container@remotehost, err: [Failed to SSH: execResult: servername: container@remotehost
cmd: /usr/bin/ssh -o StrictHostKeyChecking=yes -o LogLevel=quiet -o ConnectionAttempts=3 -o ConnectTimeout=10 -o ControlMaster=auto -o ControlPath=/root/.vuls/cm-8bb3614d-%C -o Controlpersist=10m -l user01 -p 22 -i /root/.ssh/id_rsa -o PasswordAuthentication=no 172.27.98.126
exitstatus: 2
stdout: fetch https://dl-cdn.alpinelinux.org/alpine/v3.20/main/aarch64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.20/community/aarch64/APKINDEX.tar.gz
v3.20.6-45-g5aeff84c0c8 [https://dl-cdn.alpinelinux.org/alpine/v3.20/main]
v3.20.6-45-g5aeff84c0c8 [https://dl-cdn.alpinelinux.org/alpine/v3.20/community]
0 unavailable, 2 stale; 24054 distinct packages available
stderr: stty: 'standard input': Inappropriate ioctl for device
WARNING: updating https://dl-cdn.alpinelinux.org/alpine/v3.20/main: temporary error (try again later)
WARNING: updating https://dl-cdn.alpinelinux.org/alpine/v3.20/community: temporary error (try again later)
err: %!s(<nil>):
github.com/future-architect/vuls/scanner.(*alpine).apkUpdate
github.com/future-architect/vuls/scanner/alpine.go:70]
...
Scan Summary
================
remotehost debian12.9 283 installed
container@remotehost Error Use configtest subcommand or scan with --debug to view the details
調査
エラーを見るに、report.shの途中に追加の情報をインタネットにとりにいっている様子。
インタネット接続は最初のfetch_all.shで済ませ切っている、、という認識だったので、あれ？と思いつつ調査。
とりあえず別途検証環境を作って、インタネット接続をon/offしながら動作を確認。
インタネットつないだ状態でreport.shを実行しても、症状は解消せず。
なんで？と思いつつscan.shから再実行していたところ、、上記のエラーはscan.sh時に生じていたエラーを引用表示しているだけ（インタネットへの接続はscan.shで実施している）と気が付いた、と。
全部が全部ＮＧというわけでもなく、ベースOSがalpine/centosのdockerはＮＧ、ベースＯＳがubuntuやdebianのコンテナや、普通にＳＳＨを受け付けるホスト側のdebianでは問題なし（特に追加でデータを持ってくることはしない）という感じでした。
もう１つ厄介なのは、report.shはエラーを起こす構成情報があると、途中まで完了していた突合処理も放り投げて異常終了してしまうこと。
scan.shはエラーを起こすホストがいても一通りのスキャンを完遂するのですが、report.shは途中でとまってしまうので、取り合えずエラー出さない分だけ先に結果を回収、、、ということができません。
該当のjsonをresultsディレクトリから手でどければいいんですけどね。
要注意。
対処
普通にvulsのサイトに書いてありますね。。
https://help.vuls.biz/setting/scanmode/
インタネットにつなぎに行っているのが、スキャンかけている側なのか、スキャン受けている側なのかは確認しきれてません。（今回試した構成がちょっと悪く、、）
サイトの説明を見るに、スキャンされる側がインタネット接続するっぽいですが。
延長戦 やっぱり駄目なケース
上記で落ち着いたのですが、、、まだエラーが出るケースが。
具体的にはかなり古いOSを使っているケース。
scan.shではちゃんとパッケージをとって終了するのですが、report.shのフェイズでghcr.io/vlsio/vuls-nightly-db:0にアクセスしてデータをとってこようとします。
こちらは、一回スキャンしちゃえばローカルにvuls.dbとしてデータを保存してくれるようです。
サイズは685MB。なかなか。。
あるいは、スキャンしなくても取得できるようです。
コンテナの場合は、、無理かな。。
goを個別で動かせるようにしてやらないといけなさそう。
とりあえずは
こんなところです。
脆弱性情報の発信の方法自体がどんどん変わるから、追従大変なんだろうなぁ、、と頭の下がる思いです。。