Vuls導入メモ IPAテクニカルウォッチ「脆弱性対策の効果的な進め方(ツール活用編)」

IPAテクニカルウォッチ「脆弱性対策の効果的な進め方(ツール活用編)」

https://www.ipa.go.jp/security/technicalwatch/20190221.html

2019年2月21日にIPAが脆弱性対策についての効果的なツール活用としてVulsが紹介されていた。

ちょうど自前でもVulsを導入したので、手順やつまづいた点を備忘録にブログにまとめておく。

 

vuls reportコマンドの正しいオプション指定

公式サイトの例ではrepotコマンドのオプション指定が下記のようになっているが、公式の例のようにcve情報をsqlite3で構築していると下記のオプションでは正しく動作しなかった。

 -cvedb-path="...."
 -ovaldb-path="...."
 -gostdb-path="...."
 -exploitdb-path="...."

正しいオプション指定は以下になる

-cvedb-sqlite3-path="...."
-ovaldb-sqlite3-path="...."
-gostdb-sqlite3-path="...."
-exploitdb-sqlite3-path="...."

config.tomlファイルへ記載してオプションを省略する

DB参照のオプションはconfig.tomlへ登録することができる。confに設定すれば何度も同じオプションを指定する必要がなくなる。

公式を参考にvulsユーザーの環境に構築していればconfig.tomlの記述は下記のようになる。

 

https://vuls.io/docs/ja/usage-report.html

[cveDict]
type="sqlite3"
SQLite3Path="/home/vuls/cve.sqlite3"

[ovalDict]
type="sqlite3"
SQLite3Path="/home/vuls/go/src/github.com/kotakanbe/goval-dictionary/oval.sqlite3"

[gost]
type = "sqlite3"
SQLite3Path="/home/vuls/go/src/github.com/knqyf263/gost/gost.sqlite3"

[exploit]
type = "sqlite3"
SQLite3Path ="/home/vuls/go/src/github.com/mozqnet/go-exploitdb/go-exploitdb.sqlite3"

 

Vulsのレポートをhttps(443ポート)で閲覧

