Security-JAWS第6回レポート #secjaws #secjaws06

8月24日にSecurity-JAWS 第6回が開催されました。
参加レポートをご紹介します。

Session1:クラスメソッド株式会社 佐々木 大輔「ざっくりわかるAmazon Macie」

内容

佐々木のブログをご覧ください。

Session2:NRIセキュアテクノロジーズ株式会社 大島 修さん「AWSで実践するリスト型アカウントハッキング対策」

内容

• アカウントハッキングの被害事例をみると、攻撃者は金銭目的であることが多い

種類

• ブルートフォース攻撃
• リバース型ブルートフォース攻撃
• ジョーアカウント攻撃
• リスト型攻撃
  • 流出したID,パスワードを使う。IDやパスワードの使い回しをしていると危険
• 類推攻撃
  • 個人の社会背景を使う
• なりすまし

リスト型攻撃

• リスト型攻撃の元になるID情報漏洩は常時どこかで発生
• リスト型アカウントハッキングの典型的な攻撃シナリオ
  • リスト試行
  • 不正発覚防止
    • 連絡先の変更などにより、不正発覚を防止される
  • 不正取引実行
  • 証拠隠滅

アカウントハッキングは多層で防御

• ブルートフォース攻撃：WAF、不正検知ツール
• リバース型ブルートフォース攻撃：WAF、不正検知ツール
• ジョーアカウント攻撃：WAF、不正検知ツール
• リスト型攻撃：WAF、不正検知ツール
• 類推攻撃：不正検知ツール
• なりすまし：不正検知ツール

AWS WAFでの防御

• レートミリット設定
  • 5分あたり2000アクセスが設定上の最小値
• AWS WAF + Lambdaによる高頻度アクセスIPのブロック
  • CloudFrontやELBログをLambdaに食わせて、WAFのブラックリストに追加
  • AWSのGithubにLambdaのコードがあるので参考にできる

アクセス頻度を基準とした防御の限界

• 攻撃者は閾値をにかからない頻度でアクセスしてくる。閾値を探ってくる。
• ボットネットを活用して、分散IPで攻撃してくると対応しにくい

不正検知ツールによる防御

• 複合コンテキストによるリスク分析
  • 端末属性、ネットワーク属性、ページ遷移属性、地理属性、利用時間特性、サービス利用属性など
• 不正検知ツールによる防御
  • NRIセキュアテクノロジーズでは、Uni-ID Identity Fraud Detectionを扱っている

まとめ

• AWS WAFのレートリミットはすぐに導入すると良い
• 金品やポイント扱ってる場合、コンテキスト分析によるリスク検知の導入を検討
• 多要素認証は協力だが、ユーザービリティを落とさないように高リスク時にのみ有効化

Session3:F5ネットワークスジャパン株式会社 牧田 延大さん「BIG-IPをVPCエンドポイント的に使ってみた」

スライド

内容

セキュアなS3アクセス

• VPC PrivateサブネットからのS3アクセスをセキュアに行う方法を考えて見た
  • 1.NAT、IGWを噛ませてインターネットに抜ける
  • 2.VPCエンドポイント
  • 3.BIG-IP使って何かできそう
    • NATインスタンスの代わり
    • HTTP→HTTPS変換できる
    • IAMでのアクセス制御も可能

BIG-IPを使ったバリエーション

• BIG-IPをS3アクセスのプロキシとして配置
  • スキーム変更：HTTP（Private）→ HTTPS（Public）
  • S3エンドポイントのヘルスチェック
  • アクセス先URL書き換え（ホスト+パス）とトラフィック転送
    • iRulesを利用
  • HTTPレスポンスからセンシティブな情報をサニタイズ
  • IAMユーザによるpre-signed URL発行と代理S3アクセス
    • iRules LXを利用
• iRules LX
  • iRulesのHTTPリクエストハンドラで呼び出し
  • IAMユーザーを使ってpre-signed URLを発行
    • nodejsを利用

通信フロー

• EC2がHTTPアクセス
• BIG-IPが受け取ると、IAMユーザーでpre-signed URLを発行する
• BIG-IPが URLを上記URLを受け取る
• HTTPをHTTPSに変換
• HTTPSで期限付きURLでアクセスする

さらにBIG-IPでできること

• コンテンツキャッシュ
• インターネット側TCPコネクション多重化
• WAF

デモ

• Amazon LinuxからBIG-IPを経由して、curlでS3にアクセス
  • 通常時：4〜5 MB/s
  • キャッシュ有効化時：30MB/s

まとめ

• BIG-IPはNATインスタンス兼、VPCエンドポイント的兼、CloudFrontとして使える
• アップデート
  • サービスディスカバリエンハンス
    • Auto Scalingするインスタンスの保護では、ELBが必要だが不要になった

CFTはこちらから。#secjaws #secjaws06https://t.co/H5p0X0xBgC

— Nobuhiro Makita (@nobuhiromakita) 2017年8月24日

Session4:アマゾン ウェブ サービス ジャパン株式会社 酒徳 知明さん「DevSecOps in AWS Multi-Account」

スライド

内容

マルチアカウントにする主な理由

• ガバナンス
  • セキュリティ及びガバナンス上の理由から、開発/テスト/本番で分けたい
• 課金
• 組織
  • 業務ユニットに移譲したい
• 運用
  • 構成変更時の影響を小さくしたい
• とりあえずAWSアカウントを分けているが、継続的に管理できているケースは少ない

