忙しい人のための Use AWS WAF to Mitigate OWASP’s Top 10 Web Application Vulnerabilities メモ

こんにちは、ひろかずです。

2017年7月に「Use AWS WAF to Mitigate OWASP’s Top 10 Web Application Vulnerabilities」が公開されました。
日本語翻訳されていないので、なかなか読めていない方もいると思います。
リリースから少し時間が経ってしまいましたが、読了したので一筆書きます。

どんなドキュメントか

OWASP Top10 で上っている各項目についての解説と、各項目についてAWS WAFでどのような対応ができるかを記載したもの。
Conditionを作る上でのアドバイスも記載されている。

参照ドキュメント

Use AWS WAF to Mitigate OWASP’s Top 10 Web Application Vulnerabilities

A1 – Injection

SQLインジェクション攻撃は、比較的簡単に検出できるが、バックエンドの構造によって複雑さが変わるため、アプリケーション側での対応も必要。
cookieやカスタムヘッダをデータベース参照に使う場合は、Conditionで検査対象とするように設定すること。
リクエスト中にクエリを流す事を是としているサービスの場合、対象URLを検知除外(バイパス)するような設定を検討すること。

A2 – Broken Authentication and Session Management

String Matchを活用して、盗まれた(怪しい)トークンを「安全のために」ブラックリストに登録する
デバイスのロケーションが異なるトークンを検出する等、ログから悪性利用をしているトークンを分析して、ブラックリストに登録するような使い方。
Rate-basedルールを用いて、認証URLを総当り攻撃を防ぐ施策も有効。

A3 – Cross-Site Scripting (XSS)

XSS攻撃は、HTTPリクエストで特定のキーHTMLタグ名を必要とするため、一般的なシナリオで比較的簡単に軽減できる。
BODYやQUERY_STRING, HEADER: Cookieを検査するのが推奨される。
URLを検査対象とすることは一般的ではないが、アプリケーションが短縮URL使っていると、パラメータはURLパスセグメントの一部として表示され、クエリ文字列には表示されない(後でサーバー側で書き換えられる)
CMSエディタ等、たくさんHTMLを生成するサービスには効果は薄い。
対象URLを検知除外(バイパス)する場合は、別途対策を検討すること。
加えて、<script>タグを多用するイメージ(svgグラフィックフォーマット)やカスタムデータも誤検知率が高いので調整が必要。

A4 – Broken Access Control

2017年から新たに登場
認証ユーザーの制限が適切に動作せず、必要以上に内部アプリケーションオブジェクト(不正なデータの公開、内部Webアプリケーション状態の操作、パストラバーサル、リモート/ローカルファイルの呼び出し)を操作できるというもの。
機能レベルのアクセス制御の欠陥は、一般的に後で追加されたアプリケーションで発生する。
アクセスレベルは、呼び出し時に一度検証されるが、その後に呼び出される様々なサブルーチンについては、都度検証されない。
呼び出し元のコードが、ユーザーの代わりに他のモジュールやコンポーネントを呼び出す暗黙的な信頼ができてしまう。
アプリケーションが、アクセスレベルやサブスクリプションレベルに応じてコンポーネントへアクセスさせる場合は、呼び出しの都度、検証する必要がある。

AWS WAFとしては、「../」や「://」をQUERY_STRINGやURIに含むかを検証することで、リモート/ローカルファイルの呼び出しを検出できる。
これも、リクエスト中に「../」や「://」を含む事を是とするアプリケーションには効果は薄い。
管理モジュール、コンポーネント、プラグイン、または関数へのアクセスが既知の特権ユーザーのセットに限定されている場合、Byte_MatchとIPSetの組み合わせでアクセスを制限することができる。

認証要求がHTTPリクエストの一部として送信され、JWTトークン(のようなもの)でカプセル化されている場合

  • Lambda@Edgeファンクションを用いて、関連リクエストパラメータがトークン内のアサーションおよび承認と一致することを確認することで、権限不適合リクエストはバックエンドに届く前に拒否することができる。

A5 – Security Misconfiguration

セキュリティの影響を受けるパラメータの設定ミスは、アプリケーションだけではなく、OSやミドルウェア、フレームワーク全てにおいて発生し得る。
セキュリティの影響を受けるパラメータの設定ミス例

  • ApacheのServerTokens Full(デフォルト)構成
  • 本番Webサーバーでデフォルトのディレクトリ一覧を有効にしたまま
  • エラーのスタックトレースをユーザーに戻すアプリケーション
  • PHPの脆弱なバージョンと組み合わせて、HTTPリクエストを介して内部サーバ変数を上書き

