こんにちわ。Mr.Xです。
[Qiita] 脆弱性スキャナVulsでAmazon EC2をスキャンし脆弱性深刻度をタグ付けする
この記事に触発されて、Azureでやってみようと思ったのでやってみた。
当該の記事ではこのようなアーキテクチャと、動作イメージでした。
（画像は記事からのキャプチャ）
AWSでできるなら、Azureでもできるじゃろ、というわけでこれをやってみようというわけだ。
できるかな?
そのほか参考にしたサイト
[Qiita] あなたのサーバは本当に安全ですか？今もっともイケてる脆弱性検知ツールVulsを使ってみた
[github] future-architect/vuls
[Azure Document] Azure Functions の概要
[Azure Document] Azure Functions のトリガーとバインドの開発者用リファレンス
実現イメージ
参考記事のS3をAzure Storage(BLOB)に、LambdaをAzure Functionsにそれぞれ入れ替えてみよう。いったん作ってから、応用はそのあと考えることにした。
Azure Functions は BLOB からのイベントをトリガーにして、小さなプログラムを実行できる。ドキュメントによれば、BLOBに入れたJSONをC#なら関数一つで簡単にデシリアライズできるとのこと。
・・・正直書いたことないけどC#で進めることになりそうだ。
絵的にはこうなるか。まあ、おんなじだよね。
記事ではMacからvulsを実行してたけど、手元の環境はとりあえずAzureで全部用意することにした。特に分割したりする意味を感じないので、全部一つのリソースグルーブに配置。VNET、subnetも一つだけ。
まずは環境を作ろう
諸作業は割愛。
vuls用のLinuxVMはA0スタンダードでCentOS Base 7.2 です。
スペックは元記事ならEC2のnanoでもいける、ということなので、あえてのこのスペックでトライ。とりあえずyumで導入済みのパッケージ群を最新にしておいた。
README（日本語）とREADME（英語）を読んで、ステップに沿って導入する。
なお、以下は各ステップにおいての所感・補足なので、実作業は英語版のREADMEを参照されたい。
Step1. Launch Amazon Linux
ここはAWSのサーバー立てろって項なので割愛。
Amazon Linuxの自動アップデートを不活性にしてあるのだけと、これはなんでだろう。一般的なマナーなのかな?
Azureでは、というかCentOS Baseはyumの自動アップデートはデフォルトでオフになっているので、一旦このままにしておこう。
Step2. SSH Settings
これはvulsが利用するための鍵を作る、という印象でよさそうだ。
ただ、そうであればauthorized_keyへの追記は必要ないのでは?と思うけど、とりあえずそのまま倣って作業する。正直、このマシンでの追記は必要はなかった。
ただ、vuls用に鍵を用意する、ということには意味はある。
よりセキュアに、と考える場合は試験先のサーバーも、個別にアクセスユーザーを作成するべきだろう。
Step3. Install requirements
SQLite, git, gcc, go(v1.6)が必要みたいだ。個別にインストールしていこう。
SQLite 既に sqlite-3.7.17-8.el7.x86_64 がインストールされていた。
git yumで入れる。git-1.8.3.1-6.el7_2.1.x86_64
gcc どうせ make も configure もするので、”Development Tools”で
グループインストールしてしまう。こまけえこたぁいいんだよ。
go むむ。どうもbaseリポジトリにあるのは古いな・・・
golang.x86_64 1.4.2-9.el7 base
ドキュメントに倣い、goの本家からバイナリをDLしてさらっとインストール。
1.6.2がstableなのでそれを利用することにした。
Step4. Deploy go-cve-dictionary
ここで無慈悲なメッセージをゲット。
/usr/local/go/pkg/tool/linux_amd64/link: running gcc failed: fork/exec /usr/bin/gcc: cannot allocate memory
この時点での残メモリは200MB程度。足りなかったか・・・・
仕方がないのでA1に上げよう・・・
その後CVEのデータを取得する。2002～2016で大体40分。ただ、ネットワークの状況で前後するとは思う。この間の最大CPU利用率は60%程度まで上昇し、メモリの利用率は40%まで上昇していた。日本語のデータは時間かかるみたいなんで後回し。
Step5. Deploy Vuls
特に問題も無くできたっぽい。
Step6. Config
TOMLという記法、とのことだけどパッと見た感じ iniファイルとか普通のコンフィグみたい。特に説明はないのだけど、ターゲットマシンの情報をここに入れておくもののようだ。
Step7. Setting up target servers for Vuls
前のステップでこのvulsを入れたサーバーを設定してある。
一旦自分自身を検査対象にしてみよう。特に問題なくPrepareが完了した。
でもあれ?
“INFO [localhost] (1/1) vlus-server is running on aws”
うーん。なぜかAWSにいるってことになった。バグでしょうかね。
Step8. Start Scanning
ではスキャン開始!
・・・yum updateが災いしたのか、何もでなかった・・・
さて。これでvuls検査サーバー側は準備完了。
後回しにしていたJVNのデータも試しに持って来たら、終了までに2時間かかった。
さて、動作チェックのために、適当に古いOS（CentOS Base-6.5）でターゲットマシンを作った。これにチェックをかけると・・・・
395項目のチェックにおよそ30分かかった。
ただ、ターゲットマシンがA0 スタンダードだったためか、CPUは張り付き状態だった。
おそらくパッケージファイルの読み込みを連続して行うせいだろう。メモリは横ばいだったので、CPUにのみ負荷が行った感じだ。ターゲットマシンは何もアップデートしていない、脆弱性をふんだんに残した環境なので、あくまでも参考にしかならないが、おまけの結果として処理特性が垣間見えた気がする。
AシリーズでもマルチコアのものやDシリーズ、Fシリーズであればもっとスムーズにチェックは終わるだろう。
さて、とりあえず基本的な形ができたところでいったん終了。
次回は、Azure Storage / Functions 編、ここからが本番。