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が必要だが不要になった

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の合同開催とのことです。