Red Hat Ansible セキュリティー自動化ガイド
このガイドでは、Ansible を使用してセキュリティーイベントを特定、トリアージ、および対応するために必要なさまざまなセキュリティープロセスを自動化および合理化する手順を説明します。
概要
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ を参照してください。
第1章 Ansible セキュリティー自動化によるファイアウォールポリシー管理
セキュリティー Operator では、Ansible セキュリティー自動化を使用して複数のファイアウォールポリシーを管理できます。ファイアウォールルールを作成して削除し、宛先 IP アドレスへのアクセスからソース IP アドレスをブロックまたはブロック解除します。
1.1. ファイアウォールポリシー管理について
組織のネットワークファイアウォールは、攻撃に対する防害となる最初の行と、セキュアな環境を維持するための重要なコンポーネントです。セキュリティーオペレーターは、セキュアなネットワークを構築し、管理して、ファイアウォールが組織のファイアウォールポリシーで定義した受信および送信ネットワークトラフィックのみを許可するようにします。ファイアウォールポリシーは、ネットワークを有害な受信トラフィックおよび送信トラフィックに対して保護するセキュリティールールで設定されます。
さまざまな製品やベンダー全体で複数のファイアウォールルールを管理することは、セキュリティーチームにとって困難であり、時間がかかる可能性があります。複雑なタスクに関連する手動のワークフロープロセスにより、エラーが発生し、最終的にはアプリケーションの疑わしい動作を調査したり、サーバー上の継続的な攻撃を中止したりすることが可能になります。セキュリティーポートフォリオのすべてのソリューションが同じ言語で自動化されると、セキュリティーアナリストとオペレーターの両方が、さまざまな製品に対して一連のアクションを短時間で実行できます。この自動化プロセスは、セキュリティーチームの全体的な効率を最大化します。
Ansible のセキュリティー自動化は、さまざまなベンダーのさまざまなセキュリティーテクノロジーと相互作用します。Ansible を使用すると、セキュリティーチームは、デプロイメントを正常に実行するための統一された方法で異なる製品、インターフェイス、およびワークフローを管理できます。たとえば、セキュリティーチームは、エンタープライズファイアウォールなどのサポートされているテクノロジーで IP と URL のブロックとブロック解除などのタスクを自動化できます。
1.2. ファイアウォールルールの自動化
Ansible セキュリティー自動化により、さまざまな製品全体で一連のアクションを必要とするさまざまなファイアウォールポリシーを自動化できます。acl_manager ロールなどの Ansible ロールを使用して、IP または URL のブロックやブロック解除などの多くのファイアウォールデバイスについてアクセス制御リスト (ACL) を管理できます。ロールを使用すると、既知のファイル構造に基づいて、関連する変数、ファイル、タスク、ハンドラー、およびその他の Ansible アーティファクトを自動的に読み込みます。ロールでコンテンツを分類した後に、簡単に再利用し、他のユーザーと共有できます。
以下のラボ環境は、実際のエンタープライズセキュリティーアーキテクチャーの簡素化された例です。ここでは、複雑で、追加のベンダー固有のツールが含まれます。これは、侵入アラートを受信し、攻撃者の IP アドレスをブロックする acl_manger ロールを使用して Playbook をすぐに実行する典型的なインシデント対応シナリオです。
チーム全体で Ansible セキュリティー自動化を使用して、調査、脅威ハンティング、インシデント対応をすべて 1 つのプラットフォームで行うことができます。Red Hat Ansible Automation Platform は、セキュリティーチーム内で使用および再利用を容易にする認定コンテンツコレクションを提供します。
関連情報
Ansible ロールの詳細は、docs.ansible.com の ロール を参照してください。
1.2.1. 新しいファイアウォールルールの作成
acl_manager ロールを使用して、宛先 IP アドレスへのアクセスからソース IP アドレスをブロックする新しいファイアウォールルールを作成します。
前提条件
- Ansible 2.9 以降がインストールされている。
- 新規ポリシーを適用する Check Point Management サーバーへのアクセスがある。
手順
ansible-galaxy コマンドを使用して acl_manager ロールをインストールします。
$ ansible-galaxy install ansible_security.acl_manager
新しい Playbook を作成し、以下のパラメーターを設定します。たとえば、送信元オブジェクト、宛先オブジェクト、2 つのオブジェクト間のアクセスルール、および管理している実際のファイアウォール (Check Point など) です。
- name: block IP address hosts: checkpoint connection: httpapi tasks: - include_role: name: acl_manager tasks_from: block_ip vars: source_ip: 172.17.13.98 destination_ip: 192.168.0.10 ansible_network_os: checkpointPlaybook を実行します (
$ ansible-navigator run --ee false <playbook.yml>)。
検証
宛先 IP アドレスへのアクセスからソース IP アドレスをブロックする新しいファイアウォールルールを作成しました。MGMT サーバーにアクセスし、新しいセキュリティーポリシーが作成されていることを確認します。
関連情報
ロールのインストールに関する詳細は、Galaxy からのロールのインストール を参照してください。
1.2.2. ファイアウォールルールの削除
acl_manager ロールを使用してセキュリティールールを削除します。
前提条件
- Ansible 2.9 以降がインストールされている。
- 新しいポリシーを適用するファイアウォール MGMT サーバーへのアクセスがある。
手順
ansible-galaxy コマンドを使用して acl_manager ロールをインストールします。
$ ansible-galaxy install ansible_security.acl_manager
CLI を使用して、acl_manger ロールで新規 Playbook を作成し、パラメーター (例: ソースオブジェクト、宛先オブジェクト、2 つのオブジェクト間のアクセスルール) を設定します。
- name: delete block list entry hosts: checkpoint connection: httpapi - include_role: name: acl_manager Tasks_from: unblock_ip vars: source_ip: 192.168.0.10 destination_ip: 192.168.0.11 ansible_network_os: checkpointPlaybook を実行します ($ ansible-navigator run --ee false <playbook.yml>)
検証
ファイアウォールルールが削除されました。MGMT サーバーにアクセスし、新しいセキュリティーポリシーが削除されていることを確認します。
関連情報
ロールのインストールに関する詳細は、Galaxy からのロールのインストール を参照してください。
第2章 Ansible を使用したネットワーク不正侵入および防止システム (IDPS) の自動化
Ansible を使用してネットワーク不正侵入および防止システム (IDPS) を自動化できます。本書の目的上、Snort を IDPS として使用します。Ansible 自動化ハブを使用して、タスク、ロール、モジュールなどのコンテンツコレクションを使用して自動ワークフローを作成します。
2.1. 要件および前提条件
Ansible で IDPS の自動化を開始する前に、IDPS を正常に管理するために必要なインストールと設定が正しく行われていることを確認します。
- Ansible 2.9 以降がインストールされている。
- SSH 接続およびキーが設定されている。
- IDPS ソフトウェア (Snort) がインストールされ、設定されている。
- 新しいポリシーを適用する IDPS サーバー (Snort) にアクセスできる。
2.1.1. IDPS インストールの検証
関連情報
Snort が正常に設定されたことを確認するには、sudo 経由で呼び出して、バージョンを確認します。
$ sudo snort --version
,,_ -*> Snort! <*-
o" )~ Version 2.9.13 GRE (Build 15013)
"" By Martin Roesch & The Snort Team: http://www.snort.org/contact#team
Copyright (C) 2014-2019 Cisco and/or its affiliates. All rights reserved.
Copyright (C) 1998-2013 Sourcefire, Inc., et al.
Using libpcap version 1.5.3
Using PCRE version: 8.32 2012-11-30
Using ZLIB version: 1.2.7
サービスが sudo systemctl 経由でアクティブに実行されていることを確認します。
$ sudo systemctl status snort
● snort.service - Snort service
Loaded: loaded (/etc/systemd/system/snort.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2019-08-26 17:06:10 UTC; 1s ago
Main PID: 17217 (snort)
CGroup: /system.slice/snort.service
└─17217 /usr/sbin/snort -u root -g root -c /etc/snort/snort.conf -i eth0 -p -R 1 --pid-path=/var/run/snort --no-interface-pidfile --nolock-pidfile
[...]
Snort サービスの実行がアクティブでない場合は、systemctl restart snort で再起動し、ステータスを再度確認します。
サービスがアクティブに実行されていることを確認したら、CTRL と D を同時に押すか、コマンドラインで exit と入力して Snort サーバーを終了します。以降の操作はすべて、Ansible コントロールホストから Ansible を介して行われます。
2.2. Ansible を使用した IDPS ルールの自動化
IDPS を自動化するには、ids_rule ロールを使用して Snort ルールを作成および変更します。Snort はルールベースの言語を使用しており、ネットワークトラフィックを分析して指定のルールセットと比較します。
以下のラボ環境では、Ansible セキュリティー自動化の統合に関するデモを紹介します。Attacker と呼ばれるマシンは、IDPS が実行されているターゲットマシン上で、攻撃パターンを想定してシミュレートします。
実際の設定では、他のベンダーやテクノロジーが含まれている点に注意してください。
2.2.1. 新しい IDPS ルールの作成
関連情報
ids_rule ロールを使用して IDPS のルールおよび署名を管理します。たとえば、新しいルールを設定して、ファイアウォールで以前の攻撃に合わせた特定のパターンを検索できます。
現在、ids_rule ロールは Snort IDPS のみをサポートしています。
前提条件
-
Snort サーバーに変更を加えるには、
root権限が必要です。
手順
ansible-galaxy コマンドを使用して
ids_ruleロールをインストールします。$ ansible-galaxy install ansible_security.ids_rule
add_snort_rule.ymlという名前の新しい Playbook ファイルを作成します。以下のパラメーターを設定します。- name: Add Snort rule hosts: snort
becomeフラグを追加して、Ansible が権限昇格を処理するようにします。- name: Add Snort rule hosts: snort become: true
以下の変数を追加して IDPS プロバイダーの名前を指定します。
- name: Add Snort rule hosts: snort become: true vars: ids_provider: snortPlaybook に、以下のタスクおよびタスク固有の変数 (例: ルール、ルール、Snort ルールファイル、およびルールがない状態) を追加します。
- name: Add Snort rule hosts: snort become: true vars: ids_provider: snort tasks: - name: Add snort password attack rule include_role: name: "ansible_security.ids_rule" vars: ids_rule: 'alert tcp any any -> any any (msg:"Attempted /etc/passwd Attack"; uricontent:"/etc/passwd"; classtype:attempted-user; sid:99000004; priority:1; rev:1;)' ids_rules_file: '/etc/snort/rules/local.rules' ids_rule_state: presentタスクは、ターゲットマシンに変更を加えるコンポーネントです。このようなタスクを定義するロールを使用しているため、必要となるエントリーは
include_roleのみです。ids_rules_file変数はlocal.rulesファイルに定義された場所を指定し、ids_rule_state変数は、ルールが存在しない場合には作成する必要があることを示しています。以下のコマンドを実行して Playbook を実行します。
$ ansible-navigator run add_snort_rule.ym --mode stdout
Playbook を実行すると、新規作成したルールに加えて、すべてのタスクが実行します。Playbook の出力では、PLAY、TASK、RUNNING HANDLER、PLAY RECAP を確認します。
検証
IDPS ルールが正常に作成されたことを確認するには、Snort サーバーに対して SSH を実行し、/etc/snort/rules/local.rules ファイルの内容を表示します。