Ansible Workshopのセキュリティ編を眺めてみた。
この記事は、Ansible Advent Calendar 2020 、13日目の記事です。
ここのところAnsibleに全く触れられていないので、手抜きで申し訳ないのですが、もくもく会コンテンツにもなりそうなAnsible Workshop のセキュリティ編を眺めてみた結果を書いていきます。
率直な感想としては、「これ、もくもく会で是非やってみたい」です。サーバ/NW混在・TowerのワークフローやRBAC、サービスのボタン化など、自動化2.0の要素が盛りだくさんでとても楽しそう。
ただ、完走するまでに3時間くらいはかかる気がしますね。
今回は読んでみるだけですが、似たような環境を自宅に作って試してみようと思います。
ベースとなる情報
Ansible Workshop セキュリティ編へのリンク
初めに謝辞
今回英語コンテンツを読んでみる覚悟で覗いてみたのですが、実はこのコンテンツ、完全に日本語化されておりました…
立役者のお二方(ひよこ大佐さん、せんさん)に最大級の感謝を…
- ベースとなる情報
- Section1: Ansible SecurityAutomation の基礎を紹介
- Section2: Ansible SecurityAutomation のユースケース
- 全体的な感想
Section1: Ansible SecurityAutomation の基礎を紹介
1.1 ラボ環境を確認してみよう
Workshopでおなじみの、環境面の紹介です。
ただ、他のコンテンツと比較して異色だな、と思ったのは、操作する対象がサーバのみ、NW機器のみ、という形ではなく、以下の種類をすべて組み合わせてAnsibleの操作対象としている点です。
- 疑似攻撃者の端末(SSHで操作)
- ファイアウォール（管理サーバ含む）(RESTで操作)
- WebサーバとSnort(IDS)を動かすターゲットサーバ(SSHで操作)
- SIEMであるIBM QRadar(RESTで操作)
複数種類のプロダクトを共通の制御手法でコントロールできる。やはり、これがAnsibleの強いところだなと思います。
そして、AnsibleコントロールノードではVSCodeエディタのオンライン版が用意されているとのこと。ブラウザだけあればもくもくできる、いい時代になりました…
1.2 最初のCheckPoint用のPlaybookを実行してみよう
ファイアウォールであるCheckPointをAnsibleで操作するためのPlaybookを実行します。
CheckPoint、業務ではもう1x年以上触ってないですね…
CheckPointに対して、今回のラボ実行に必要となる通信ポリシーを許可させるために、以下の3点を実施するPlaybookを実行します。
- 送信元/宛先のオブジェクトの作成
- 通信許可ポリシーの追加
- 作成したポリシーの実環境へのインストール
CheckPointManagerの確認にはSmartConsoleというツールを利用するのですが、それにはWindowsのワークステーションを使うとのこと。
よく読んでみると、RDPクライアントがない人のためにHTML版のRDPクライアントも用意されているようで。本当に至れり尽くせりです…
このWindowsワークステーションを使って、Playbook実行前後のCheckPointの状態を確認しています。
1.3 最初のSnort用のPlaybookを実行してみよう
侵入検知・防止システムであるSnortをAnsibleで操作するためのPlaybookを実行します。
最初にインベントリ情報から、SSHでSnortを動作させるホストに入り、状態確認をします。ここは手動なのですねｗ
Snortの設定ルールの紹介された後Playbookの話になるのですが、snort用のモジュールは無いそうで。
「だからモジュール作ったよ」とのこと。SASUGA。
ansible-galaxyを使ってsnort操作用のroleをインストールする手順が記載されていました。
その後、インストールしたroleにパラメータを渡してPlaybookを実行し、簡単なSnortルールをAnsible経由で設定しています。
設定実施後のSnort状態確認もroleで実行できるようで、ここでも至れり尽くせり感が半端ないです。
1.4 最初のIBM QRadar用Playbookを実行してみよう
一番最初の絵を眺めてた時に「商用SIEMプロダクトのIBM QRadarを使うんだろうなあ、これだと自宅で気軽に試すの無理だなあ…」と思っていたのですが、制限付きではあるものの、無償で使えるコミュニティ版を用いたハンズオンになっていました。
QRadar Community Edition - Tour QRadar - QRadar 101
Workshopの内容は、QRadarの画面の簡単な紹介から始まり、「Offenses」という機能の概念の説明がありました。
また、QRadar操作用のモジュールは標準では同梱されていないようで、「Ansible collections」からインストールを行う工程があります。
その後、collectionで導入されたモジュールを実行することで、QRadar用のルール現状確認、設定の追加をしています。
Section2: Ansible SecurityAutomation のユースケース
2.1 Investgation Enrichment
Section1で自動化の下ごしらえをした環境群に対し、実際の調査対応を行う演習です。
まず、「疑似攻撃者の端末から、定期的にWebサーバ上の特定URIへアクセスさせる」ためのPlaybookを、Tower経由で実行します。
次に、SnortとCheckPointからQRadarに対しログを転送するための設定を、すべてPlaybookで実行していきます。
その後、QRadarのWebUIから、ログ転送設定が行われていることを確認します。
ログ転送設定が確認出来たら、Snortに対して最初にTowerで仕込んだ、「特定のURIへのアクセス」を異常として検知し、ログを記録する設定を行います。
その後、定期的に来るアクセスをQRadarが拾えていることを確認したら、作業は終了で、環境のロールバックを行うPlaybookを実行します。
こういうロールバックなども一発で実施できるのが、IaCの素晴らしいところだなと思いますね。
その後、Tower経由で、定期的なWebサーバへのアクセスを停止させるPlaybookを実行してセクション終了になっていました。
補足
余談ですが、演習テキストの途中に、以下のような記載がありました。
典型的な状況では、新しいルールを実装するには、Snort を担当するセキュリティオペレータとさらにやりとりが必要になります。しかし、幸いなことに、私たちは再び Ansible Playbook を使用して、数時間や数日ではなく、数秒で同じ目標を達成することができるようになりました。
このへんが、自動化2.0で目指したいポイントですね。
2.2 Threat hunting
まずは、これまで通過させていたアクセスをCheckPointでDropするためのポリシー設定を、Ansible Tower経由で実行します。
次に、疑似攻撃者の端末から定期的にアクセスをさせるための設定を、これもAnsible Tower経由で実行します。
その後、CheckPointの管理サーバで、実際に定期的に発生したトラフィックがDropされていることを確認します。
このCheckPointのDropログの確認が、QRadarなしで単独で管理している、セキュリティ担当さんのお仕事、というような前提で語られています。
統合的にセキュリティイベントを管理できる環境を作るために、Ansible TowerのRBACを活用して以下のような設定を行っています。
- QRadarへのログ転送設定追加
- CheckPointからのログ転送設定の追加
- Snortへのルール追加と、ログ転送設定の追加
その後、QRadarでCheckPointとSnortのログを横断で確認することで、「Snortで検知されていないのにCheckPointでDropになっている＝過剰検知である」ということを確認し、接続許可をAnsible Tower経由で追加する、というようなシナリオになっていました。
最後に、2.1同様、ロールバックを行っています。
2.3 Incident response
最後の項目では、SQLインジェクション攻撃が発生した場合のインシデントレスポンスを実践します。
まず、Snortに対し、所定のアクセスをSQLインジェクションと認識させるための設定をAnsibleで追加します。
次に、疑似攻撃者の端末から定期的にSQLインジェクションを模したアクセスをさせるための設定を、これもAnsible Tower経由で実行します。
Snortのホストに入り、実際にSQLインジェクションを検知していることを確認します。
その後、QRadarにログを転送するPlaybookを実行し、QRadar側にログが転送されていることを確認します。
QRadarで攻撃を検知出来たら、その情報をもとに送信元IPを特定し、CheckPointで特定IPからのアクセスをDropさせる設定を追加するPlaybookを実行し、トラフィックをDropさせます。
最後に、これまで同様、環境のロールバックを行っています。
全体的な感想
Section2のユースケースにあるように、複数のプラットフォームに対してAnsibleという統一された手段でコントロールできることは、非常に重要だなと実感できました。
実際には、このあたりのSnortでの検知→CheckPointへのブラックリスト登録などまで含めてすべて連動させ自動実行させることで、より運用に手間がかからなくなる、ということも可能だと思います。
自身の業務としてセキュリティ系のお仕事をしてますが、ここで指摘されてるようにそれぞれがバラバラ見たいな動きをしているので、耳が痛いところです。
実業務環境ではなかなか改善の機会に恵まれませんが、その時が来たらいつでも対応できるように、Ansibleの学習を続けていきたいと思います。
