Vulsに触れてみた（Vuls meetup 祭りVol2に参加してみて）

#1.きっかけ
Vuls meetup祭りVol2(2017.3.24)に参加しセキュリティ界隈の猛者たちの熱い意見をお聞きすることができた。
CVSSコードの解釈/パッチ対応の考え方、AWSによるサーバーレス環境の設計や工夫点など大変参考になる情報がありました。

そもそも私自身Vulsを触ったことがないため、Vulsサーバを構築し自分が保有しているWebサーバー（さくらのクラウド）を診断してみようと考えた。
折角なので構築時の手順を備忘録に纏めました。ご参考に！

#2.Vulsとは
・VulsはVULnerability Scannerの略。
・Linux/FreeBSD向けの脆弱性スキャンツール。
・OSSで提供。
・スキャン対象サーバーから取得したソフト/パッケージ情報のと脆弱性IDを特定する。
・リモートサーバーにはエージェント不要。
・アウトプットもSlackやメールに連携可。
※詳細はThinkIT参照。日々のセキュリティにおける苦悩や知見をツールに組み込んでます。ThinkIT記事

#3.Vuls環境（さくらのクラウド）
・Vulsのサーバーを新規作成する。
・元々あるWebサーバをスキャン対象とする。
・スキャンは共有セグメント（グローバルIP越）で行う。

#4.構築方法

##4.1 vulsサーバ構築方法
　・さくらのクラウドへCentOS7.3サーバを準備する。（割愛）
　・サーバーへSSH接続できるようにする。（以下リンク）
　　さくらのサポート情報：セキュリティの設定を参照

　　※本家「さくらのサポート情報」セキュリティの設定を行います。
　　　CentOS7はFirewalldなので読み替えましょう。
　　※Vuls専用ユーザー「sakura」を作成してssh接続を許可します。
　　　SSHキーペアを作成し、公開鍵をauthorized_keysに追加する。

##4.2.前提パッケージ
　・SQLite3 or MySQL
　・git
　・gcc
　・go v1.7.1 or later
　　https://golang.org/doc/install
　・yum-plugin-changelog（リモートにも必須）

##4.3 環境構築
　・パッケージのインストール

[root@vuls sakura]# yum -y install sqlite git gcc make
[root@vuls sakura]# wget https://storage.googleapis.com/golang/go1.7.1.linux-amd64.tar.gz
[root@vuls sakura]#tar -C /usr/local -xzf go1.7.1.linux-amd64.tar.gz
[root@vuls sakura]#mkdir $HOME/go

　・go環境

/etc/profile.d/goenv.sh を作成し以下を追記。
export GOROOT=/usr/local/go
export GOPATH=$HOME/go
export PATH=$PATH:$GOROOT/bin:$GOPATH/bin

　・環境変数をセット

[root@vuls sakura]#source /etc/profile.d/goenv.sh

##4.4 go-cve-dictionary展開
[root@vuls sakura]# mkdir /var/log/vuls
[root@vuls sakura]# chown sakura-user /var/log/vuls
[root@vuls sakura]# chmod 700 /var/log/vuls
[root@vuls sakura]# mkdir -p $GOPATH/src/github.com/kotakanbe
[root@vuls sakura]# cd $GOPATH/src/github.com/kotakanbe
[root@vuls sakura]# git clone https://github.com/kotakanbe/go-cve-dictionary.git
[root@vuls sakura]# cd go-cve-dictionary
[root@vuls sakura]# make install

・NVDから脆弱性データベースを取得。10分程度

[root@vuls sakura]#for i in {2002..2016}; do go-cve-dictionary fetchnvd -years $i; done

・JVNから脆弱性データベースを取得。（日本語)3分程度

[root@vuls sakura]#for i in `seq 1998 $(date +"%Y")`; do go-cve-dictionary fetchjvn -years $i; done

　※ファイルcve.sqlite3、cve.sqlite3-shm、cve.sqlite3-walが追加される。