AWS WAFとしては、パラメータの設定ミスを悪用するHTTPリクエストパターンが認識可能な場合に限り対応可能。

  • A4 – Broken Access Controlと同様に、特定パスやコンポーネントに対してByte_MatchとIPSetの組み合わせでアクセスを制限を行う。(Wordpress管理画面 等)
  • 脆弱なPHPを利用している場合、QUERY_STRING中の“_SERVER[“を遮断する。

その他に考慮できること

  • Amazon Inspectorでの設定ミスの捜査(rootログイン許可や脆弱なミドルウェアバージョン、脆弱性の対応状況)
  • Amazon InspectorでのCISベンチマークとの適合性チェック
  • AWS ConfigやAmazon EC2 Systems Managerを用いた、システム構成変更の検出

A6 – Sensitive Data Exposure

アプリケーションの欠陥による機密情報の暴露をWAFで緩和するのは難しい。
この欠陥には、一般に不完全に実装された暗号化が含まれる(弱い暗号の利用を許容していること)

AWS WAFとしては、HTTPリクエスト中の機密情報を識別するパターンをString-Match Conditionで検出することで、機密情報へのアクセスを検出することができる。(ホストするアプリケーションに対する深い知識が必要)
アプリケーションが、アップロードを許容する場合、Base64を示す文字列の一部を検出するString-Match Conditionが有効(BodyはBase64でエンコードされているから)
一般的ではない手法

その他に考慮できること

  • AWS内の機能を使って、接続ポイントにて、ELBで強い暗号化suiteを使用するように制限する
  • クラシックロードバランサの場合、事前定義・カスタムセキュリティポリシーで制御できる。
  • アプリケーションロードバランサの場合、事前定義セキュリティポリシーで制御できる。
  • Cloud Frontでも利用するSSLプロトコルを制限できる。

A7 – Insufficient Attack Protection

2017年から新設
このカテゴリは、新しく発見された攻撃経路や異常なリクエストパターン、または発見されたアプリケーションの欠陥にタイムリーに対応する能力に重点を置いている。
幅広い攻撃ベクトルが含まれるので、他のカテゴリと重複する部分もある。

確認ポイント

  • アプリケーションに対して、異常なリクエストパターンや大量通信を検出できるか?
  • その検出を自動化できる仕組みはあるか?
  • 不要な通信に対して、ブロックできる仕組みはあるか?
  • 悪意のあるユーザーの攻撃開始を検出できるか?
  • アプリケーションの脆弱性に対するパッチ適用までの時間はどの程度かかる?
  • パッチ適用後の有効性を確認する仕組みはあるか?

AWS WAFで何ができるか

  • Size-Content Conditionを使うことで、アプリケーションで利用するサイズ以上の通信を検出・遮断できる。
  • URIやクエリ文字列のサイズを、アプリケーションにとって意味のある値に制限すること。
  • RESTful API用のAPIキーなどの特定のヘッダーが必要になるようにすることもできる。
  • 特定IPアドレスからの5分間隔での要求レートに対する閾値設定。(例えば、UserAgentとの組み合わせでのカウントも可能)
  • Web ACLはプログラマブルで反映が早いのが利点(CloudFrontに対しても約1分で反映)
  • ログの出力傾向から分析して、Web ACLを自動調整する機能も構築できる。

AWS WAFのセキュリティオートメーション機能の活用

  • Lambdaを使って、4xxエラーを多く出しているIPアドレスを特定してIPブラックリストに登録する。
  • 既知の攻撃者に対しては、外部ソースのIPブラックリストを活用する。
  • ボットとスクレイバに対しては、robots.txtファイルの ‘disallow’セクションにリストされている特定URLへのアクセスを行ったIPを、IPブラックリストに登録する。(ハニーポットと表現されています)

A8 – Cross-Site Request Forgery

CSRFは、WebアプリケーションのStateを変更する機能を対象としている。
State変更に係るURLやフォーム送信などのHTTPリクエストを考慮する。
「ユーザーがその行動を取っている」ということを必ず証明する機構がなければ、悪意のあるユーザーによるリクエスト偽造を判断する方法はない。

  • セッショントークンや送信元IPは偽造できるので、クライアント側の属性に頼るのは有効ではない。
  • CSRFは、特定のアクションのすべての詳細が予測可能であるという事実(フォームフィールド、クエリ文字列パラメータ)を利用する。
  • 攻撃は、クロスサイトスクリプティングやファイルインクルージョンなどの他の脆弱性を利用する方法で実行される。

CSRF攻撃への対処

  • アクションをトリガーするHTTPリクエストに予測困難なトークンを含める
  • ユーザー認証プロンプトの要求
  • アクション要求時のキャプチャの提示

AWS WAFで何ができるか

  • 固有トークンの存在確認
  • 例えば、UUIDv4を活用して、x-csrf-tokenという名前のカスタムHTTPヘッダーの値を期待する場合は、Byte-Size Conditionが使える。
  • ブロックルールには、POST HTTPリクエスト条件に加える

その他にできること

  • 上記のようなルールでは、古い/無効な/盗まれた トークンの検出については、アプリケーションでの対応が必要
  • 例えばの仕組み
  • サーバが、一意のトークンを隠しフィールドとしてブラウザに送信し、ユーザーのフォーム送信時の期待値にする。
  • 期待したトークンが含まれないPOSTリクエストを安全に破棄できる。
  • 処理後のセッションストアからトークンは削除しておくことで、再利用がされないことを保証。

A9 – Using Components with Known Vulnerabilities

既知の脆弱性を持つコンポーネントの利用
ソースや、商用/オープンソースのコンポーネント、フレームワークを最新に保つことが重要
最も簡単な攻撃ベクトルで、その他の攻撃手法の突破口にもなる。
脆弱なサブコンポーネントに依存するコンポーネントの利用しているケース。
コンポーネントの脆弱性は、CVEにて管理/追跡されないので、緩和が難しい。

  • アプリケーション開発者は、それぞれのベンダー、作成者、またはプロバイダとのコンポーネントのステータスを個別に追跡する責任を負う。
  • 脆弱性は、既存のバージョンを修正するのではなく、新機能を含む新しいバージョンのコンポーネントで解決される。
  • そのため、アプリケーション開発者は、新バージョンの実装、テスト、デプロイの工数を負担する。

基本的な対処に

  • アプリケーションの依存関係と基礎となるコンポーネントの依存関係の識別と追跡
  • コンポーネントのセキュリティを追跡するための監視プロセス
  • コンポーネントのパッチやリリース頻度、許容されるライセンスモデルを考慮したソフトウェア開発プロセスとポリシーの確立
  • これらにより、コンポーネントプロバイダーがコード内の脆弱性に対処する際に、迅速に対応できる。

AWS WAFで何ができるか

  • アプリケーションで使用していないコンポーネントの機能に対するHTTPリクエストをフィルタリングおよびブロックによる、攻撃面の削減
  • 例)HTTPリクエストを直接/間接的にアセンブルするコードへのアクセスのブロックする
  • String-matchコンディションを用いたURI検査(例えば、”/includes/”の制限)
  • アプリケーションでサードパーティのコンポーネントを使用しているが機能のサブセットのみを使用する場合は、同様のAWS WAF条件を使って、使用しないコンポーネントの機能への公開URLパスをブロックする。

