Unimus APIの活用例 ― ネットワーク機器の脆弱性確認PoCを試してみた

はじめに

Unimusは、ネットワーク機器のコンフィグバックアップや変更履歴の確認、複数機器への設定変更などを行えるネットワーク構成管理ツールです。

こうした標準機能に加えて、UnimusにはREST APIも用意されており、管理しているネットワーク機器の情報を外部から取得したり、Unimusの機能を外部のプログラムから利用したりできます。

そこで今回は、Unimus APIの活用例として、ネットワーク機器のバージョン情報を使った簡単なPoCを作ってみました。

Unimusで管理している機器にCLIコマンドを実行してバージョンを取得し、公開されている脆弱性情報から関連しそうなCVEを検索。結果はMicrosoft Teamsへ通知します。

検証にはCisco、VyOS、MikroTikを使用しました。

ただし、これは機器が脆弱性の影響を受けるかどうかを判定する「脆弱性スキャナ」ではありません。あくまで、追加で確認したほうがよさそうなCVEを探すための簡易的なチェックツールです。

この記事では、このPoCを例に、Unimus APIから取得した情報や実行結果を外部の処理へつなぐ方法を紹介します。

Unimusとは

Unimusは、ルーターやスイッチ、ファイアウォールなどのネットワーク機器を対象とした構成管理ツールです。

機器のコンフィグを定期的にバックアップし、設定が変更された場合には以前のコンフィグとの差分を確認できます。

また、複数の機器にCLIコマンドを送るConfig Pushなど、ネットワーク機器をまとめて扱うための機能も備えています。

この検証では、Cisco、VyOS、MikroTikの3種類の機器をUnimusへ登録しました。

Unimusのデバイス一覧
検証で使用したCisco、VyOS、MikroTikのデバイス

Unimus APIから外部処理へつなぐ

PoCの構成は次のようになっています。

Unimus APIを利用したPoCの構成
Unimusで取得した情報や実行結果を、API経由で外部処理へ連携する構成例

Unimus側では、管理しているデバイスの取得、CLIコマンドの実行、実行結果の取得を行います。

そこから先のバージョン解析、NVDへの問い合わせ、Teamsへの通知はPython側の処理です。

Unimus APIへのアクセスにはAPI Tokenを使用します。Unimusの「User management > API tokens」からTokenを作成し、APIリクエストのAuthorizationヘッダーにBearer Tokenとして指定します。

Authorization: Bearer <token>

今回のPoCでも、このAPI Tokenを使ってPythonからUnimus APIへアクセスしています。

使用した主なAPIは次のとおりです。

処理API
デバイス一覧の取得API v2 GET /api/v2/devices
CLIコマンドの実行API v3 POST /api/v3/jobs/push
実行結果の取得API v3 GET /api/v3/jobs/push/{jobUuid}/result

UnimusではJSONベースのREST APIが提供されており、現在のバージョンではAPI v2とAPI v3を利用できます。

この記事ではPythonのコードそのものではなく、APIを使ってどのような処理につなげたのかと、その結果を見ていきます。

API v2で対象機器を取得する

最初に使用するのが、Unimusに登録されているデバイスを取得するAPIです。

GET /api/v2/devices

Pythonから呼び出す部分だけ抜き出すと、イメージは次のようになります。

response = requests.get(
    f"{UNIMUS_URL}/api/v2/devices",
    headers={"Authorization": f"Bearer {API_TOKEN}"}
)

devices = response.json()

APIから取得したレスポンスはJSON形式です。

例えば、その中から後の処理で使う情報だけを見ると、イメージとしては次のようになります。

{
  "uuid": "...",
  "vendor": "Cisco",
  "model": "WS-C2960G-24TC-L",
  "managed": true
}

実際のレスポンスにはほかの情報も含まれますが、このPoCでは管理対象のデバイスを選び、デバイスUUIDやベンダー、モデルなど必要な項目を取り出して使用しています。

特にデバイスUUIDは、次のCLI実行で「どの機器へコマンドを送るか」を指定するときに使用します。

API v3からCLIコマンドを実行してバージョンを取得する

対象となる機器が決まったら、OSやファームウェアのバージョンを取得します。

ここではAPI v3のJobsを利用し、Config PushとしてCLIコマンドを実行します。

使用するAPIは次のものです。

POST /api/v3/jobs/push

Python側では、対象デバイスのUUIDや実行するCLIコマンドを指定してリクエストを送ります。

呼び出し部分を簡略化すると、次のような形です。

response = requests.post(
    f"{UNIMUS_URL}/api/v3/jobs/push",
    headers={"Authorization": f"Bearer {API_TOKEN}"},
    json=payload
)

Ciscoであれば、例えば次のコマンドを実行します。

show version

コマンドを実行するとUnimus上にJobが作成されます。

続いて、そのJobの実行結果を次のAPIから取得します。

GET /api/v3/jobs/push/{jobUuid}/result

Pythonからは、例えば次のように結果を取得します。