##4.5 vulsインストール
[root@vuls sakura]# mkdir -p $GOPATH/src/github.com/future-architect
[root@vuls sakura]# cd $GOPATH/src/github.com/future-architect
[root@vuls sakura]# git clone https://github.com/future-architect/vuls.git
[root@vuls sakura]# cd vuls
[root@vuls vuls]# make install

##4.6 Vulsの設定ファイルを作成と編集
　・スキャン対象サーバーの設定（その他通知先なども設定もできる）

[root@vuls sakura]# cd $HOME
[root@vuls sakura]# cat config.toml

　 ※ローカルと、リモート（Web）をスキャンする。

[servers]

[servers.153-127-**-**]host         = "153.127.**.**" ←vulsサーバIP
port         = "22"
user         = "sakura"
keyPath      = "/home/sakura/.ssh/id_rsa"←vulsサーバ側で秘密鍵のパス

[servers.153-127-**-**]
host         = "153.127.**.**" ←脆弱性スキャン対象リモートサーバのIPアドレス指
port         = "22"
user         = "sakura"
keyPath      = "/home/sakura/.ssh/id_rsa"←vulsサーバ側で秘密鍵のパス

・Configのテストと準備

[root@vuls sakura]# vuls configtest
[root@vuls sakura]# vuls prepare

##4.7 リモートサーバ側の準備（スキャン対象）
　・「sakura」ユーザー追加、ログインします。
　・公開鍵「id_rsa.pub」をSFTPでコピーします。
　・SSHの準備

# mkdir .ssh 
# chmod 700 .ssh 
# cat id_rsa.pub > .ssh/authorized_keys 
# chmod 600 .ssh/authorized_keys 

　※スキャン対象サーバのvuls用ユーザでパスワードなしsudoを可能にする。

[root@vuls sakura]# visudo 以下を行を追記する（ローカルスキャンが必要であれば同様に設定）
 sakura ALL=(root) NOPASSWD: /usr/bin/yum, /bin/echo

#5. スキャン＆レポート
・脆弱性スキャン

[root@vuls sakura]# vuls scan
[root@vuls sakura]# vuls report -format-one-line-text -cvedb-path=$PWD/cve.sqlite3

　※エラーが起きたときはオプション-debugで確認。

・TUI(Terminal-Based User Interface)で詳細表示

[root@vuls sakura]#vuls tui

#6. まとめ
　・手っ取り早く脆弱性の情報収集ができて、レポート機能も充実しているので大変有効なツールです。
　　Webサーバーは放置しすぎていたため、14個の脆弱性が見つかり対応できた。
　・将来的にリモートスキャンサーバーが増えても、Config.tomlを編集さえすれば標準的な対応ができる。
　　このようなツールを有効に利用すればセキュリティ管理者の負担も軽減できる。
　・Vuls祭りVol2のお話にもあったように「情報収集」→「正しい解釈」→「対応」が重要。
　　出力されたCVSSコードより正しい評価（解釈）、そして正しい対応（不要な対応はしない）ができるよう
　　改めて理解を深める必要があると感じた。
　　※IPA共通脆弱性評価システムCVSS概説やJVNレポートの読み方などが参考になる。

　・さくらのクラウドについて・・・
　　サーバー停止時間は料金が掛かりません。（正確にはディスク料金だけ）
　　vulsのようなサーバーは必要なときに必要なだけ立ち上げて利用もできる。
　　お金に余裕があればスイッチ・オプションを配置して構内でスキャンするのが望ましい。
　　NVD、JVNのDB更新やリモートスキャンにおける通信の従量課金費用は気にならないなど上手く活用できる。

#参考文献
・github Fure-architesct
・vulsで脆弱性スキャン対象サーバにリモート接続失敗したときの解決法
・[IPA 共通脆弱性評価システムCVSS概説] (https://www.ipa.go.jp/security/vuln/CVSS.html)
・Japan Vulnerability Notes脆弱性レポートの読み方