その他にできること

  • ペネトレーションテスト。マーケットプレイスで買える。申請が必要だが、一部事前承認を受けているサービスでは申請が不要なこともある。(マーケットプレイス上のマークで識別可能)
  • 展開とテストのプロセスに統合して、潜在的な脆弱性を検出するとともに、展開されたパッチが対象となるアプリケーションの問題を適切に緩和する。

A10 – Underprotected APIs

2017年版の新カテゴリ
特定アプリケーションの欠陥パターンではなく、潜在的な攻撃ターゲットを示す

  • UIを持たないアプリケーションは増えてきている。(UI/API両方使えるサービスも同様)
  • 攻撃ベクトルは、A1-A9までと変わらないことが多い。
  • APIはプログラムからのアクセスのために設計されているので、セキュリティテストでは、追加の考慮事項がある。
  • APIは、(Rest,SOAP問わず)複雑なデータ構造での動作とより広い範囲の要求頻度と入力値を使用するように設計される事が多い。

AWS WAFでできること

  • A1-A9での対応と変わらないが、対APIとして追加でできる事がある。
  • 強化が必要な主要コンポーネントは、プロトコルパーサ自体(XML,YAML,JSON 等)
  • パーサーの欠陥を悪用しようとする特定の入力パターンをString-match Condition、またはByte-Size Conditionを使用して、そのような要求パターンをブロックする。

旧OWASP Top10 A10 – Unvalidated Redirects and Forwards

リダイレクトや転送要求を検証しない場合、悪意のある当事者が正当なドメインを使用してユーザーを不要な宛先に誘導する可能性がある。

  • 例)短縮URLを生成する機能がある場合、URLジェネレータがターゲットドメインを検証しないことで、悪意を持ったユーザーが正式サービス上から悪意のあるサイトへの短縮URLを発行できる。

AWS WAFでできること

  • まず、アプリケーションでリダイレクトとフォワードがどこで発生するのかを理解する(リクエストパターン等)
  • アプリケーションが使用する、サードパーティコンポーネントも同様にチェックする。
  • エンドユーザからのHTTPリクエストに応じてリダイレクトと転送が生成された場合は、AWS WAFでリクエストをQUERY_STRINGやURIに対するString-Match Conditionでフィルタリングする(リダイレクト/転送の目的で信頼されているドメインのホワイトリストを維持する)

Cloud Formationテンプレート

