builderscon 2019-08-31(2日目) アウトラインメモ
builderscon 2019-08-31(2日目)に参加したのでアウトラインメモ
スーパーカミオカンデの開発と運用
- ニュートリノすごい
入門サービスメッシュ
- Tetrate | Enterprise ready service mesh
- サービスメッシュなるまでの変遷
- Service Mesh Before Container
- サービスメッシュはk8sとかより前にもあった
- 運用する規模が大きくなりすぎて
- 1000人とか1万人とか
- そうするともう少し小さく割ったシステムにしたほうが良いのでは ⇒ Microserviceが大きな規模のところでは主流になってきた
- 素早くサービスを展開する必要がでてきて既存のものだと足りなくなってきた
- Containerとか使われるようになってきた
- 規模が大きくなるとネットワークもそれ向けに
- Observabilityという概念もできて
- 未知の問題や障害をモニタリングして、解決する概念
- 既存のモニタリングは既知の問題に対する対処
- Microserviceだと今までは失敗しなかった関数呼び出しみたいなものが、ネットワークを経由するようになり失敗することがでてきた
- タイムアウトや問題の監視する必要がでてきた
- サービス(チーム)に対するアクセスコントロールなどの認可などが必要になった
- Finagleなどのライブラリアプローチが色々増えた
- ライブラリアプローチには、いくつか問題があった
- 言語ごとに実装が必要になるという問題
- JavaとかRubyとか言語ごとにライブラリが必要
- 言語間の一貫性を保つのが大変
- ライブラリのアップグレードコストが高い
- コミュニケーションコスト
- プロセスの切り替え
- 色々ライブラリなアプローチがあって、サービスメッシュ的なアプローチがでてきた
- Linkerdでサービスメッシュという言葉が初めてでてきた
- linkerd.io
- envoyproxy.io
- istio.io
- サービスメッシュ的なアプローチ
- サービスとサービス間のルーティングをするアプローチ
- 今までのライブラリは、アクセスするサーバ側に入っていてルーティングするようなアプローチだった
- プロキシプロセスを作ってそこを経由するようになった
- SmartStack
- Nerve(接続先 zookeeper)とSynapse(HAProxy) みたいなアプローチ
- SmartStack
- Prana - Netflix
- いろんなパッケージをまとめたやつ
- Sidecarという言葉でてきた
- サービスメッシュのコンセプト
- ルーティング以外もやる
- タイムアウトとかアプリケーションがやってたこともやる
- サービス側からはプロキシにリクエストを投げるだけ
- プロキシで認証とか色々やってくれる
- 開発者はあんまり気にしなくて良くなる
- 世の中の実装
- Envoyはただのプロキシーの実装
- Envoyを管理するControl Planeが色々ある
- 自作 ← ある程度規模がデカイ所なので独自のカスタマイズが必要だったりするため
- istio
- App Meshとかのマネージド
- Consul
- Linkerd v2
- Control Plane
- Nginx Basedなどもある
- ユースケース Yelp
- SmartStackを使ってた
- ZooKeeper + HAProxy
- もともとHAProxyを使ってた
- HAProxyはいいやつだけど欠点もあった
- メトリクスが少ない
- タイムアウトなどの制御
- HAProxyをEnvoyに置き換えた
- MeshedがZooKeeperから設定をとってきて、Envoyに渡して上げる
- ⇒ サービスメッシュを小さく入れていく事例
- SmartStackを使ってた
- ユースケース 2
- EnvoyをVMとコンテナで動かす
- コンテナとVMを一括管理
- VMからコンテナベースにマイグレーションする際に利用できる
- ⇒ トラフィック部分をサービスメッシュで管理して移行しやすくする
- ユースケース 3 メルカリの事例
- istioを段階的に適応する
- いろんな機能があり学習コストや移行コストが高い
- ⇒ istioは機能ごとに有効化できるようになってる
- トラフィックコントロールだけを有効にするとか
- Adopting Istio for a multi-tenant kubernetes cluster in Production
- サービスメッシュの選び方
- 規模を見る
- 大規模になるなら開発、運用の分散化が重要になる
- 小さいならコミュニケーションで解決することが多い
- サービスを動かしてる環境
- 比較的にモダンな環境ならOSS実装とかがフィットしやすい
- 歴史あるレガシーな環境ならカスタマイズが必要になる
- 規模を見る
- サービスメッシュはアーリーフェーズ
- 自分の状態をちゃんと見て選ぶ
- k8sとかじゃなくてサービスメッシュは使える
- VMとコンテナのハイブリット構成、マルチクラウド構成などはまだちゃんと対応してないものも多い
- Q&A
- Q. Envoyにタイムアウトを移譲するという話だけど、クライアント側では実装しない?
- A. Envoyが落ちてる場合はアプリケーションのPodも落ちているという前提。なのであんまりその状態は想定しない
- Sidecarパターンは同じPodにいるという前提のパターン
もしもハッカーの「サイバー攻撃日誌」が読めたら
- ペネトレーションテスト
- ある日のミッション:
- 日替わりパスコードでしか入れない部屋にはいる
- ある日のミッション:
- Red Teamサービス
- Red Teamとは
- サイバー攻撃シミュレーションサービス
- 組織のインシデント対応力を調査する仕事
- サイバー攻撃に備えたい企業や組織などがお客
- 対策したいけど、実際に大丈夫かをチェックする
- 特徴: ゴール設定
- 管理者権限奪取
- 物理侵入など
- 特徴: 事前通知なし
- 実際に通知してから攻撃してくる人はいないので
- 特徴: 攻撃対象は組織全体
- ITシステムだけじゃなくて、みえるものは全部攻撃対象
- 組織、人、システム、建物なども対象
- 社員証を偽装して入ってたりとか
- セキュリティ診断との比較
- 対象: 特定のシステムだけじゃなくて、組織全体のセキュリティを見る
- 目的: それに検知から対応までできるかを見ていく
- Red Teamとは
- ケーススタディ
-
架空の企業: 株式会社シナノ
-
オンラインショッピングサイト SHINANOを狙う
-
システム構成: Active Directory → 踏み台 → システム
-
攻撃目標: 主力サービス SINANO
- 端末へのマルウェア感染
- AD端末の感染
- システムを乗っ取り
- 個人情報を抜く
-
シナリオ
- OD訪問メールから端末のウイルス
- 添付ファイルからマルウェア感染
- 境界突破
- Perimeter Breach
- Excel の VBAマクロ
- 境界突破
- 感染してC2
- 攻撃者からコマンド実行してその結果をカエル
- C2プロセスは再起動してら消えてしまう
- 自動起動設定(Persitence)をする
- レジストリキーとかサービスとか使って
- この状態で情報収集する
- 添付ファイルからマルウェア感染
- OD訪問メールから端末のウイルス
-
権限昇格
- SYSTEM権限で動作するサービスの脆弱性を使う
- Everyone、Full controlとかをついてるexeを探す
- exeを置き換えて、管理者権限で起動させる
- SYSTEM権限で動作するサービスの脆弱性を使う
-
ローカルのパスワードハッシュの取得
- ローカル管理アカウント
pcadmin
みたいなアカウントを探す- Mimilatz lsadumpなどでローカルアカウントのハッシュをダンプする
- ハッシュをクラックするパスワードを取得する
- 大体共有アカウントなので
- ローカル管理アカウント
-
IT管理者を探す
- 既存情報から、管理者っぽいところを探す
- 横断的侵害(Lateral Movement)
- 横に移動する感じで侵入をする
- WMIにリモートコマンドを実行できる
- 他のアカウントの管理アカウントで入ってコマンドを実行する
-
Mimikatz
- メモリ上のメモリ認証情報を取得する
- メモリ上のデータ見るので、管理者権限がいる
- これでADの管理者パスワードを取る
-
HTTPからTCP Tunnelを貼る
- SSH Reverse TCP Tunnelを使って、Remote Desktopでつながるようになる
-
ADサーバからアカウント一覧を取る
- パスワードのハッシュ取れる
- 弱いパスワードは簡単に取れる
-
WebMailとかにログインして、SHINANOサービスについて調べる
- 開発ドキュメントとかを見て、実際にサービスにつながる端末を見る
- ⇒ 第二サービスの端末に行く
-
踏み台サーバへのログインする
- ユーザー
- パスワード
- 二要素認証
「二要素認証めっちゃいいです」 「攻撃していく過程でユーザー名とかパスワードはだいたい取られる」 「二要素認証がでてくるとRedTeamで作戦会議します」
-
二要素認証の攻撃アプローチ
- 業務端末でログインするはずなので、そのセッションでログインする
- 二要素認証自体はユーザーに任せる。二要素認証自体は突破しない
-
ログインして放置されている端末を狙って使う
- ランチいっているときにログイン済みセッションを使う
- SSH鍵とかを取る
-
踏み台に入ってbash historyとか取る
- MySQLとかに入ってデータを取る
-
- 攻撃者視点での振り返り
- フィッシングメールの開封
- これは数打てば当たる
- 端末における権限昇格の脆弱性
- 全端末共通の管理者パスワード
- ネットワークアクセスの制御
- 端末間の移動ができてしまう
- Webメールにおける二要素認証の未導入
- 検知・監視機能が機能してない
- 外部通信
- データベースの不正ログイン
- ⇒ 色々不十分なところを報告する
- フィッシングメールの開封
- Red Teamサービス結果報告書
- 侵入までやった結果や推奨対策を報告する
- 個人で体験するには
- 分析のフレームワーク
- 攻撃側のフレームワーク
- サイバーキルチェイン
- 事前冗長さ
- 境界突破
- 持続性アクセス
- 権限昇格
- 横断的侵入
- サイバーキルチェイン
- 防御側のフレームワーク
- CSF
- 特定、防御、検知、対応、復旧のプラクティス
- CSC
- CSF
- 共通言語
- ATT&CK Framework
- サイバー攻撃で利用される技術要素を体系的に分類、整理
- Access Token Manipulation
- 「わざわざそこまでやるやつは起きないだろう」って言うたびに、わざわざそこまでやるやつがでてくる
- 攻撃側のフレームワーク
- Q. SSHのセッションのやつは毎回ログインパスワード入力とかしたほうがいいのか?
- A. キーロガーを入れるとかいろんな攻撃があるので銀の弾丸はない。ちゃんと検知できる
- Q. デカイ規模(ADとかがしっかりある)と小さい規模(クラウドとかのみみたいな)の場合どちらかやりやすい
- A. 小さいほうが成長優先になっていて、やりやすい
- インシデントが起きてからじゃなくて、起きる前に契約しておいたほうが、実際に起きたときに反応が早い
- 起きてから探すと時間がかかる
- Q. マクロで仕込むときにウイルス対策ソフトとかが反応する?
- A. あるけど、txtを吐いてdecodeして実行してる
- Q. 中間者攻撃?
- A. 証明書とかの問題があるのでMITMとかが結構めんどい。
- Q. 事前にRedTeamに与えられる情報ってどれぐらい?
- A. クライアントによる。目標設定に依存して聞く
- Q. クラウドサービスの通信が色々あるので、検知が難しい
- A. https://aws.amazon.com/jp/guardduty/ とか
- Q. 不正な通信を通信量とかで検知できる?
- A. 通信量では検知しにく
- Q. リモートワークが増えているけど良い対策ありますか?
- A. 難しい問題
- Q. 今回はWIndowsだけど、macだとどういう攻撃になる?
- A. macの環境。AD連携とかあるといいけど、疎結合な場合が多いのでWindowsより大変なことがある。
- Q. 実際にRedTeamでゴールに行ける率はどれぐらい?
- A. ゴールの達成にこだわる必要はないけど、過去の経験はほぼ達成している。
- Q. 最初の攻撃がMailだったけど、他の入り口はどういう検知していけばいいのか?
- A. 難しい。
- Q. 日々どうやって勉強してる
- A. いい方法がアレば知りたい。カンファレンスとかSNSとかトレーリング
- この脆弱性いいよねとか話すことがある
- Q. 0dayを使うことはある?
- A. たまにあるけど、もうちょっと普通の方法で入る
- Q. 攻撃していてやりづらかったケース?
- A. 二要素認証、情報共有が早い会社は結構難しいこと
- Q. 期間が数ヶ月とかかかってるのは? ゆっくりやるため?
- A. 毎回試行錯誤とかして数ヶ月みたいな感じ
- Q. やる範囲はどう決める
- A. 最初の契約で決める、そこを守る必要がある
お知らせ欄
JavaScript Primerの書籍版がAmazonで購入できます。
JavaScriptに関する最新情報は週一でJSer.infoを更新しています。
GitHub Sponsorsでの支援を募集しています。