この記事はシスコの有志による Cisco Systems Japan Advent Calendar 2022 (2枚目) の 18日目として投稿しています。
2022年版(1,2枚目): https://qiita.com/advent-calendar/2022/cisco

0.はじめに

　ネットワークを運用する場合に、設計ルールとしていかに素晴らしい取り決めをしてもそれが守られなく、形骸化してしまったという経験はないでしょうか？

　例えば、ネーミングルールを設定しているのに、担当者が後から適当に名前を付けてしまって、この定義って何だっけ？となったり、機密情報を保持したサーバーを配置するネットワークセグメントなので、外部と通信一切させないポリシーだったはずなのに、気付いたら外部と通信できるようになっていた、といったようなことは実際に起こりうるのではと思います。

　本稿では、このような問題を解決するためにCisco Nexus Dashboard InsightsとCisco ACIを連携させ、仮に設計ルールからの逸脱があった場合はWebex Botにタイムリーに怒られるという実装の仕方をご紹介したいと思います。

1.Nexus Dashboard Insightsとは

　Cisco Nexus Dashboard Insights（以後NDI）は、Ciscoのデータセンターソリューションで活用できる、次世代Day2 Operationプラットフォームのことです。
NDIの様々な機能を利用して、運用を高度化できます。

　Nexus Dashboard Insightsの機能は続々と追加されていますが、現時点での主な機能をまとめてみました。

　今回は、この中のCompliance機能を取り上げます。
NDIやNexus Dashboardに関する様々な情報はこちらにもありますので、是非参考にしてください

1.1.Compliance機能について

Compliance機能とは、事前に設定したルールを逸脱した場合に、Anomaly（NDIにおけるFaultのこと）を発生する機能になります。これにより、定期的に棚卸やレビューをしなくても、自動的にルールの逸脱を発見することができます。

1.2.Complianceで設定可能なルール

Compliance機能は、大きく2つの機能に分かれます。
Configuration(設定)のコンプライアンスと、Communication(通信)のコンプライアンスです。

先ほどの例で上げた、ネーミングルールは、Configのコンプライアンスに分類され、通信の禁止ルールは、Communicationのコンプライアンスに分類されます。

2.Webex botについて

NDIではルールの逸脱をAnomalyとして検知した場合に外部のソースに転送することができます。
外部ソースとしてEmail、SyslogやKalkaなどを選択できますが、それらの受信先からAPIを実行することで、もっとユーザーフレンドリーで、様々な面白いことができるWebex Botに違反を通知してもらうことにします。）

Webex botの設定はhiroさんの記事を参考にしてください

3.実装例

登場人物：

Kiteretsu ・・・ネットワーク管理者
Korosuke　・・・ Webex Bot

本稿における構成概要は以下のようになっています。
ACIはVersion4.2を利用し、NDIはVesion6.1を使用しています。
Syslog Server、スクリプト実行サーバーとしてZABBIXを利用しています。

①KiteretsuがACIにおいてルールを逸脱をする
②APICと連携しているNDIがAnomaryを検知する
③NDIがAnomaly情報をSyslog(Zabbix)に転送する
④Syslog(Zabbix)サーバーにおいてAnomalyのキーワードに応じてActionとしてWebex APIを実行する
⑤これを受けたKorosuke（Bot）がKiteretsuに怒る

という仕組みです。

3.1. NDI事前設定

まずNDI側の設定です。
今回以下の２つのルールを設定したいと思います。

設定ルール	カテゴリ	内容
BDに対するネーミングルール	Configuration	BDの名前はBD_で始めなければならない
EPG:Daihyakkaの通信ルール	Communication	EPG:Daihyakkaは外部に通信してはいけない

①Configurationルールは、ネーミングルールのほかに、パラメータの設値なども設定が可能です。
今回は、添付画像のようにBD_で始めることをルールとして設定しました。

②Communicationルールは、Must Talk to（SLAルール）、Must Not Talk to（禁止ルール）、May Talk to(制限ルール)の３つの方法が可能です。今回は、Daihyakkaは非常に気密性が高いため、外部と通信させないという禁止ルールを設定しました。

該当Complianceルールを逸脱した際に、Anomalyの情報を外部サーバーに転送することができます。今回はFalicity local5で、Syslogサーバーに対して転送を行うこととしました。

事前の状態では、Complianceの順守状況は、100％となっています。

3.2. Syslog Server設定

Syslogサーバー、Webex APIの実行を行うサーバーとして、今回Zabbixを使用しました。
Anomalyのキーワードを元に、対応する処理を規定しています。