レポートが生成されるとWebブラウザで結果を表示することができるのだが、デフォルトだとvuls repotサーバに接続するためには5111ポートを開放しなければならない。(例:http://example.com:5111/)脆弱対策のレポート閲覧にポートの追加開放が必要というのはスマートではないし本末転倒。

Webサーバ構築に慣れている人はすぐに気づくと思いますが、nginxやapacheをプロキシとして設定すれば外部からのレポート参照はhttpから閲覧できる。私の場合はnginxでproxy設定したのだが一般的なconfの記述でSSL設定(https)とBasic認証の設定が可能だった。

(vulsのマニュアルでは5111ポートにvuls用のSSLとvuls用の認証設定が記載されている)

 

リモートスキャン設定

方法1.http経由のスキャンでは5515ポートを開放してスキャンサーバを実行させて、かつクライアントからhttpを実行、ログはクライアント側に出力される。

方法2.ssh経由のスキャンではスキャン対象のssh鍵が必要。fast scan以外の実行にはsudo権限が必要になる。(実質的にいくつかOSファイルをインストールが必要になる場合がある)

どちらも試したのだが、1の方法は5515のポート開放が必須でログがリモート側に保存されて管理が煩雑になるため5515ポートを閉じて利用しない事にした。現在は2の方法でssh経由のスキャンを運用している。

基本的にバッチ処理の組み合わせなのでcronで定期実行を設定しておけばレポート画面を自動更新することができる。慣れてくるとレポート画面の確認をサボってしまうので、出力結果をメールやslack, mattermost等に飛ばしておくと忘れることがなくなる。

 

※システム連携のサンプル

出典:

https://github.com/future-architect/vuls/

vulsのgithubから引用

感想

ディストリビューションが提供する最新パッケージを適用していても修正されていない脆弱性が大量にあるため、セキュリティリスクを把握して対策できるものは対策する、対策する必要がない場合はそのリスクを把握する判断が必要とされる。

 

◇Vuls導入の利点・長所、個人的に良いと思うところ:

・Vulsのリモートスキャンはエージェントレスなので、対象のサーバに追加アプリケーションのインストールが不要(※yumのパッケージ管理の場合は1つだけパッケージインストールが必要)

・一般的なCVEの脆弱性情報を利用するため、標準的なLinux/Windowsシステムであればプラットフォームに依存しない、AWSやVPS環境でも利用可能

・全てのCVE情報を対象とするため診断精度が高い。システムの脆弱性診断としてはAWSのInspectorよりも詳細なレポートが得られる

・スキャン設定が選択可能でFastでは高速に検査できる。Deep設定では追加の権限設定が必要だが詳細情報を取得可能。

・基本的にバッチ処理とレポート生成だけなので、サーバーリソースが少なくても快適に動作する

・OSS版だけでもセキュリティリスクの現状把握として十分に有用だが、OSS版に対応できるエンジニアがいなくて予算に余裕があるならクラウド版を導入するとよさそう。(1台あたり4000円かかる)

◇Vulsではたりなさそうな短所、個人的にイマイチだと思えるところ:

・SSHでスキャンする場合、スキャン元から接続できるSSHポートが必要、かつSSH鍵のパスフレーズを削除する必要があり、鍵が漏洩したときに第三者の攻撃の懸念になる。(iptablesやsshd_configで接続元を制限することで対策可能)

・CVSS情報にない脆弱性(例えばAWSの固有設定についての脆弱性、AWSだとTrustedadvisor相当の情報)は検査できない。version 007からWordPress特有のセキュリティリスクは内部的にWPScanと同等の検査が行われるようになったらしい。
※version 007にアップデートして検査したがWordPres関連と見られる検査結果は見当たらなかった。。。

・Vuls商用版がメインで提供されているため、OSS版の構築や運用手順、検出したCVSSの情報が少ない。Windowsの脆弱性スキャンは有料版のみ対応。

・有料版の案内が不明瞭。vulsをGoogle検索しても有料版のURLが10位内に表示されない。クラウド版は1台のスキャン設定あたり4,000円(税抜き)とあるがVMやクラウドでも台数があるとそれなりの金額になる。固定のGIPが必要なのかSSH接続ができないオンプレは対応しているのか等がわからない。新規契約者には初期導入や運用について「コンサルティングサービス」オプションの別費用で提供するらしいが相応に費用がかかりそう。

 

CacooのAWS構成図自動生成機能を試す

Visioの代わりに使っている設計用の作画サービス「Cacoo」でAWSの構成図Export機能が追加された。

https://cacoo.com/ja/blog/aws-architecture-import/

紹介記事の手順ではアクセスキーを登録するリスクが心配ですが、サポートページではクロスアカウントのIAMロールで登録する方法が掲載されているので、後者を参考にすると良いです。

https://support.cacoo.com/hc/ja/articles/360010495594-AWS%E6%A7%8B%E6%88%90%E5%9B%B3

 

AWS構成図の対象

  • CloudFront+ELB(ALB)AutoScaling+EC21台(待機2台)+RDS+その他一般的なCloudWatch,SNSあり
    (※ARNやVPC名等は消去しています)

利用した感想

  • AWS構成図の自動生成で有名な「CloudCraft」と比べると、出力結果が物足りない(見た目とサービス間の情報が貧弱)
  • 競合の「CloudCraft」「lucidchart」と比べると、コストパフォーマンスが最も良い。
  • ELB/ALBに登録されているAutoScalingの情報が出力されない(競合のlucidchartは出力される)
  • CloudFrontとALBの連携が出力されない(図から省略したがCloudFrontとS3 web frontの連携は出力される)
  • CloudWatchの情報が出力されない(競合のlucidchartはCloudWatchのアラート登録が出力される)
  • DynamoDBの情報が出力されないが、構成図の出力に対応してほしい(競合のlucidchart Basicも同様に出力されない)
  • Lambdaの情報が出力されない(ALBにもマウントできるので、できれば出力してほしい)
  • S3とSNSはバケットとCloudWatchの名称だけが表示される
  • 可能であれば、ELBやCloudfrontに登録されているRoute53, Config, セキュリティグループあたりの情報もほしい
  • 未検証だが「CloudMapper」というAWSの構成図を出力できるOSSがある。
    https://github.com/duo-labs/cloudmapper
    出力結果がCLoudformationで提供されているエディタに類似していて、商用サービスよりも強力かもれない。

 

AWS構成図の生成はCloudCraftが有名でしたが、低価格のサービスで提供されるようになったのは嬉しいところです。

 

 

s3のバケットでWebホスティングしたドメインをCloudFrontのACMでhttps化するときの注意点

Amazon s3に登録したドメインをCloudFrontのACMでhttps化する設定で、小さなハマりどころがあったので、備忘録としてブログに残します。

■目的
・s3で配信しているWebページがある
・s3の配信をhttps化して、かつCloudFrontで高速に配信したい

まず、解決方法の概要から、
s3で配信するために登録したDNS(Route53)設定のままでは、CloudFrontを経由した配信にならずhttpsの通信ができない。
CloudFront用のドメインをRoute53に登録すれる事で解決した。
それだけの設定なのですが、CloudFront用のドメインに気付くまで時間が掛かってしまった。。。

※CloudFrontのドメインが表示される画面
“CloudFrontリソースグループ “の “General”を設定すると該当のドメインが割り当てられて表示される。

 

 

 

 

 

 

 

 

※Route53設定の注意点

・前提条件として、s3でのWeb配信は設定済みとする。
・s3をCloudFrontで参照するためには、赤枠で囲ったドメイン(xxxx.cloudfront.net)を、Route53の配信対象のドメインへcnameとして設定する必要がある

※CloudFrontのOrigin設定
・s3で独自ドメインを割り当てたバケットはhttpsが使えないので、”Origin Protocol Policy”には”http only”を指定する
・”Origin Domain Name”が設定済みだと、プロトコル選択(http, https)が表示されない場合がある
・”Origin Domain Name”に適当なドメイン(test.comとか)を入力すると、プロトコル選択(http,https)が表示される

※CloudFrontのBehavior設定
・”http and https”
・その他はキャッシュ範囲、キャッシュ時間等を目的にあわせて設定する

 

 

AWS RDSのparameter_groupを初期化する方法

Qiitaのエントリーを参考に設定しようと試したのだけれど、
サンプルの書式ではコマンドが通らず。

http://qiita.com/web_se/items/3f789f70873b88720b0e

下記のようにパラメータを全てリセットすると正常に反映された。

$ aws rds reset-db-parameter-group --db-parameter-group-name rdsparam-group --region ap-northeast-1 --reset-all-parameters

原因はわからないがとりあえず備忘録に残します。

AWS-CloudDesignPattern

 

AWS-CloudDesignPattern.

先日3/4のJAWS-UG サミットで発表された

AWS Cloud Design Pattern

 

現状ではFacebookを経由しないとWikiが見れないので、

Googleで検索しても上位に表示されない。

 

Facebookの「いいね」乞食もいいけど、これではSEO的にイケてない。

なので、勝手にURLをリンクさせて頂きました。

リンク先に興味のある方はWikiを見たら「いいね」もお願い致します。

AWS-CloudDesignPattern.