Web ACLと、このドキュメントで推奨されている条件タイプとルールを含むAWS CloudFormationテンプレートが用意されています。
今回は、解説を割愛します。

所感

AWS WAFの設定は基本的にDIYですが、実装のポイントをOWASP Top10になぞらえて、その対応を解説する良いヒント集だと思いました。
AWS WAFを設定する人は、一読するのがいいですね。
外部にAWS WAFの設定を依頼する人は、アプリケーションの特性をよく理解している人を立てて、設定する人とよくコミュニケーションを取ることが重要だとわかります。
セキュリティ製品の真価を発揮するには、保護する対象のサービスへの理解とサービスへの適合化が必要なのは、どんなソリューションにも共通しますね。

今日はここまでです。
お疲れ様でした。

続きを読む

Amazon Inspectorを試してみた

Amazon Inspectorとは

EC2で実行されているアプリケーションのセキュリティ状態をテストできるものです。

利用可能なリージョン

us-east-1,us-west-2,eu-west-1,ap-northeast-1

利用可能なOS

Amazon Inspector でサポートされているオペレーティングシステムとリージョン

Amazon Linux (2015.03、2015.09、2016.03、2016.09、2017.03)
Ubuntu (14.04 LTS、16.04 LTS)
Red Hat Enterprise Linux (6.2、6.3、6.4、6.5、6.6、6.7、6.8、6.9、7.2、7.3)
CentOS (6.2、6.3、6.4、6.5、6.6、6.7、6.8、6.9、7.2、7.3)

設定

EC2にエージェントインストール

今回はAmazon Linuxで試しました。

$ cat /etc/system-release
Amazon Linux AMI release 2017.03

ダウンロードしてインストールします。
リンクの手順に沿ってやるだけです:point_up::dizzy:
AWS エージェントをインストールするには

$ wget https://d1wk0tztpsntt1.cloudfront.net/linux/latest/install

$ sudo bash install

Inspectorの設定

  1. サービスから「Inspector」を選択
  2. 左ペインから「評価ターゲット」を選択し、「作成」をクリック
  3. 名前とキーを入力して「保存」
    スクリーンショット 2017-08-01 10.13.44.png

  4. EC2にタグ付けする
    スクリーンショット 2017-08-01 13.16.58.png

  5. Inspectorで先ほど作成した評価ターゲットの左にある矢印をクリックして、「プレビュー」をクリックするとタグ付けされたEC2が出力されます
    スクリーンショット 2017-08-01 13.19.39.png
    →これが評価ターゲットになります。

  6. 左ペインから「評価テンプレート」をクリックして「作成」をクリックします。

  7. ターゲット名は先ほど作成した評価ターゲットを選択します。
    ルールパッケージは以下から選択可能です。今回はCVEを選択してみました。
    Amazon Inspector のルール パッケージとルール
    ・ 共通脆弱性識別子(CVE)
    ・ Center for Internet Security (CIS) ベンチマーク
    ・ セキュリティのベストプラクティス
    ・ 実行時の動作の分析
    所要時間は長ければ長いほど、より精密な結果が得られるとのことです。
    AWS推奨は1時間。
    SNSと連携してメール飛ばせたりしますが、ここでは省略。
    「作成および実行」を押すと調査が始まります。

スクリーンショット 2017-08-01 13.34.48.png

結果

スクリーンショット 2017-08-01 13.47.29.png
指定した時間が経過すると、調査結果が出力されます。
重要度の左にある矢印をクリックすると詳細が確認で、CVEのページのリンクも載っています。

脆弱性が自分のインスタンスに影響しているのか否か判断できて便利ですね:baby:

料金

料金は月あたり 1 エージェント 1 評価あたり 0.30 USD から始まり、従量制割引により月あたり 1 エージェント 1 評価あたり 0.05 USD の低価格でご利用いただけます。

Amazon Inspector料金

Amazon Inspectorの価格体系について

評価実行中のインスタンスへの影響

評価実行プロセス中のパフォーマンスへの影響を最小限に抑えるように設計されています
Amazon Inspector のよくある質問

CloudWatchで確認してみましたが、CPU使用率が高騰することはありません(上がっても1%未満)でした。

関連資料

BlackBelt

Amazon Inspector とは

Amazon Inspector のよくある質問

続きを読む

Amazon Inspectorのレポート機能を試す

こんにちは、ひろかずです。
Preview版の時にAmazon Inspectorの評価を行いましたが、それっきりになってしまいました。
Amazon Web Services ブログでレポート機能が追加されるなどのアップデートがなされたので、一筆書きます。

目的とゴール

GA/アップデート後のAmazon Inspectorを実行し、その差分とレポート機能がどんなものかを確認する。

参考ドキュメント

Amazon Inspectorユーザーガイド