result = requests.get(
    f"{UNIMUS_URL}/api/v3/jobs/push/{job_uuid}/result",
    headers={"Authorization": f"Bearer {API_TOKEN}"}
)

API経由で実行したCLIコマンドの結果
API経由で実行したCLIコマンドの結果

Cisco、VyOS、MikroTikの3種類で試したところ、いずれもUnimus API経由でバージョン情報を取得できました。

ただし、ベンダーによって使用するコマンドやCLI出力の形式は異なります。そこで、取得したCLI出力をPython側で読み取り、ベンダー名、モデル、OS、バージョンなど、後の処理で必要になる情報だけを取り出すようにしました。

処理の流れを簡単にすると、次のようになります。

CLIコマンドを実行 → CLI出力を取得 → Pythonで必要な情報を抽出 → NVDへ問い合わせ

つまり、show versionなどの長いCLI出力をそのままNVDへ送るわけではありません。Python側でバージョン情報などを抜き出し、それを脆弱性情報を検索するための材料として使っています。

次の章では、この情報を使って実際にCVE候補を探してみます。

バージョン情報からCVE候補を探す

ここからは、Unimus APIで取得した情報を使った外部処理です。

取得したベンダー名や製品、バージョンの情報をもとに、NVD(National Vulnerability Database)から関連しそうな脆弱性情報を検索します。

NVDは、米国NISTが提供している脆弱性情報のデータベースです。NVDでは、CVEと呼ばれる脆弱性ごとの識別番号をもとに、脆弱性の概要や深刻度、影響を受ける製品などを確認できます。

このPoCでは、PythonからNVDへ問い合わせ、機器情報に関連しそうなCVEを確認候補として取り出しています。

3ベンダーで試した結果は次のようになりました。

ベンダーバージョン取得CVE候補
Cisco成功取得できた
MikroTik成功取得できた
VyOS rolling release成功今回の方法では特定できず

CiscoとMikroTikでは、今回の検索方法でCVE候補を取得できました。

一方、VyOSのrolling releaseもバージョン取得までは正常に動作しましたが、同じ方法ではNVD上で一致する候補を特定できませんでした。

ここは実際に試してみて分かったところです。

機器からバージョンを取得できても、その情報を外部の脆弱性データベースと正確に対応付けられるとは限りません。製品名やバージョンの表記方法によっては、単純な照合では候補を見つけられない場合があります。

そのため、このPoCでは検索結果をそのまま「脆弱性あり」と判定するためには使っていません。

あくまで追加確認するための候補として扱い、実際の影響有無については、必要に応じて各ベンダーが公開しているSecurity Advisoryなどで確認します。

CVE候補をTeamsへ通知する

CVE候補はPython側で整理し、Microsoft TeamsへWebhookを利用して通知しました。

Microsoft Teamsへ届いた通知
NVDから取得したCVE候補を整理し、Microsoft Teamsへ通知した例

通知には、対象デバイス、ベンダー、モデル、バージョン、CVE ID、CVSS、Severityなどを含めています。

Teamsは通知先として選んだ一例です。外部処理の部分を変えれば、別の通知先や社内システムへつなぐこともできます。

また、この処理はPythonスクリプトとして動作するため、必要に応じてWindows Task Schedulerなどから定期実行する運用も可能です。

例えば、毎日や週1回といったタイミングで実行し、確認候補があればTeamsで確認するといった使い方もできます。

まとめ

この記事では、Unimus APIの活用例として、ネットワーク機器のバージョン情報を使った脆弱性確認PoCを紹介しました。

Unimus APIからデバイス情報を取得し、CLIコマンドを実行。その結果をPython側へ渡し、NVDからCVE候補を探してTeamsへ通知しています。

脆弱性情報との照合については、VyOSのように単純なバージョン照合では候補を特定できないケースもありました。より正確に影響を判断するには、ベンダーのSecurity Advisoryなどを含めた確認が必要です。

一方で、Unimusで管理している機器の情報やCLIの実行結果をAPIから取得し、その先の処理へ渡すという流れは確認できました。

今回は脆弱性確認を題材にしましたが、APIから取得した情報や実行結果は、レポート作成や通知、社内システムとの連携などにも利用できます。

Unimus APIを使った外部連携の一例として、参考になれば幸いです。

さいごに

Unimusのインストールから初期設定、デバイス登録、バックアップ取得までの詳しい操作手順を確認したい場合は、Unimus評価ガイドもあわせてご活用ください。

Unimusの詳細や評価版については、弊社Webサイトもご確認ください。

こんな記事も読まれています

最新記事

おすすめ記事

  1. 「ログイン成功」でも安心できない?正常なログに潜む異常の兆候を見つけるUEBA

  2. ゼロから始めるCheckmk!評価版OVA×VirtualBoxで簡単に検証環境を構築

  3. AIが1万件超の脆弱性を見つける時代に、企業は“既知の穴”を塞げているか

製品カテゴリー

その他の情報

TOP