Vuls for Azureできるかな(第1回)

こんにちわ。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#で進めることになりそうだ。

絵的にはこうなるか。まあ、おんなじだよね。
vuls_arch_20160609
記事では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
ではスキャン開始!
vuls_scan0・・・yum updateが災いしたのか、何もでなかった・・・

さて。これでvuls検査サーバー側は準備完了。
後回しにしていたJVNのデータも試しに持って来たら、終了までに2時間かかった。

さて、動作チェックのために、適当に古いOS(CentOS Base-6.5)でターゲットマシンを作った。これにチェックをかけると・・・・

vuls_check_20160609395項目のチェックにおよそ30分かかった。
ただ、ターゲットマシンがA0 スタンダードだったためか、CPUは張り付き状態だった。
おそらくパッケージファイルの読み込みを連続して行うせいだろう。メモリは横ばいだったので、CPUにのみ負荷が行った感じだ。ターゲットマシンは何もアップデートしていない、脆弱性をふんだんに残した環境なので、あくまでも参考にしかならないが、おまけの結果として処理特性が垣間見えた気がする。
AシリーズでもマルチコアのものやDシリーズ、Fシリーズであればもっとスムーズにチェックは終わるだろう。

さて、とりあえず基本的な形ができたところでいったん終了。
次回は、Azure Storage / Functions 編、ここからが本番。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*