お品書き

  • 仕様
  • インストール手順
  • 実行手順
  • レポート機能

仕様

対応環境とルールパッケージ

Windows対応やRHEL6系への対応は聞いていましたが、新たにRHEL7.3系に対応されていました。
日本語ドキュメントでは、RHEL7.2系までの記載でしたので、英語ドキュメントを確認するように心がけたいですね。

対応環境毎に利用できるルールパッケージが異なるので、スキャンを実施する前に確認してください。
サポートされているオペレーティングシステムに関して、提供されているルールパッケージ

ルールパッケージは、Preview版は6種類でしたが、現在は4種類にスリム化されています。

  • 共通脆弱性識別子
  • Center for Internet Security (CIS) ベンチマーク
  • セキュリティのベストプラクティス
  • 実行時の動作の分析

課金体系

課金体系として、エージェント評価という聞きなれない単語が使われていますね。
Amazon Inspector 料金
ちょっとわかりにくいですが、エージェント数 x 評価回数を示すようです。
FAQ:Q: Amazon Inspector の料金体系について教えてください。を見るとイメージし易いかもしれません。

ボリュームディスカウントにも言及されているので、たくさん利用する人は要チェックですね。

インストール手順

基本的な手順はPreview版とさほど変わりがありませんでした。
手順は、過去記事を参考にしてください。

実行手順

基本的な手順はPreview版とさほど変わりがありませんでした。
手順は、過去記事を参考にしてください。

ルールパッケージは選択可能な4種類を全て選択しました。
Inspector6.png

レポート機能

レポートの出力

スキャンが完了すると、レポートアイコンが表示されました。
Inspector8.png

クリックするとFinding ReportFull Reportが出力できるようです。
Inspector9.png

内容

全編英語です。
目次がないので、見出しを拾うと以下のようになっていました。
RHEL7.3環境で実行したので、対応していないCISベンチマークは掲載されていません。

Section 1: Executive Summary

ルールパッケージ毎の検知件数が記載されています。
report1.png

Section 2: What is Tested

利用されたルールパッケージの説明が記載されています。
スキャンした対象(Assessment Target)の条件設定が記載されています。
report2.png

report21.png

Section 3: Findings Summary

各ルールパッケージで検出された項目と緊急度が記載されています。
AWSコンソールでページ送りする必要がないのがいいですね。
report3.png
report31.png

Section 4: Findings Details

各ルールパッケージで検出された項目の対応方法が記載されています。
記載内容はAWSコンソールで表示されている内容と同じですが、一つ一つ開かなくて良いので見やすいかもしれません。
report4.png

Section 5: Passed Rules

Full Reportのみのセクションです。
クリアしたルールパッケージの内訳が全て掲載されています。
Amazon Inspectorは全てのCVEに対応している訳ではないので、検査時にチェックされたCVEを確認する上では有用でしょう。
report5.png

おわりに

脆弱性の対応状況を見える化することは、安全な運用の第一歩です。
今回のアップデートで、AWSコンソールを見なくても結果が分かるようになったのは良かったと思います。

一方で、以前検証した際に懸念した、継続的な脆弱性のハンドリングについては、課題を残したままのように思えます。
判断の履歴や対応しない(必要がないと判断された)脆弱性の管理をどのように行うかがカギだと言えるでしょう。

今日はここまでです。
お疲れ様でした。

続きを読む

Amazon Inspectorの導入

Amazon Inspectorを触る機会があったため、脆弱性診断におけるAmazon Inspectorの位置づけを軽く整理した上で、自分なりにその使い方をまとめました。

Amazon Inspectorとは?

Amazon InspectorとはAWSが提供する脆弱性診断を行うサービスで、エージェントを利用したプラットホーム診断のためのサービスです。EC2に対して実施するもので有料です。またEC2のみのため、他社クラウドのインスタンスやデータセンターにあるサーバには実行できません。

こうしたサービスが求められる背景(私見)

あくまで私見ですが、セキュリティへの取り組みにはまずは「リスクの可視化」が必要と言われてますが、これまではインフラ担当者という「人」に依存する形で、自分たちのサービスで利用しているサーバのOSやミドルウェアに脆弱性有無の可視化や対応が行われていることが多いように思います。

しかしAWSをはじめ、パブリッククラウドを利用したサービスではインフラ担当者がいないのは普通です。そうした背景を考えると、Amazon Inspectorのように自動にリスクが可視化されるようにすることは、今後は重要なことと考えています。

Amazon Inspectorと脆弱性診断サービスの違い

Amazon Inspectorと外部会社を利用した(よくある)脆弱性診断サービスには、以下のような違いがある。(もちろん脆弱性診断サービスにはいろいろあるため、これが全てではない)

