脆弱性スキャナー「Vuls」による脆弱性収集
■導入
■環境
Vulsサーバ | リモートスキャン対象のサーバ | |
OS | AlmaLinux 9.4 | AlmaLinux 9.2 |
IP | 10.14.210.20 | 10.14.210.33 |
■構築の流れ
- Vulsのインストール
- Vuls Repoのインストール
- リモートスキャンサーバの設定
- スキャンとレポートの作成
- cronの登録
■構築方法
Vulsのインストール
- ユーザの作成
sudo権限を付与するためにVuls用のユーザを「wheel」グループに所属させます。
# useradd vuls -G wheel
# passwd vuls
- 必要パッケージのインストール
Vulsをインストールする際にはGitのクローンなどを行うためそういった必要になるパッケージをインストールします。
# dnf install -y git dnf-utils
- Vulsインストーラのgitをクローン
Vulsのセットアップ簡略化のためにコミュニティによってVulsctlが作成されているのでこちらをクローンします。
# su - vuls
$ git clone https://github.com/vulsio/vulsctl.git
※RockyLinux、AlmaLinuxの場合は、install.shを編集する
$ vi vulsctl/install-host/install.sh
"rhel" | "centos")
↓
"rhel" | "centos" | "rocky" | "almalinux")
- インストール
Vulsインストール用のスクリプトファイルをカレントディレクトリにコピーしインストールを行います。
$ cp -p vulsctl/install-host/* .
$ sudo ./install.sh
- 脆弱性データベースのアップデート
Vulsのスキャン時に使用する脆弱性データべースを最新のものへとアップデートを行います。尚、デフォルトでは様々なOS向けの脆弱性情報が含まれていますが、スクリプトの該当行を削除するなどして不要な情報の削減が可能です。
$ ./update-all.sh
- ローカルサーバをスキャンする為の設定ファイルを作成
$ cat << EOF | tee config.toml
[servers]
[servers.localhost]
host = "localhost"
port = "local"
EOF
- コンフィグテスト
$ vuls configtest
- スキャン実行
$ vuls scan
- レポート作成
$ vuls report
- レポート確認
Vulsでは以下のコマンドによってターミナルベースでレポートの確認が可能です。
$ vuls tui
Vuls Repoのインストール
- Vuls Repoのgitをクローン
$ cd
$ sudo git clone https://github.com/ishiDACo/vulsrepo.git
- Vuls Repoの設定ファイル作成
$ cd vulsrepo/server
$ cat << EOF | sudo tee vulsrepo-config.toml
[Server]
rootPath = "/home/vuls/vulsrepo"
resultsPath = "/home/vuls/results"
serverPort = "5111"
EOF
- ユニットファイル作成
systemdで管理できるようにユニットファイルを作成します。
$ sudo cp -p /home/vuls/vulsrepo/server/scripts/vulsrepo.service /lib/systemd/system/vulsrepo.service
$ sudo vi /lib/systemd/system/vulsrepo.service
[Unit]
Description=vulsrepo daemon
Documentation=https://github.com/ishiDACo/vulsrepo
[Service]
ExecStart = /home/vuls/vulsrepo/server/vulsrepo-server
ExecRestart = /bin/kill -WINCH ${MAINPID} ; /home/vuls/vulsrepo/server/vulsrepo-server
ExecStop = /bin/kill -WINCH ${MAINPID}
Restart = no
Type = simple
User = vuls
Group = vuls
[Install]
WantedBy = multi-user.target
- 自動起動設定
$ sudo systemctl daemon-reload
$ sudo systemctl enable --now vulsrepo
$ sudo systemctl status vulsrepo
$ ss -nltup
- Firewall設定
Vuls Repoの設定ファイルで指定したポートの開放を行います。
$ sudo firewall-cmd --add-port=5111/tcp --permanent
$ sudo firewall-cmd --reload
- ブラウザアクセス確認
ブラウザにて以下のような画面が確認できればOKです。
![](https://www.conversion.co.jp/wp-content/uploads/2024/07/S001_001-1.png)
リモートスキャンサーバの設定
※以下リモートスキャン対象のサーバを対象サーバと呼称。
Vulsサーバ側作業
- SSHキーを作成(パスフレーズなし)
Vulsは対象サーバにSSH接続してスキャンを行うため、その時に使用する鍵を作成します。
$ ssh-keygen -t rsa
$ cat ~/.ssh/id_rsa.pub
※公開鍵の内容をコピーする。
対象サーバ側作業
- 必要パッケージインストール
# dnf install dnf-utils
- ユーザの作成
# useradd vuls
# passwd vuls
- 公開鍵登録
対象サーバに認証済みの鍵としてさきほどVulsサーバ側で作成した公開鍵を登録します。
# su - vuls
$ mkdir ~/.ssh
$ chmod 700 ~/.ssh
$ touch ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/authorized_keys
$ vi ~/.ssh/authorized_keys
※先ほどコピーした公開鍵を張り付け
Vulsサーバ側作業
- 対象サーバにSSHログインして、$HOME/.ssh/known_hostsに登録
$ ssh -i ~/.ssh/id_rsa vuls@10.14.210.14
- config.tomlへ対象サーバ情報を追記
$ vi config.toml
[servers.client_hostname]
host = "10.14.210.14"
port = "22"
user = "vuls"
keyPath = "/home/vuls/.ssh/id_rsa"
※[]内はFQDNではない。「.」を含むホスト名等を入れるとエラーになる。
- コンフィグテスト
$ vuls configtest client_hostname
※引数はconfig.tomlに記載した[servers.client_hostname]の"client_hostname"の部分
スキャンとレポートの作成
- スキャン実行
$ vuls scan
※引数にconfig.tomlに記載した[servers.client_hostname]の"client_hostname"の部分を引数として追加して対象を指定することが可能
- レポート作成
$ vuls report
- レポート確認
Vuls Repoでは作成したレポートを以下のようにブラウザベースで確認することができます。
![](https://www.conversion.co.jp/wp-content/uploads/2024/07/S001_002.png)
cron登録
脆弱性データベースのアップデートとスキャン、レポート作成をcronに登録し定期的に実行することで、最新の状況をVuls Repoにて確認できるようになります。
# crontab -e -u vuls
PATH=/home/vuls/.local/bin:/home/vuls/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
0 0 * * * cd /home/vuls/; ./update-all.sh && /usr/local/bin/vuls scan -quiet && /usr/local/bin/vuls report -quiet
■Vulsを利用した脆弱性情報収集についての検討事項
上記で環境の構築が完了しましたので、次は実際にVuls RepoをOSS-Newsに活かした利用が可能であるかといったことを調査しました。
しかし結論から言うと、Vuls Repoでは現在サーバにインストールされているプロダクトに対し、該当するバージョンで影響の可能性がある脆弱性のみ表示されるため、発表されている脆弱性情報をすべて収集するなどのOSS-Newsに活かした利用はできないということがわかりました。
実際に行った調査の内容は以下の通りです。
まず、DNSサーバとして攻撃対象となることも多く、脆弱性がクリティカルなものになりやすいといった点から、監視対象のサーバにISC BINDをインストールし、Vuls Repoにて確認できる脆弱性を調査しました。
- 調査対象サーバ毎のBINDインストール情報
調査対象サーバ① | 調査対象サーバ② | |
OS | AlmaLinux 9.2 | AlmaLinux 8.5 |
bindバージョン | bind-9.16.23-11.el9 | bind-9.11.26-6.el8 |
その結果、Vuls Repoではプルダウン選択によってサーバ毎に脆弱性情報の確認を行うことが可能なのですが、調査対象サーバ①を選択した時と調査対象サーバ②を選択した時では表示される脆弱性情報が異なることがわかりました。
それぞれのサーバで表示されなかった脆弱性は以下の通りです。
調査対象サーバ① | 調査対象サーバ② | |
共通脆弱性識別子 | CVE-2022-38178 CVE-2022-38177 CVE-2022-3094 など | CVE-2023-6516 CVE-2023-5679 CVE-2023-5517 など |
次に、これらがなぜ一方では表示されなくなったのかを調査したところ、どうやら影響のあるバージョンによって表示の有無が変化するということがわかりました。
例えば、調査対象サーバ①で表示されなかったCVE-2022-3094ですが、コミュニティで影響のあるバージョンは以下のように記載しています。[参考情報(1)]
- 9.16系: 9.16.0 から 9.16.36
- 9.18系: 9.18.0 から 9.18.10
- 9.19系: 9.19.0 から 9.19.8
- 9.11.37 より前のバージョンは未調査だが、9.11系の全バージョンが脆弱である可能性あり。さらに古いバージョンも脆弱である可能性あり。
そのため調査対象の両サーバとも該当のバージョンのように思えますが、Red Hat Customer Portalによると「bind-9.11.36-11.el8」にてこの脆弱性は修正されており、調査対象サーバ①では「bind-9.16.23-11.el9」とこれより新しいバージョンのパッケージを利用していたため表示されなかったものと思われます。[参考情報(2)]
これは、CVE-2023-6516などの調査対象サーバ②で表示されなかった脆弱性についても同様であることを確認しました。
よって上記のことから、発表されている脆弱性情報をすべて収集したいといった要件を満たすのは難しく、OSS-Newsでの脆弱性情報収集に活かすことはできないということがわかりました。
■まとめ
今回は残念な結果となりましたが、既存サーバに潜在する脆弱性情報を収集するという点において「Vuls」はとても便利なツールかと思われますので、現在のセキュリティリスクを確認する意味でも利用を検討してみてはいかがでしょうか。
[参考情報] (2024/07/18執筆時点)
(1) ISC - BIND 9 Security Advisories- CVE-2022-3094
(2) Red Hat Customer Portal - RHSA-2023:7177 - Security Advisory
お問い合わせ
弊社では様々なサービスを取り扱っております。
詳細はサービス一覧からご覧ください。
お気軽にお問い合わせください。応対時間 9:30-17:30 [ 土・日・祝日除く ]
お問い合わせ