内容	キーワード	アクション
BDのネーミングルール逸脱を検知	CONFIGURATION_COMPLIANCE_VIOLATED (復旧ルールとして、CONFIGURATION_COMPLIANCE_SATISFIED)	webex_anomaly_compliance1.pyを実行 RoomにConfigurationルール逸脱が発生したことを通知
通信ポリシー逸脱を検知	TRAFFIC_RESTRICTION_COMPLIANCE_VIOLATED (復旧ルールとして、TRAFFIC_RESTRICTION_COMPLIANCE_SATISFIED）	webex_anomaly_compliance2.pyを実行

Zabbixの設定として、以下を実施しています。
なお、こちらの設定は、Configルールのみを記載しておりますが、Communicationルールも同様の設定を行っています。
① Syslogの指定
　・NDIから送信されたFacilityに従いSyslogを受信する設定

rsyslog.conf

# Save NDI messages to nw.log
local5.*                                                /var/log/ndi.log

② トリガーの指定
　・Zabbixに送付されたSyslogからキーワードを指定して、トリガーを指定

③　アクションの指定
　・該当のトリガーが発生した際に、アクションとしてリモートコマンドを実施。
　今回は、Zabbix上にPythonファイルを配置し、Webex APIを発行するスクリプトを実行するように設定しました。

3.3. Webex API設定

Webex APIを実行する際は、
・Room IDの指定
・User IDの指定
・Markdownの指定
が必要になります。
さらに今回の環境は、Proxy経由でしか外部にアクセスできないため、Proxyの設定も併せて実施しました。
これらをPythonのrequestsモジュールを使用して、以下のように実装しています。

webex_anomaly_compliance1.py

#!/usr/bin/env python3

import requests
import json

proxies = {
    'http' : 'http://proxy.xxxx.com:80', # HTTP用Proxy
    'https' : 'http://proxy.xxxx.com:80',　# HTTPS用Proxy
}

def main():
    url="https://webexapis.com/v1/messages"
    headers={"Authorization": "Bearer xxxxxxxxxxxxx", # BOTのBearerを記載
             "Content-Type": "application/json"}
    markdown = "Kiteretsu、設定ミスしてるなりー"　# BOTにしゃべらせる文字を指定
    payload={"roomId": "xxxxxxxxxxxx", # Room IDを記載
            "markdown": markdown}
    requests.post(url, headers=headers, data=json.dumps(payload),proxies=proxies)

if __name__=="__main__":
    main()

3.4. ACIにルール逸脱設定をしてみる1（BDの名前をButa_Golliraにする）

では、早速BDを作成してみましょう。
①本来「BD_」で開始すべきBDの名前を「Buta_Gollira」として作ってみます

②数分～十数分後にNDI側でComplianceのAnomalyが発生し、Korosukeが以下のメッセージを出して怒ってくれました。

③NDIにログインすると、BD_RuleがVIOLATEDとなっていることが分かります。

更に、NDIでは、該当の詳細の理由や対応アクションを表示することも可能です。

3.5. ACIにルール逸脱設定をしてみる2（Daihyakkaを外部に公開する）

次に、Daihyakkaが外部からアクセスできる状態にしてみましょう。
①EPG DaihyakkaをL3OutのExternal EPGと通信できるようにContractを設定してみます
事前のACI設定は、こちらですが、

設定変更してDayhyakkaが外からアクセスできる状態になりました。

②数分～十数分後にNDI側でComplianceのAnomalyが発生し、Korosukeが以下のメッセージを出して怒ってくれました。

③NDIにログインすると、Security_RuleがVIOLATEDとなっていることが分かります。

先ほど同様NDIで、該当の詳細の理由や対応アクションを表示することが可能です。

4. まとめ

　このようにNDIを使うと運用の高度化を簡単に実現します。
　一つだけ注意点は、Compliance機能は、デフォルトで15分間隔でSnapshotを取得し、Anomalyの発生有無を確認しているため、短い間隔での検知が必要な場合は、手動でSnapshotを取得するなどを検討頂く必要があります。
　今回はComplianceの機能を使って、BotOpsを実装する例を紹介しましたが、今後様々な活用用法をCisco Communityなどで紹介していきたいと思います。
　また、ACIやNDIの情報は、ACI How to、Nexus How toにまとめてありますので、是非活用してみてください。

それでは、皆様、良い年末をお過ごしください

最後に

Advent Calender気軽に挙手してみたんですけど、結構大変だとわかりましたー。
来年は一年かけてネタを仕込んでみたいと思います
本稿の投稿にあたって、様々な知見をアドバイス頂いた@hiroactivityさんに感謝いたします。

Cisco Nexus Dashboard InsightのCompliance機能を使って、設計ルールから逸脱した場合にBotに怒られる実装をしてみる