Amazon Inspector 脆弱性診断サービス
診断の種類(トポロジー) 診断用エージェントを利用したホスト型診断 外部ネットワーク型診断など
診断の種類(レイヤー) プラットホーム診断(ネットワーク/OS/ミドルウェア) プラットホーム診断+Webアプリケーション診断など選択可能
実施者 プログラム(エージェント) セキュリティ診断の担当者
AWSへの事前申請 不要 必要

詳細はこちらを参照
http://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-amazon-inspector

そしてAmazon Inspectorでは以下のような項目とルールパッケージが用意されており、内容に沿ったテストが可能になっている。

項目 ルールパッケージ名 内容 注意点
共通脆弱性識別子 Common Vulnerabilities and Exposures EC2 インスタンス が一般的な脆弱性や曝露 (CVE) に曝露されているかを確認する
CIS オペレーティングシステムのセキュリティ設定ベンチマーク CIS Operating System Security Configuration Benchmarks アメリカにあるインターネット・セキュリティー・センター(CIS)が定義したセキュリティチェックリストに沿って確認する Amazon Linuxでのみ利用可能
セキュリティのベストプラクティス Security Best Practices システムが安全に設定されているかどうかを判断するのに利用する WindowsのEC2インスタンスでは結果が出ないので、LinuxのEC2インスタンスで利用すること。
実行時の動作の分析 Runtime Behavior Analysis 評価の実行中にインスタンスの動作を分析し、EC2 インスタンスのセキュリティを高めるためのガイダンスを提供する

詳細はこちらを参照
https://docs.aws.amazon.com/ja_jp/inspector/latest/userguide/inspector_rule-packages.html

費用の話

月250回までなら1台実行毎に$0.3かかる。

Amazon Inspector の利用開始から 90 日間 エージェント評価ごとの料金
最初の 250 回のエージェント評価 0.00 USD
任意の月 エージェント評価ごとの料金
最初の 250 回のエージェント評価 0.30 USD
次の 750 回のエージェント評価 0.25 USD

詳細はこちらを参照
https://aws.amazon.com/jp/inspector/pricing/

Amazon Inspectorの使い方

Inspectorの実施条件は以下の通り。RHELやCentOSの場合、6以下では利用できない。またWindows向け対応はまだβ版のため、正式には対応していない。

  • Amazon Linux (2015.03 以降)
  • Ubuntu (14.04 LTS)
  • Red Hat Enterprise Linux (7.2)
  • CentOS (7.2)
  • Windows Server 2008 R2 および Windows Server 2012(β版)

準備

IAMロールの作成

  1. AWS Webコンソール上のInspectorを開いて、「今すぐ始める」→「ロールの選択または作成」をクリック
    ロール作成

  2. IAMロール名”inspector”、ポリシー名「新しいロールポリシーの作成」を選び、右下の「許可」をクリック。

image.png

なおこのポリシーはec2 describe-instancesのアクションのみ許可するもの。またロール名は他の名前でも問題ない。

タグを付ける

Amazon Inspectorを実行するEC2インスタンスに対してタグを付ける。GUIから実施するか、以下のようにaws-cliを使ってタグをつける。

# テスト実行
aws ec2 create-tags --dry-run --resources i-XXXXXXXXXXXXX --tags Key=inspector,Value=True

# 本番実行(--dry-runなし)
aws ec2 create-tags --resources i-XXXXXXXXXXXXX --tags Key=inspector,Value=true
  • –resources の後にEC2インスタンスのリソースIDを指定します。
  • 上記例だと「Key: inspector, Value: true」というタグが設定される。

参考資料
https://docs.aws.amazon.com/ja_jp/inspector/latest/userguide/inspector_applications.html

エージェントのインストール

Amazon Inspectorを実行するEC2インスタンス上で、以下のようにコマンドを実行する

ファイルの入手

# installファイルの入手
wget https://d1wk0tztpsntt1.cloudfront.net/linux/latest/install
実行例
# wget https://d1wk0tztpsntt1.cloudfront.net/linux/latest/install
--2016-11-18 11:45:51--  https://d1wk0tztpsntt1.cloudfront.net/linux/latest/install
Resolving d1wk0tztpsntt1.cloudfront.net (d1wk0tztpsntt1.cloudfront.net)... 54.192.233.79, 54.192.233.106, 54.192.233.110, ...
Connecting to d1wk0tztpsntt1.cloudfront.net (d1wk0tztpsntt1.cloudfront.net)|54.192.233.79|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 23648 (23K)
Saving to: ‘install’

100%[==================================================================================>] 23,648      --.-K/s   in 0.002s

2016-11-18 11:45:51 (14.8 MB/s) - ‘install’ saved [23648/23648]

インストール

# installスクリプトを実行してエージェントをインストール
bash install
実行例(CentOS7.2利用)
# ls -ltr
total 24
-rw-r--r-- 1 root root 23648 Nov 16 23:59 install