マルチアカウントの前に、IAMの機能について抑えておく必要がある

• IAMのロールの機能を使って、セキュリティ負荷を小さくできる。
  • IAMユーザーはあまり作りすぎない方がいい
  • 10アカウントに10のユーザーを作ることは避ける
  • 複数のアクセスキー、シークレットキーがあるとローテーションが難しい
• IAMロール利用の例
  • アカウントA
    • アカウントBに対する操作を行う場合、アカウントBにロールをかりに行くことで、一時的なクレデンシャル（テンポラリなキー）を発行される。
  • アカウントB
    • アカウントBでクレデンシャルを作る必要はなくなる

Overview of BaseLine

• 管理用のアカウントとターゲットアカウントがある
• ターゲットアカウント
  • IAM Role（Assume Role）、CloudTrail、Configなどを設定しておく
  • 上記をCloudFormationで展開する
• 管理用アカウント
  • ターゲットアカウントでCloudTrailがOFFになった時に、SNSで管理用アカウントのAPI Gatewayに通知

CloudFormationのターゲットアカウントへの配布

• Step Functionでやっていたが、いきなり使うのは難しかった。今はCloudFormationのStack Setを使うと良い
• Stack Setsを使うことで、1つのテンプレートを複数のアカウントに配布できる
  • CloudTrailを有効化するテンプレートなど、選べる。デプロイするリージョンの選択、アカウントIDの指定、オーガナイゼーションの指定が可能
  • 管理用アカウントからターゲットアカウントへのCloudFormationの配布が非常に簡単になった

QA

• Q. Stack Setでターゲットアカウントに配布するにはどうするのか
  • A. ターゲットアカウントにIAMロールを作成しておく。手動で作成するのは面倒だが、CloudWatch Eventとオーガナイゼーションを使えば自動化できるはず。
• Q. 特定のターゲットアカウントだけ異なる設定にしたいケースではどのように対応するのか
  • A. Update Stackすれば同じ設定になる。今の時点では、オーガナイゼーションで分けて対応する形が良さそう。

Session5:株式会社ラック 関 宏介さん「AWS環境におけるフォレンジック」

内容

AWSインシデント事例1

• 発覚経緯：数10TBの通信が発生し、請求された料金をみて気がづいた
• 侵入被害：DDoS Bot、Webシェル、RAT、ハックツール
• 侵入原因：Tomcatの管理画面が公開されており、パスワードの推測が容易な状態

AWSインシデント事例2

• 発覚経緯：AmazonのAbuseからDDoSの攻撃になっていると指摘
• 侵入被害：DDoS Bot
• 侵入原因：古いバージョンのソフト、FWでポートが空いていた、デフォルトパスワード、ソースからインストールしており管理者権限で動いていた
  • 社内の古いシステム検証用だった

AWSインシデント事例3

• 発覚経緯：サービスが原因不明の停止、負荷増大
• 侵入被害：Bitcoin Miner
• 侵入原因：古いバージョンのソフトウェア

AWSのインシデント傾向

• SSHの不正ログインは少ない
  • AWSのデフォルト設定がセキュア
• 検証用のサーバの被害が多い
  • 気軽に立ち上げやすい
• 意図しない公開ポートからの被害
  • オンプレに比べてFWによる制御がされにくい

フォレンジックとは

• 和訳すると、法科学、科学捜査
• フォレンジック技術を使う利点
  • 削除済みエリアから痕跡が見るかる可能性
  • Rootkitの影響を受けずにマルウェアを検知
  • OS上からのは見えない情報が調査可能
  • メモリも取得できれば当時の状況を再現可能

フォレンジックの限界

• 削除済みエリアは使用されるたび上書きされる
  • ローテションや攻撃者により削除されたログ
• ユーザー操作の全てが追跡できるわけでは無い
  • 更新時刻は最終更新時刻
  • ディスクやメモちに残っていない痕跡は追えない
• 復旧の最善策はOSの再インストール

復旧時の注意事項

• バックアップから戻す際に、Webシェルやバックドアとして動くコードを戻してしまう可能性がある
  • クローズドなステージング環境から戻す形をおすすめ
  • Web Sellの特定は困難。難読化されてしまうことがある。

ディスクのフォレンジックのためには

• オンプレミスでは、ハードディスクのイメージコピーを取得
  • AWSでは、フォレンジック用のハードウェアができない
    • ソフトウェアによるイメージコピー
• AWSでのフォレンジック手法
  • インシデントを検知したらスナップショットをとる
  • スナップショットからボリュームを作成
    • AZを調査インスタンスに合わせるように注意
  • 作成したボリュームを調査用インスタンスにアタッチ
  • イメージコピー（ddなど）
    • S3経由などで手元にダウンロード
• SSHを使ったLiveイメージング
  • PermitRootLogin no、かつsudoできる場合
    • ssh -C 一般ユーザー@対象ホスト "sudo dd bs=512" conv=noerror,sysnc if=/dev/xvda > xvda-img.dd
    • 圧縮転送が効くため、CPU負荷はかかるが転送効率は良い

フリーのフォレンジックツール

• FTK Imager
• SleuthKit
• Autopsy
• Log2timeline

まとめ

• 検証用でもアクセス制御不備に注意
• やられたらすぐにスナップショット

さいごに

Security-JAWS 第6回のレポートをお届けしました。
次回は、NW JAWSとSecurity-JAWSの合同開催とのことです。