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接続ができないオンプレは対応しているのか等がわからない。新規契約者には初期導入や運用について「コンサルティングサービス」オプションの別費用で提供するらしいが相応に費用がかかりそう。

 

letsencryptの設定メモ

■セットアップ

githubからソースをcloneして取得する


$su

#mkdir letsencrypt
#cd letsencrypt
#yum install git
#git clone https://github.com/letsencrypt/letsencrypt.git

■鍵の生成(新規)

letsencryptのSSLを新規作成する場合は下記のような書式で実行する


#新規
#sudo ./letsencrypt-auto certonly  --webroot --webroot-path (nginxのルートフォルダ) -d (ドメイン名)

■鍵の生成(更新)

既にletsencryptのSSLを作成済みで更新する場合


# 更新
#sudo ./letsencrypt-auto --renew certonly --webroot --webroot-path (nginxのルートフォルダ) -d (ドメイン名)

■nginxのconfファイル設定

nginxのconfファイルのSSLを下記のように指定すればOK

    ssl_certificate /etc/letsencrypt/live/(ドメイン名)/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/(ドメイン名)/privkey.pem;

■nginx サービスを再起動

#systemctl restart nginx.service

サービス再起動後にhttpsを確認、letsencryptによって信頼された証明書になっていればOK

jQuery MobileのXSSについての対策

 

 

jQuery MobileのXSSについての解説 - 金利0無利息キャッシング – キャッシングできます - subtech.

はてブのエントリーに挙がっていた。

 

XSSの脆弱性はajaxを無効にしていれば、ほぼ問題ないレベルだと思いますが、

しっかりと対策したい人には参考になるエントリーです。

 

とりあえず、githubから最新版を取得すれば比較的安心できると思うので、

jQuery mobileのgithubからのビルド方法を備忘録

  1. gitクライアントをインストールする
    (windowsの利用を前提にすると、msysgitとか)
  2. gitから最新版取得
    (msysgitを起動 → git clone https://github.com/jquery/jquery-mobile.git)
  3.  makeの環境を設定
    (msysgitのディレクトリに/bin/make.exe がインストールされるので、環境変数PATHに追記する)
  4. make実行
    (msysgitのmingwのままで、取得したjquery-mobileのパスへ移動、makeを実行)
  5.  ビルド完了
    (jquery mobile配下に、compiledが出力される)

あとは、XSSの根本的な対策として、Webサーバーにアプリケーションファイアウォールも設定しておくと安心できるかもしれません。

Linux系サーバー → mod_security
Windows系 → UrlScan

 

 

jQuery mobile beta1リリース

 

スマートフォン開発で注目されている「jQuery mobile」

 

ソーシャルゲームでは開発プロセスに取り入れられていたり、注目度が高いのですが。

jQuery mobileの開発バージョンは、今週6/20 Mon にbeta1リリースが発表されたばかりで、

ようやく仕様Fixという状況です。

 

自分もあるサイト開発でAlpha4からBeta1へ移行を実施したので、
注意点等、備忘録として下記します。

 

  • jQuery mobile 1.0.a4.1から 1.0.b1へのアップデート注意点
  1. デフォルトでスマートフォン表示に最適化されない
  2. 以下のmetaタグを加えると解決(alpha版まではjsで生成されていたらしい)

    <meta name="viewport" content="width=device-width, initial-scale=1">

  3. ajax遷移のフラグがalpha版の仕様から変更
  4. alpha 1.0.a4.1 では、以下2つの変数を無効にすればよかったのですが

    $.mobile.ajaxLinksEnabled=false;
    $.mobile.ajaxFormsEnabled=false;

    beta 1  からはajaxEnabledという変数をfalseにする必要があります。
    $.mobile.ajaxEnabled=false;

    下記のように、mobileinit関数にバインドする事で、ajax遷移(画面遷移時のスライド等)が無効化されます。

    $(document).bind("mobileinit",function(){
    $.mobile.ajaxEnabled=false;
    });

  5. backボタン
  6. alphaではデフォルトで「back」ボタンが有効でしたが、betaからデフォルトが無効になりました。addBackBtn変数を"true"にする事で、デフォルトでbackボタンが表示されるようになります。
    $(document).bind("mobileinit",function(){
    addBackBtn=true;
    });

  7. cssの変更
  8. cssの構造も若干変更されているので、cssグラデーション等でカスタマイズしているサイトも影響があるようです。

  9. clickイベント
    jQuery mobileのフレームワーク内でjsのclickイベントをバインドするようになったので、サイト側でclickイベントのバインドを利用している場合、alpha版と動作が異なる場合があるらしいです。
  10. その他、機能改善
  11. ・ブラウザのアドレスバーが自動的に隠れるようになった
    ・画面遷移のajaxアニメーションがかなり改善された

  12. XSS脆弱性のセキュリティアップデート
  13. githubで指摘されていたXSS脆弱性がFixされたそうです
    https://github.com/jquery/jquery-mobile/pull/1789
    この指摘は笑えないので、alpha版を利用しているサイトは早急にBetaへアップデートした方がいいですね・・・

    ※まとめ

    ・XSS脆弱性対策としてalphaからBetaへのアップデートは必須
    ・ajax関連はかなり改善されたが、画面遷移のajaxを使うのはリスク大
    ・今後のアップデートでajaxやレンダリングの安定が見込めるので、Betaリリースを機会に手を出してみるといいかもしれない

     

    ※出典:

    解決策など、こちらのブログが参考になりました

    「jquery mobile beta1でハマった点まとめ」

    http://yslibrary.wordpress.com/2011/06/21/jquery-mobile-beta-1-tips/