# bash install
Distribution of the machine is CentOS Linux.
Distribution type of the machine is centos.
Revision of the distro is 7.
Kernel version of the machine is 3.10.0-327.13.1.el7.x86_64.
...
(略)
...
Installation script completed successfully.

Notice:
By installing the Amazon Inspector Agent, you agree that your use is subject to the terms of your existing
AWS Customer Agreement or other agreement with Amazon Web Services, Inc. or its affiliates governing your
use of AWS services. You may not install and use the Amazon Inspector Agent unless you have an account in
good standing with AWS.
*  *  *
Current running agent reports to arsenal endpoint:
Current running agent reports version as: 1.0.551.0
This install script was created to install agent version:1.0.551.0
In most cases, these version numbers should be the same.
#

セキュリティグループ確認(オプション)

EC2からAmazon Inspector および Amazon S3 サービス用のパブリックエンドポイントへのアウトバウンド許可されているか確認する。なお、インバウンドの許可は不要。

評価ターゲットを作る

どのタグがついているものをAmazon Inspectorの調査対象とするかを設定するために、評価ターゲットを作成します。ここでは「キー: inspector、値:True」となっているものをAmazon Inspectorの調査対象とするようにしてます。

項目 設定値
名前 任意の名称(下記では”inspector”)
キー Keyの値(下記では”inspector”)
Valueの値(下記では”True”)

image.png

評価テンプレートを作る

以下のようにして評価テンプレートを作成し、「作成および実行」でAmazon Inspectorが実行される。
なお評価テンプレートの修正はできない。削除&作成が必要となる。

項目 設定値
名前 任意の名称(下記では”inspector_templete”)
ターゲット名 先程作成したターゲット名を記載(本資料では”inspector”)
ルールパッケージ 前述のルールパッケージを選択(下記では”Security Best Practices-1.0″を選択)
所要時間 時間を選択。長ければ長いほど詳細のテストができるが推奨は1時間
SNSトピック 検出されたものをSNSに通知する場合は設定する(オプション)
タグ 必要に応じて設定(オプション)
結果に追加された属性 必要に応じて設定(オプション)

image.png

またaws-cliでAmazon Inspectorを実行する場合は以下のように行う

aws inspector start-assessment-run --assessment-run-name (評価テンプレート名) --assessment-template-arn (評価テンプレートのARN)
実行例
# aws inspector start-assessment-run --assessment-run-name inspector_templete --assessment-template-arn arn:aws:inspector:ap-northeast-1:XXXXXXXXXXXX:target/xxxxxxxx/template/xxxxxxxx

結果確認

実行開始すると、検出されたものから左ペインにある「評価の実行」内に出力される。検出件数をクリックすると以下のような画面が表示されるので、検出された内容や推奨事項を確認して対応を行う。
image.png

まとめ

Amazon Inspectorは、GUIでもaws-cliでもあっけないほど簡単に実行できました。
またaws-cliとcronやRundeckやjenkinsなどが利用して自動実行もできるため、有料サービスですが定期的に実行してリスクの可視化を行うとよさそうです。

資料

診断実行中のプロセスと負荷

診断実行中は以下のようなプロセスが起動してました。

root     14202  0.0  0.0      0     0 ?        S<   Nov17   0:00 [kworker/0:2H]
root     14203  0.0  0.0      0     0 ?        S<   Nov17   0:00 [kworker/0:0H]
root     21393  0.0  0.0      0     0 ?        S    10:40   0:00 [kworker/0:0]
root     21430  0.0  0.4 140788  5060 ?        Ss   10:42   0:00 sshd: root@pts/0
root     21434  0.0  0.2 115384  2112 pts/0    Ss   10:42   0:00 -bash
root     21994  0.0  0.0      0     0 ?        R    11:46   0:00 [kworker/0:1]
root     22054  0.0  2.9 470424 30116 ?        Ssl  11:46   0:01 /opt/aws/awsagent/bin/awsagent
root     22231  0.0  0.2 176024  2412 ?        S    12:03   0:00 /usr/sbin/CROND -n
root     22232  0.0  0.1 113120  1200 ?        Ss   12:03   0:00 /bin/bash -c /bin/sleep $[ ( $RANDOM % 3420 ) + 1 ]s; /opt/aws/awsagent/bin/update > /var/log/awsagent-update.log 2>&1
root     22233  0.0  0.0 107896   616 ?        S    12:03   0:00 /bin/sleep 3324s
root     22293  0.0  0.0      0     0 ?        S<   12:12   0:00 [inspector_task_]
root     22294  0.0  0.0      0     0 ?        S<   12:12   0:00 [inspector_libra]

CloudWatchで負荷をみたところ、インストール時のみ一瞬負荷があがりましたが、診断中はあまり負荷が上がりませんでした。
image.png

参考資料

http://dev.classmethod.jp/cloud/aws/aws-inspector/
http://dev.classmethod.jp/cloud/aws/blackbelt2016-inspector/
https://docs.aws.amazon.com/ja_jp/inspector/latest/userguide/inspector_introduction.html
https://docs.aws.amazon.com/ja_jp/inspector/latest/userguide/inspector_settingup.html

続きを読む

Security-JAWS#3 Integrate Vuls with OWASP Dependency Check. To enable automatic update of vuls config when the programming language libraries are update.

This slide was used in Security-JAWS 【第3回】2016年10月28日(金)
2016/10/28 @ Tokyo

vuls_logo.png


Who am I


Vulnerability Management on AWS

Amazon Inspector is awesome
_SEC324__NEW__Introducing_Amazon_Inspector.png

Inspector can scan only OS packages.
We need to manage vulnerabilities of programming language libraries.
Today, I talk about how to manage it automatically and the way to notify the scan report by slack or E-Mail in Japanese by using Vuls and OWASP Dependency Check.


Vuls (VULnerability Scanner)


What’s Vuls

vuls.png


Buzzed All Over The World

Star_history.png


Got First Place In GitHub Trending

2016/10/1 All Language
image002.png


Architecture

vuls-architecture.png


Features (日本語)

  • Scan for any vulnerabilities in Linux/FreeBSD Server

    • Supports Ubuntu, Debian, CentOS, Amazon Linux, RHEL, FreeBSD
    • Cloud, on-premise, Docker
  • Scan middleware that are not included in OS package management
    • Scan N/W Devices, middleware, programming language libraries and framework for vulnerability
    • Support software registered in CPE (日本語)
  • Agentless architecture
    • User is required to only setup one machine that is connected to other target servers via SSH
  • Nondestructive testing
  • Pre-authorization is not necessary before scanning on AWS
  • Email and Slack notification are both available. (supports Japanese language)
  • Scan result is viewable on accessory software, TUI Viewer terminal or Web UI (VulsRepo).

Usage: Scan vulnerabilities of non-OS packages

README , README日本語

[servers]

[servers.172-31-4-82]
host         = "172.31.4.82"
user        = "ec2-user"
keyPath     = "/home/username/.ssh/id_rsa"
cpeNames = [
  "cpe:/a:rubyonrails:ruby_on_rails:4.2.1",
]

Sample: NVD Vulnerability Database

  <entry id="CVE-2016-2098">
    <vuln:vulnerable-software-list>
      ...
      <vuln:product>cpe:/a:rubyonrails:ruby_on_rails:4.2.1</vuln:product>
      ...
    </vuln:vulnerable-software-list>
    <vuln:cve-id>CVE-2016-2098</vuln:cve-id>
    <vuln:cvss>
      <cvss:base_metrics>
        <cvss:score>7.5</cvss:score>
        <cvss:access-vector>NETWORK</cvss:access-vector>
        ...
    </vuln:cvss>
    ...
    <vuln:cwe id="CWE-20"/>
    <vuln:summary>Action Pack in Ruby on Rails before 3.2.22.2, 4.x before 4.1.14.2, and 4.2.x before 4.2.5.2 allows remote attackers to execute arbitrary Ruby code by leveraging an application's unrestricted use of the render method.</vuln:summary>
  </entry> 

How to find CPE names of libraries


OWASP Dependency Check

  • Dependency-Check is a utility that identifies project dependencies
  • checks if there are any known, publicly disclosed, vulnerabilities.
  • Currently Java and .NET are supported;
  • additional experimental support has been added for Ruby, Node.js, Python, and limited support for C/C++ build systems (autoconf and cmake).

組み込んだOSSコンポーネントの更新漏れを可視化する「OWASP_Dependency_Check」__2_5_:CodeZine(コードジン).png


OWASP Dependency Check Report


Integrate with OWASP Dependency Check

  • #232
  • Execute OWASP Dependency Check with --format=XML option.
  • Define the xml file path of dependency check in config.toml.
[servers.u16]
host     = "127.0.0.1"
port     = "22"
user     = "vuls"
keyPath  = "/path/to/.ssh/id_rsa"
dependencyCheckXMLPath = "/tmp/dependency-check-report.xml"

Demo


Benefit Of Integrating Vuls And OWASP Dependency Check

  • Automatic Update of Vuls config when the libraries are updated.
  • Reporting in Japanese
    • OWASP Dependency Check supports only English
  • Reporting by Email or Slack by using Vuls.

Tagging To EC2


What I’m planning to do next


Presentation (in Japan)


How To Catchup Vuls


We Are Hiring Hacker And Engineer!

If you are interested, please contact me ( Twitter: @kotakanbe )


Thanks

Give a GitHub Star if you are interested :)

続きを読む