2025年7月1日

はじめに

クラウド化が進む昨今、お客様の中でも社内サーバのクラウド移行を検討している、または既に移行しているというようなケースをよく耳にします。クラウド移行を検討しているお客様では、オンプレミスで設置している移行前のサーバに対して現状どれだけの通信が発生しているのかをまず可視化し、それをもとに移行後のキャパシティプランニングやローカルブレイクアウトの計画に役立てたいというようなご用件から、トラフィック可視化ツールFlowmonにご注目いただくことが多いです。既に移行を済ませているようなお客様でも、クラウドサーバとの通信可視化の必要性はオンプレ環境と変わりません。これらのようなケースでは、可視化対象はオンプレ端末-オンプレサーバ間及びオンプレ端末-クラウドサーバ間の通信となり、いずれもオンプレ側が基点となります。では、例えばクラウド上のVM同士の通信を見たい場合はどのような方法が取れるでしょうか。FlowmonではAWS（Amazon web Service）、Azure、GCP（Google Cloud Platform）の3種類のクラウドサービスと連携し、クラウドの内部通信を可視化することができます。本コラムではAWSにフォーカスし、連携方法や可視化検証をご紹介いたします。

VPC Flowログとは

AWSの内部通信は、VPC（Virtual Private Cloud）のFlowログという機能を使用することで可視化が可能です。このFlowログはCloudWatch Logs Insightsを使ってマネジメントコンソールから確認する方法や、S3バケット経由でAmazon Athena・AWS Glueなどの解析ツールと連携する方法が一般的ですが、FlowmonのFlowログ連携機能を使うことでFlowmon Collectorでも表示することができます。この機能ではFlowログをIPFIX（NetFlow）形式で収集します。収集したログは通常のネットワーク機器で生成したFlowと同様に生データ保持・解析ができるため、オンプレとクラウドでツールを分けることなく、Flowmonで一括して扱うことが可能になります。

FlowmonとVPC Flowログの連携

FlowmonとFlowログの連携は、以下のような流れで行われます。

①VPC内のリソース（EC2インスタンス等）で通信が発生すると、②ENI（Elastic Network Interface）単位でFlowログが生成され、③Amazon CloudWatchのロググループに格納されます。④格納されたログをFlowmon Collectorが1分または5分（プロファイル粒度に依存）間隔で取得し、IPFIX形式に変換して保持します。また、Flowmonで対応しているVPC Flowログレコードは、デフォルトフォーマット及びデフォルトのフィールドに「tcp-flags」を追加したカスタムフォーマットの2種類となります。VPC FlowログとIPFIX形式変換後とのフィールドのマッピングは以下の通りです。

なお、カスタムフォーマットを用いる場合は、表に記載の順序でレコードを作成する必要があります。 AWS連携の詳しい設定方法は弊社までお気軽にお問い合わせください。

AWS環境可視化検証

AWS上に下図のような環境を構築し、VPC Flowログを用いて実際にどのように可視化ができるのかを検証いたしました。

Flowmonは物理版のほかにAWS等の仮想環境にも対応したアプライアンスをご用意しており、AWS版ではAWS Marketplaceにてデプロイ可能なAMI（Amazon Machine Image）を公開しております。今回の構成ではAWS版Flowmon Collector（Collector_EC2）と検証用のダミーサーバ（Test_EC2）を1台ずつデプロイし、これらのインスタンス間で通信を発生させます。Flowログの連携にはデプロイしたCollector_EC2を使用しておりますが、連携に使用するCollectorはAWS環境に設置されている必要はなく、オンプレ環境の物理Collectorでも問題ありません。 環境構築後、Test_EC2からCollector_EC2に対してping、ssh、curl（HTTPS）を実行し、これらの通信をCollector_EC2で確認しました。表1に記載の情報が取得されるはずですので、「フローのリスト」解析を用いて以下の項目を出力しています。

• 開始時間 – 最終確認
• 期間
• 送信元IPアドレス
• 宛先IPアドレス
• 送信元ポート
• 宛先ポート
• プロトコル
• パケット
• バイト
• パケット/秒
• ビット/秒
• バイト/パケット
• フロー
• TCPフラグ
• 入力インターフェース
• FlowソースIPアドレス

実際に取得された情報は以下の通りです。

それぞれの項目がきちんと取得されており、pingの場合はプロトコルが「ICMP」、宛先ポートが「Echo reply」となっています。また、sshやcurlの場合はポートがそれぞれ「ssh」、「https」となっているほか、TCP通信のためカスタムフィールドのTCPフラグも取得されました。入力インターフェースにはENIのIDが記載されています。また、VPC Flowログのフィールドにはありませんが、FlowソースIPアドレスにはCloudWatchロググループの名前が出力されました（IPアドレス部分は127.128.0.xで、Flowソースとして認識された順に0から振られていきます）。このように、ロググループ単位でFlowソースとして認識されるため、ロググループを複数作成することで別々のFlowソースとして管理することが可能です。CollectorでVPCの通信を取得できることが確認できましたが、AWS CloudWatchで直接Flowログを確認できるLogs Insights機能ではどのように見えるのでしょうか。

図4は、図3と同じpingの通信ログをCloudWatch Logs Insightsから確認した画面です。こちらでは、Flowmonでは非対応の「accountId」や、セキュリティグループ・ネットワークACLでの処理結果を示す「action」（ACCEPT/REJECT）なども確認できます。また、Flowログから通信量の多いIPアドレスや使用されているポートの統計であったり、通信量の推移をグラフで出力したりといった解析を行うこともできますが、クエリコマンドを入力する必要があり初心者では手を出しづらい印象があります。

一方、Flowmonでは、統計解析やトラフィックグラフ描画がGUIで簡単に行えます。

VPC Flowログで取得したデータと通常のネットワーク機器から収集したFlowデータとは同等に扱われ、解析機能などに差はありません。また、このことから、VPCから生成したFlowログとオンプレ環境で生成したFlowをCollector 1台で同時に扱うことができ、環境によって複数のツールを使い分ける手間を省くことができます。加えて、オンプレ環境とAWS環境両方に監視ポイントを設けることで可視化できる範囲が拡張でき、双方のトラフィックデータを組み合わせることでより詳細な解析も可能になるといえます。

5. おわりに

本コラムでは、Flowmonを用いてAWS環境の可視化を実現する、VPC Flowログ連携についてご紹介しました。今回はAWSに焦点を絞ってご紹介しましたが、ほかにもAzureやGCPといったクラウドサービスにも対応しております。オンプレ環境だけでなくクラウド環境まで可視化範囲を広げることで、Flowmonを最大限活用いただければと思います。

• 120秒でざっくりわかる製品紹介動画
• 20分でデモまで見られる製品紹介動画
• 30日間無償で試せる評価版

2025年5月7日

はじめに

現代のIT環境において、ネットワークはあらゆる業務の基盤として欠かせない存在となっています。DX化が加速する昨今では、クラウドサービスの活用やリモートワークの普及、拠点間の接続環境の多様化など、ネットワークを取り巻く環境は日々複雑化しています。こうした背景から、単にネットワーク機器の死活監視や障害検知を行うだけでは、十分な運用・管理が難しくなっています。ネットワークの状態を正確に把握し、安定したサービス提供を続けるためには「ネットワークの可視化」が今まで以上に重要になっています。さらに、可視化によって得られた情報をもとに、効率的な負荷分散や迅速なトラブルシューティング、インシデントの早期発見へとつなげていくことが、これからのネットワーク運用には求められています。本コラムでは、Flowmon Probeの機能を活用した「ネットワーク品質状態の可視化」について解説し、具体的なユースケースを交えながらその有用性をご紹介します。

ネットワーク品質状態可視化のポイント

まず、「ネットワークの品質状態」とは何を指すのでしょうか？ これは単に通信ができているかどうかだけではなく、通信がどれだけスムーズに、安定して行われているかを示す重要な指標です。遅延（Delay）が発生していないか、再送（Retransmission）が頻発していないか、応答速度（Response Time）が適切かといった点を総合的に評価する必要があります。 Flowmonでは、ネットワーク品質状態を可視化するための項目を総括してNetwork Performance Monitoring（以下、NPM）と呼んでいます。NPMでは、主に以下の6項目を可視化・監視することができます。

NPMを用いることで通信遅延やサーバ応答遅延、通信経路の不安定さなど、ネットワーク上で発生するパフォーマンス問題の可視化/把握ができます。また、Flowmonでは過去のデータをサマリーせずに参照できるため、突発的な障害だけでなく、慢性的な性能劣化にも早期に気づくことができます。

ネットワーク品質状態可視化のユースケース例
～特定時間帯に発生する業務システムの通信エラー調査～

ここからは実際に起きうるケースを想定して、NPMを活用したネットワークの品質状態を可視化したケースをご紹介します。ある企業では、毎日特定の時間帯になると、業務システムのサーバアプリケーションで通信エラーが発生するという現象が起きていました。利用者からも「業務システムに接続できない」「動作が重い」といったクレームが頻発しており、迅速な対応が求められる状況です。まず、問題切り分けに際してあたりをつけるために、グラフ上にRTTとSRTの情報を表示させることでネットワークの遅延が原因なのか、サーバの応答が遅いのか、おおまかな方向性を把握します。

次にグラフ上で問題発生時刻周辺のバーストトラフィックやアプリケーションエラーが発生した時間帯に絞って選択し、フローのリスト解析を用いて各項目を図3のように設定し、解析します。

図4の解析結果最上部の通信を問題が発生した該当の通信として話を進めます。解析の結果を見てみると、RTTは平均約5.25ミリ秒程度ですので、問題の発生時には他の通信と比較してもあまり問題でないことが確認できました。しかし、SRTは平均約7.1ミリ秒に対して552.6ミリ秒となっており、他の通信と比較してとても大きい値であることがわかります。RTTはネットワークの遅延値、SRTはサーバの応答時間ですので、ネットワーク自体には大きな問題はなく、サーバ側のリソース不足やアプリケーションのパフォーマンス問題が主な原因であると特定できました。ネットワーク側の調査に無駄な時間をかけることなく、サーバチームへ速やかに原因対応を依頼することができ、業務影響の最小化を図ることができます。 今回は主にSRTとRTTを用いて原因調査をしましたが、他に起きている問題や状況によっては、RTR(再送回数)やDelay(遅延)といった他のNPM情報を可視化することで、より詳細なネットワークの品質状態を確認することができます。

おわりに

ネットワークの可視化とは、単にネットワーク機器や接続構成を見える化することだけではありません。さらに一歩踏み込み、通信の速度・遅延・安定性といった「品質状態」を見える化することが、これからのネットワーク運用に求められる視点となります。可視化に＋αの視点を持つことで、問題発生時の迅速な対応、トラブルの根本原因特定、パフォーマンス改善提案など、ネットワーク部門としての価値をさらに高めることができます。 Flowmon Probeで生成したフローでは、NPMだけでなく、HTTPホスト名やDNS、sambaファイルサーバなど、NW機器が生成したフローだけでは行えない＋αの解析を実現することができます。前回の記事では、HTTP関連について解説/検証していますので、ご興味があればこちらも併せてご覧ください。
前回のコラム記事はこちらからご覧いただけます。
Flowmon Probeに関する詳細はこちらからご覧ください。

• 120秒でざっくりわかる製品紹介動画
• 20分でデモまで見られる製品紹介動画
• 30日間無償で試せる評価版

2025年4月1日

1. はじめに

HTTP通信の可視化はFlowmonを導入いただいているお客様の中で好評いただいている機能の一つですが、近年ではそのほとんどがHTTPSの暗号化通信となっています。Web通信におけるプライバシー確保のニーズは高まっており、常時SSL化の動きも急速に広まっていますが、ネットワーク管理者の立場では社内のWeb通信を可視化したいというような相反するご要望も存在します。そこで本コラムでは先月と今月の二回にわたりHTTPSの秘匿された通信がトラフィック可視化ツールFlowmonでどのように視えるのかを解説いたします。パート2となる今月は、Flowmonの実機を用いて実際のHTTPS通信がどのように可視化されるのかを検証していきます。なお、パート1となる先月のコラムではHTTPS通信の暗号化の仕組みを解説しておりますので、本コラムを読む際の予備知識として参考にしていただければ幸いです。前回の記事はこちらからご覧いただけます。

2. HTTPS利用状況

レポート機能を用いて、ある1週間を対象に社内通信のHTTPS利用状況を見てみました。まずHTTPとHTTPSの利用割合ですが、この週では約93%（バイト）がHTTPSの通信となっていました（ポート443の通信をHTTPS、80の通信をHTTPとしています）。

HTTPSの暗号化を担うTLSのバージョンもFlowmonで可視化できます。前回のパート1でもご紹介したように、TLS 1.2以前とTLS 1.3以降では暗号化の仕組みや暗号化される通信の範囲が異なります。どのバージョンを利用するかはTLSハンドシェイクの初めにネゴシエーションされ、Client Helloからクライアントの希望するバージョンを、Server Helloからサーバが採用したバージョンをそれぞれ確認できます。

サーバ、クライアント共に1位は「N/A（Not Available）」となっていますが、これはFlowmonで取得できなかったものや未対応のものとなり、最新のHTTP/3で利用されているQUICの通信などはここに含まれます。QUICについては本コラムの最後の方で解説いたします。

サーバ側の2位以降は、「TLS 1.2」が3割、「TLS 1.3」が2割、そして「TLS 1.0」やRFCとしてリリースされる前の草案となる「TLS 1.3 (Facebook draft 23)」も見られました。

クライアント側の2位以降は、「TLS 1.3」及び「TLS 1.2」が共に2割程度となり、4 ~ 19位には「GREASE#0x****」というものが入っていました。GREASEとはTLS 1.2及び1.3で使われる全部で16個の予約された値で、プロトコルの拡張性を確保するために用いられます。どのように使われるかというと、例えばWebサーバでTLSの実装に問題があった際、未対応の拡張が含まれたパケットを受信した際に接続が失敗してしまうことがあります。そこで、クライアントから意図的に無意味な値（0x****で表記されている16進数の値）をClient Helloに挿入して送信することで、サーバがこれを無視して接続を続行できるかテストします。

3. HTTP情報取得のためのFlowmon設定

HTTP情報は通常のNetFlow/IPFIXでは取得できませんが、Flowmon Probeを用いてフロー生成を行うことで可視化できるようになります。本コラムの検証では、以下の情報を用いました。

• HTTPフィールド：HTTPヘッダから取得可能な情報
• TLS Mainフィールド：TLSバージョンなどの基本情報
• TLS Clientフィールド：拡張タイプなどクライアント側の情報
• TLS Certificateフィールド：サーバ証明書の情報

これらの情報を取得する際には、Probe（フロー生成機）とCollector（フロー分析機）でそれぞれ以下に示した項目にチェックが入っている必要があります。

Flowmon Probeの場合

Flowmon Collectorの場合

4. HTTP通信の可視化

「フローのリスト」解析を用いて、HTTP及びHTTPSのTLSバージョンごとに可視化できる項目を確認していきます。今回は、以下の項目を出力しました。

• ホスト名
• HTTPメソッド
• URL
• HTTP結果コード

• TLS Server version
• TLS server name (SNI)
• TLS Content type
• TLS Handshake type

• TLS Client version
• TLS Extension types

• TLS Issuer common name
• TLS Subject common name
• TLS Subject organisation name
• TLS Signature algorithm
• TLS Public key algorithm

それでは実際に取得された情報を確認してみましょう。まずは平文のHTTP通信から、フロー情報を下図に示します。

Windows Update関連の「lu.dl.delivery.mp.microsoft.com」（末尾から32ビットまで表示）と、Chromeの管理コンソール「client2.google.com」が確認できました。ホスト名やメソッドのほかに、クライアントからのリクエストではURLが、サーバからのレスポンスではHTTP結果コードが記録されていました。また、HTTPではSSL/TLSは使用しませんので、TLS Main、TLS Client、TLS Certificateのフィールドは空欄（N/A）でした。

5. TLS1.2の可視化

続いて、TLS 1.2のHTTPS通信で取得できたフロー情報を下図に示します。

マイクロソフトのEdge「edge.microsoft.com」やGraph「graph.microsoft.com」との通信が該当しました。HTTP通信とは異なり、URLや結果コードは確認できませんでしたが、TLS関連の項目はすべて確認できました。通常ホスト名はHTTPヘッダから取得される情報ですが、TLSで暗号化されている場合はTLSの拡張機能であるSNI（TLS Server Nameの項目）から取得できます。また、メソッドには「SSL」という値が出力されます。そのほかにも、TLSコンテンツタイプからはハンドシェイク（HS）やChange Cipher Spec（CCS）等をやり取りする通信がフローに含まれていることが分かります。ハンドシェイクタイプを見ると、Client Hello（CH）やServer Hello（SH）、Certificate（CER）等がハンドシェイク内でやり取りされています。クライアント側の情報（緑のフィールド）としては、エクステンション（拡張）タイプから、0：SNI、5：Status Request（サーバ証明書の失効情報取得に使用）等のTLS拡張機能が確認できます。証明書の情報（紫）としては、発行者のCN（コモンネーム）、対象ドメイン（ホスト）のCNやON（組織名）のほかにも、署名や公開鍵のアルゴリズム等が分かります。

6. TLS1.3の可視化

下図はTLS 1.3の通信から取得できたフロー情報です。

「www.google.com」「www.yahoo.co.jp」「login.microsoft.com」との通信がTLS 1.3を利用していました。TLS 1.2と同様に、SNIからホスト名を取得することができています。また、TLS Main（オレンジのフィールド）やTLS Client（緑）は見ることができましたが、TLS Certificate（紫）は取得されませんでした。TLS 1.3ではServer Helloまでは平文で行われますが、Server Helloで鍵交換が完了した直後から暗号化通信が開始するため、そのあとにやり取りされる証明書などの情報は見ることができないのです。

7. 最新の暗号化通信

HTTP/3ではTLS 1.3を組み込んだQUICというプロトコルが使用されます。HTTP/2との大きな違いはトランスポート層がUDPになっていることで、接続確立の高速化など効率的な通信を実現しています。TLSがQUICに内包される形となるためFlowmonではTLSバージョンを確認することができませんが、下図のようにHTTPS通信（port 443）でUDPを使っていることからQUIC（HTTP/3）であると判断できます。

「www.bing.com」「play.google.com」との通信が該当しました。これらの通信では、SNI（ホスト名）のほかに可視化できた項目はありませんでした。QUICではClient Helloから一部暗号化された状態で接続を開始します（AEAD: AES-GCMという独自の方式で暗号化します）。これは事前共有鍵ではなく固定鍵を用いるため完全な機密性はなく、ハンドシェイクのみに利用されます。QUICのデフォルトではSNIは暗号化範囲外のため今回はホスト名を確認することができましたが、近年では通信のセキュリティ強化を目的としたESNI（Encrypted SNI、暗号化されたSNI）やECH（Encrypted Client Hello、暗号化されたClient Hello）が登場しています。現状ではESNIは実装上の課題からあまり普及はせず、後継となるECHもまだ実験段階のため広く使われているわけではありません。しかしセキュリティ強化のニーズは高まる一方なので、Client Helloから暗号化を行おうという動きは今後広まっていくでしょう。FlowmonではECH等にも対応した可視化ソリューションを開発しているとのことなので、プライバシーの確保とネットワーク可視化がどのように両立されるのか気になるところです。

8. まとめ

今回の検証結果として、TLSバージョンごとに可視化できた項目を以下の表にまとめます。

TLSを使わないHTTP通信では、ホスト名やメソッド、URL、結果コードといったHTTPヘッダ情報が可視化できました。TLSを用いるHTTPS通信（TLS 1.2、TLS 1.3、QUIC）ではHTTPヘッダ情報は取得できませんでしたが、SNIからホスト名を取得できました。また、TLS 1.2ではTLSの基本情報であるTLS Mainフィールド、クライアント情報のTLS Clientフィールド、証明書情報のTLS Certificateフィールドのすべてが可視化できました。TLS 1.3ではTLS Main、TLS Clientフィールドは可視化できましたが、証明書交換以降は暗号化されるためTLS Certificateフィールドは取得できませんでした。QUICはTLS 1.3が組み込まれた新しい暗号化通信規格ですが、鍵交換を行う前から暗号化されるためホスト名以外の可視化はできませんでした。

9. おわりに

本コラムでは、Flowmonの実機を用いてHTTPS通信がどのように可視化できるのかを検証いたしました。SSL/TLS及びHTTPのバージョンを追うごとに暗号化される範囲は広がっており、可視化できる項目も減ってきてはいますが、今後Flowmonでは暗号化通信の可視化にどのようなソリューションを提示していくのか注目していきたいです。

• 120秒でざっくりわかる製品紹介動画
• 20分でデモまで見られる製品紹介動画
• 30日間無償で試せる評価版

2025年3月3日

はじめに　※今回Flowmonの解説は出てきません！

HTTPはWeb上でデータを通信するために利用されているプロトコルであり、インターネットの閲覧には不可欠となっています。しかしながらHTTPは通信が暗号化されないことや認証機能を備えていないことから、安全性の高いプロトコルとは言えません。このセキュリティ面の課題を解決するために生み出されたのがHTTPSです。HTTPSは厳密にはプロトコルではなく、SSL/TLSという暗号化プロトコルを組み込むことで安全性を確保した、”セキュアなHTTP通信”のことを指します。近年では重要なデータをやり取りするログインページ等のほかにも、Webサイト内のすべてのページをSSL化する常時SSL化の動きが広まっています。HTTPSの使用率は日本では95%（2025/2/8時点、※1）にも上り、セキュアな通信が当たり前の時代になっているといえます。

通信の高い安全性が求められる一方で、ネットワーク管理者の立場からは「インターネットへ向けたLAN内の通信を可視化したい」というような相反するニーズも存在します。そこで本コラムでは今月と来月の二回にわたり、HTTPSの秘匿された通信がトラフィック可視化ツールFlowmon上でどのように視えるのかを解説いたします。まずパート1となる今月はHTTPSの基礎解説編として、どのような仕組みで暗号化通信が行われているのかの解説を行います。（ですので今回Flowmonの解説は出てきません！）Flowmonを用いたHTTPS通信可視化については、来月公開予定のパート2実機検証編にて詳しくご紹介いたします。

HTTPS通信の流れ

次の図は、HTTPとHTTPSそれぞれの通信シーケンスの概略図です。

基本的な流れとしては、クライアント-Webサーバ間のTCP接続が確立した後、HTTP通信でクライアントからのリクエストとサーバからのレスポンスがやり取りされます。HTTPSの場合では間にSSL/TLSハンドシェイクと呼ばれるネゴシエーションが入り、ここで暗号化に必要な情報が交換されます。バージョンによって暗号化される範囲が異なり、TLS 1.2以前ではHTTPS通信部分のみ、TLS 1.3以降ではSSL/TLSハンドシェイクの途中からが暗号文を用いた通信となります。SSL/TLSハンドシェイクでは認証/暗号化アルゴリズムの合意に加え、暗号化を行うカギの交換や接続先の認証も行われます。これらについて、以降の章で詳しくご説明していきます。

共通鍵と公開鍵/秘密鍵

暗号化に用いるカギによって共通鍵暗号方式と公開鍵暗号方式という2種類の暗号方式が存在し、HTTPSではこれらを組み合わせたハイブリット方式が用いられています。

共通鍵方式は暗号化と復号を共通のカギで行うもので、公開鍵方式と比べて処理速度が速いというメリットがあります。しかし、送信者（暗号化する側）と受信者（復号する側）以外の第三者にカギが渡ってはいけないため、通信相手が増えるほど必要なカギの種類も増え、管理が複雑になります。加えて、カギの受け渡しの際も漏洩を防ぐよう十分に注意する必要があります。
それに対して公開鍵暗号では2つのカギのペアを使い、暗号化/復号をそれぞれ別のカギで行います。一方のカギで暗号化されたものはもう一方でしか復号できず、その逆も同様です。公開鍵方式では、このペアのうち片方をだれでも取得できる公開鍵とし、もう片方は秘密鍵として生成者のみが保有します。こうすることで、暗号化は公開鍵を利用して誰でも行えますが、復号は秘密鍵の所有者（受信者）にしかできない仕組みになっています。この方式の特徴として、公開鍵では復号ができないため盗聴されても問題なく、共通鍵方式のデメリットであった暗号鍵受け渡し時のリスクが解消されます。さらに、複数の送信者で暗号鍵の共用が可能となり、通信相手が増えても複数のカギを用意する必要がなくなります。しかし、暗号化と復号を別々のカギで行うことで処理速度が低下するというデメリットもあります。
HTTPSでは公開鍵方式と共通鍵方式を組み合わせて暗号化通信を行います。次の図ではTLS 1.2以前のカギ交換の概略を説明します。

1. まずクライアントからの接続要求があると
2. Webサーバは応答として公開鍵を送付します。
3. 次にクライアントは暗号化通信に利用する共通鍵を生成し、
4. 受け取った公開鍵を用いてこれを暗号化します。
5. その後、暗号化した共通鍵をクライアントからサーバに送付します。
6. サーバは受け取った共通鍵を自らが保有する秘密鍵で復号することで暗号鍵の受け渡しが完了し、
7. 暗号化通信（HTTPS通信）が開始されます。

暗号化通信には共通鍵暗号方式を利用することで処理速度を向上し、共通鍵の受け渡しに公開鍵暗号を使うことで機密性が確保される仕組みとなっています。ちなみに、公開鍵暗号にはいくつか種類があり、ここで共通鍵の受け渡しに利用されているのはRSA暗号を用いたものとなっています。TLS 1.3以降ではDH（Diffie-Hellman）鍵交換という公開鍵方式の技術を用いることで、共通鍵を送付するのではなく、サーバとクライアントの双方が個別に同一の共通鍵を生成することが可能となっています。ただし、DHには認証機能がないためサーバの認証を行うためにRSAも利用されています。
ここで認証機能という単語が出てきましたが、公開鍵暗号ではデジタル署名という技術で通信相手の認証を行うことができます。前述のように公開鍵と秘密鍵は暗号化/復号の役割を入れ替えることができるため、秘密鍵で暗号化した物を公開鍵で復号することができます。公開鍵は誰でも入手できるため機密性の観点からはあまり意味のない行為ですが、通信相手から提供された公開鍵で復号できるということは、その暗号化を行った秘密鍵と自らが入手した公開鍵が対になっていることの証明になります。したがって、暗号化を行った人物と公開鍵を送付した人物が同一であることが保証できます。このように秘密鍵で暗号化を行うことをデジタル署名と呼びます。
TLS 1.3以降で行われているDH鍵交換では、サーバとクライアントがお互いにDH公開鍵/秘密鍵のペアを用意し、それぞれのDH公開鍵を送付しあいます。これらのDH鍵交換を用いた共通鍵の生成に関しては今回割愛させていただきますが、この時のDH公開鍵の交換においてサーバ側はDH公開鍵をRSA秘密鍵で暗号化（署名）して送付します。これを受信したクライアントは、先に受け取っているRSA公開鍵でDH公開鍵（SV）が復号できるかどうかでサーバのなりすましがないかを確認できます。

サーバ証明書

SSL/TLSにおいて、WebサーバのRSA公開鍵はサーバ証明書というものに含まれた状態で送付されます。この証明書はWebサーバが正当な接続先であることの証明（実在証明）に用いられ、RSA公開鍵を安全に送付する手段にもなっています。デジタル署名を用いたDH鍵交換では、DH公開鍵を暗号化した人物とRSA公開鍵を送付した人物が同一であるかを確認できましたが、そもそもRSA公開鍵が改ざんされていた場合はなりすましに気づくことができません。サーバ証明書を用いることでRSA公開鍵が正当なWebサーバのものであることが保証されます。サーバ証明書は認証局（CA、Certificate Authorities）という「無条件で信頼される第三者」により発行され、これらの機関によってサーバの実在証明やRSA公開鍵の正当性の保証が行われます。
証明書を受け取ったクライアントは以下を確認することで正当性をチェックします。

• 自分が所有するルート証明書とサーバ証明書に含まれる発行局の情報の比較（証明書の発行者が信頼できるか）
• デジタル署名の確認（証明書の発行者がなりすまされていないか）
• ハッシュ値の検証（証明書自体が改ざんされていないか）

ルート証明書とはWebブラウザにあらかじめインストールされている「信頼できる認証局の情報」のことで、サーバ証明書に記載されている発行局の信頼性を確認します。
デジタル署名はWebサーバのなりすましだけでなく、認証局のなりすまし検知にも利用されます。前述のルート証明書には認証局が生成する公開鍵が含まれており、これを使ってサーバ証明書に含まれる認証局のデジタル署名が検証されます。
また、ハッシュ値とはデータの改ざん検知に使われる情報で、RSA公開鍵を含むサーバ証明書が改ざんされていないことを確認します。ハッシュ値を計算する関数をハッシュ関数といいますが、これは入力値をもとに「入力値を代表する値（ハッシュ値）」を出力します。より具体的な例では、入力値「FLOWMON」に対して「一文字おきに文字を取り出す」という操作を行うと出力値（ハッシュ値）は「FOMN」となります。改ざんの検知においては、やり取りするデータに対して送信側と受信側で互いにハッシュ値の計算を行う、即ち送信前と受信後のデータからハッシュ値をそれぞれ計算し、これらを比較します。ここで、データが通信途中で「FLOW”N”ON」と改ざんされていたとすると、受信側で出力されたハッシュ値は「FONN」となり改ざんされていることに気づくことができます。もちろんここで示した「一文字おきに文字を取り出す」という関数は実用的ではなく、「FLOWM”A”N」という改ざんに対しては同じハッシュ値「FOMN」が出力されてしまう（衝突）などの問題があります。実際に用いられるハッシュ関数ではより工夫が必要になります。
それでは、サーバ証明書が実際にどのように利用されているか、通信全体の流れをご説明いたします。

まずサーバ証明書の発行を行うフェーズでは、①Webサーバの運用者がサーバの情報とともにRSA公開鍵を認証局に提出して申請します。②認証局により承認されるとWebサーバのRSA公開鍵が入れられたサーバ証明書が発行されます。③証明書を受け取ったWebサーバ運用者はサーバ上に証明書を設置します。続いてクライアントとの通信を行うフェーズでは、⓪前提としてクライアントは認証局からルート証明書を入手しています。①クライアントの接続要求に対して、②サーバは証明書を送付します。これを受け取ったクライアントは③ルート証明書との照会と、ルート証明書から取り出した公開鍵（CA）を使って④デジタル署名の検証、及び⑤ハッシュ値の検証を行います。ここで証明書の正当性が確認できれば、証明書に含まれる公開鍵（SV）が正当なものであることがわかるため、図4や図5のカギ交換に移ることができます。

Flowmonにおける暗号化（HTTPS）通信の視え方

フロー生成機Flowmon Probeを利用することで、HTTPホスト名といったHTTP通信の情報を可視化することができますが、HTTPSの暗号化通信の場合はどうでしょうか。Flowmonでは、SSL/TLSハンドシェイクの拡張機能であるSNI（Server Name Indication）という情報からHTTPホスト名を取得しています。このSNIというのは、SSL/TLSハンドシェイクにおいてクライアント側が接続したいWebサイトを指定するための情報です。一般に、一つのWebサーバでは複数のWebサイトをホストしています。このような場合、同じIPアドレスに対して複数のサイトが、更にそれらのサーバ証明書もそれぞれ存在することになります。したがって、正しいサーバ証明書を送付するためにはHTTPホスト名をSSL/TLSハンドシェイクの時点で指定する必要があります。この役割を担うのがSNIとなります。クライアントからの接続要求を受け取ったサーバは、SNIを読むことでどのサイトの証明書を送付すべきなのかが分かります。このやり取りはSSL/TLSによる暗号化の前に行われるため、HTTPSの通信においてもFlowmonによってHTTPホスト名を取得することができます。
しかし、近年ではSNIのやり取りから暗号化を行うESNI（Encrypted SNI）と呼ばれるものも登場し、Flowmonでは現状これを可視化することはできません。このようなFlowmonを用いて可視化できる通信とできない通信について、来月公開予定のパート2で詳しく検証できればと思います。

おわりに

本コラムでは、HTTPS通信で用いられている共通鍵暗号、公開鍵暗号やサーバ証明書などの仕組みをご紹介しました。パート2のFlowmonにおけるHTTPS暗号化通信の可視化検証編の前知識にもなるかと思いますので、ご参考になれば幸いです。 パート2はこちらからご覧いただけます。

• 120秒でざっくりわかる製品紹介動画
• 20分でデモまで見られる製品紹介動画
• 30日間無償で試せる評価版

2025年2月3日

REST APIはアプリケーション間のデータ交換手段として広く利用されており、現代のWebサービスやアプリケーション開発を支える重要な基盤といえるでしょう。REST（REpresentational State Transfer）とはソフトウェアのアーキテクチャスタイルの一つであり、6つの基本原理（クライアント-サーバ、ステートレス、キャッシュ、統一インターフェース、階層型システム、コードオンデマンド）により定義されます。この設計理念に基づいたREST APIは、シンプルかつスケーラブルものとなります。
“RESTful”なAPIは、その柔軟性や拡張性の高さから第三者による二次利用のハードルを下げ、効率的なアプリケーション開発を実現します。現在では、多くの企業が自社サービスのAPIを公開しています。開発者はこれら既存のサービスを構成する「機能」を個別に「再利用」することで開発の手間を省き、様々なシステムを統合して新たなサービスを作り出すことも容易にできるのです。
本コラムでは、Flowmonが公開しているREST APIの一部をご紹介いたします。Flowmonをより便利に利用するシステムづくりのヒントになれば幸いです。

Flowmon REST APIガイド

FlowmonのWeb GUIから、公開されているREST APIガイドを確認することができます。ADSやFPIなどのプラグインモジュールも含めると300個以上のメソッドが公開されており、ブラウザ上からコマンドを送信することもできるためCLI操作に慣れていない方でも手軽にAPIを試していただけます。

トークン発行

APIコマンドを送信する際はユーザ認証のためのアクセストークンが必須となります。APIガイド上ではページ上部の「Authorize」ボタン、または各メソッドの右側にある南京錠マークをクリックすると認証情報を入力するポップアップが表示されます。

認証が成功すると、下図のように南京錠マークが閉じ、コマンドが実行できるようになります。

CLIで実行する場合は、下記のコマンドを使用してトークンを発行します。他のコマンドを送信する際に、取得したアクセストークンをcurlのヘッダーオプションとして付加します。なお、Flowmon OSでは自己証明書を用いており、そのまま実行しようとするとcurlのSSLエラーではじかれてしまうので、-kオプションを付ける必要があります。

curl -X 'POST' -k 'https://<flowmon_address>/resources/oauth/token' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'grant_type=password&client_id=invea-tech&username=<username>&password=<password>' | jq

画像はコマンドの実行例です。有効期限86400秒（24時間）のアクセストークンと、リフレッシュトークン（有効期限はデフォルトで2日間）が発行されました。

解析の実行

次のコマンドでは、Monitoring Centerの統計情報解析を実行します。に統計基準、に並べ替え基準、に集約といった形で、Web GUIでの解析と同様の条件指定をすれば問題ありません。

curl -X 'POST' -k 'https://<flowmon_address>/rest/fmc/analysis/statistics' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer <access_token>' \
  -d '{
    "search": {
      "from": "<start_time>",
      "to": "<end_time>",
      "profile": "<profile_id>",
      "channels": [
        "<channel_id#1>", "<channel_id#2>", ...
      ],
      "statistics": {
        "statistics": "<statistics>",
        "orderBy": "<order_by>"
      },
      "specific": {
        "aggregateBy": [
          "<aggregate_by#1>", "<aggregate_by#2>", ...
        ]
      },
      "filter": "<filter>"
    },
    "showonly": <number_of_displays>
  }' | jq

画像の実行例では、プロファイルに「All Sources（CLI上の表記はlive）」、統計基準に「IP通信（record）」を選び、「送信元IPアドレス（srcip）」及び「宛先IPアドレス（dstip）」で集約しています。このコマンドを送信すると、出力として解析結果のIDが返されます。

解析結果の確認は次のコマンドで行います。に前述のIDを入力することで、解析結果が出力されます。

curl -X 'GET' -k 'https://<flowmon_address>/rest/fmc/analysis/results/<result_id>' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer <access_token>' | jq

実行例では、通信の開始時間（ts）と期間（td）、送信元IP（srcip）、宛先IP（dstip）、パケット数（pkt）、バイト数（byt）、フロー数（fl）が確認できます。

Web GUIを用いて同じ解析を行った場合と見比べてみましょう。CLIでの解析と同じ結果が得られていることがわかりますが、バイト数の値が若干異なっているのはCLIではバイト単位、GUIではメビバイト（MiB、2の20乗バイト）単位で表示しているためです。

トラフィック量の出力

次のコマンドでは、トラフィック量を取得することができます。には出力したいトラフィック値として「traffic」や「packets」、「flows」が指定できます。また、は数字のID（0：すべて、1：ICMP、4：IPv4、6：TCP、等）で指定します。

curl -X 'POST' -k 'https://<flowmon_address>/rest/fmc/analysis/chart' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer <access_token>' \
  -d '{
    "search": {
      "from": "<start_time>",
      "to": "<end_time>",
      "profile": "<profile_id>",
      "channels": [
        "<channel_id#1>", "<channel_id#2>", ...
      ],
      "chart": {
        "measure": "<measure_value>",
        "protocol": <protocol_id>
      }
    }
  }' | jq

出力結果はプロファイルの粒度単位でのトラフィック量となり、実行例では5分粒度プロファイルで10分間を指定したため、5分ごとの値が2つ出力されています。

Web GUI上では、トラフィックグラフ上で同じ値を確認できます。

まとめ

本コラムではFlowmonのREST APIについてご紹介しましたが、ここでお見せしたコマンドはほんの一部です。ほかにもたくさんの機能があり、トラフィック状況に応じたネットワーク機器との外部連携やデータ出力のカスタマイズ、設定の自動化などアイデア次第で多様な活用方法が考えられます。Flowmonをもっと便利に使いたい！という際は、ぜひFlowmon REST APIをご活用ください。

• 120秒でざっくりわかる製品紹介動画
• 20分でデモまで見られる製品紹介動画
• 30日間無償で試せる評価版

2025年1月6日

現代のネットワーク環境において、トラフィックの可視化と分析はネットワーク管理者にとって必要不可欠な要素となっています。正確な分析を行うためには、トラフィック状況やリソースの使用状況など様々な情報が必要になります。ですが、分析データを収集して整理し、わかりやすい形式でまとめる作業には多くの労力を要し、定期的に発生するタスクは長い期間で考えると、実に多くの時間を費やすことになります。
本コラムでは、Flowmonのダッシュボード＆レポート機能を利用することで、これらの定期作業を効率的にする方法をご紹介させていただきます。

直感的な監視を実現するダッシュボード

Flowmonのダッシュボードの特徴は、何と言ってもその高いカスタマイズ性にあります。トラフィック量、プロトコル分析、アプリケーション使用状況など、必要な情報を一画面に集約して表示できます。気になるトラフィックデータをクリックすることで、該当の通信に絞り込み、詳細解析画面にシームレスに遷移することも可能です。そして、直感的な操作性もポイントの一つです。ドラッグ＆ドロップによるサイズ調整や配置変更が簡単に行えるため、運用管理者それぞれの好みに応じた使いやすい画面構成を構築できます。

レポート機能による業務効率化

レポート作成は運用管理者の重要な業務の一つですが、Flowmonはこの作業を大幅に効率化します。スケジューリング機能を利用することで日次・週次・月次等での定期レポートを自動作成できます。これにより、Flowmonへアクセスしなくても、重要なトラフィックのサマリーデータを定期的に取得することができますので、レポート作成業務に追われることなく、運用管理者の働き方改革にも貢献します。
レポートの出力先は、指定のメールアドレスへの送信や外部データストレージへの保存を選択できます。PDF/CSV形式でのエクスポートに対応しており、月次のトラフィック使用状況の記録や、定例会での報告資料として幅広く活用できます。また、過去のトレンド分析や監査対応の際にも、過去のレポートが有用なデータソースとなります。

レポートの定義方法

レポートを作成するためには事前にプロファイルを作成する必要があります。プロファイルとはFlowmonに保持されるフロー情報をあらかじめフィルタ条件で定義付けすることで、プロファイルデータとして管理し、複数のフロー情報をグルーピングする機能です。例えばLAN内の通信がセグメント単位で構成されている場合、プロファイルでグループ化することで拠点単位での通信の可視化を簡単に行うことができます。その他にもHTTPホスト名を指定すれば、該当アプリケーションの通信量や使用したユーザを特定することもでき、お客様のニーズに合わせたプロファイルを作成できます。プロファイルを基にレポートの出力内容を定義します。表示形式はTOP(n)形式かトラフィックグラフ形式から選択でき、必要な項目を組み合わせることで、情報量の豊富なレポートを作成できます。例えば、「利用の多いホストTOP10」や「拠点内での直近1週間のトラフィック量」といった具体的な分析ができます。また、出力内容や形式は複数パターンから選択できるため、既存で利用しているレポートから内容を大きく変更せずにFlowmonのレポートを作成することができます。

トラブルシューティングにおける活用事例

ネットワークの問題解決においてFlow分析は非常に効果的なアプローチとなります。ダッシュボードや定期的なレポートを活用することで、特定の時間帯におけるトラフィックがひっ迫していることや、特定のアプリケーションで頻繁に発生している遅延など、問題の兆候や原因を早期に発見できます。問題発生後にパケットを取得して解析するより効率的に問題の根本原因を把握できます。

最後に

Flowmonのダッシュボード＆レポート機能は、日々複雑化するネットワーク環境の可視化と効率的な運用管理を実現します。直感的な操作性によるスムーズな管理性と、自動化されたレポート作成機能を備えているため、日々の業務効率化に大きく貢献します。 今後ネットワーク環境がさらに複雑化していく中で、Flowmonは運用管理者にとって強力なパートナーとしての役割を果たすことが期待できます。

• 120秒でざっくりわかる製品紹介動画
• 20分でデモまで見られる製品紹介動画
• 30日間無償で試せる評価版

細かく相談されたい方は、こちらよりお気軽にお問い合わせください。
担当営業が直接Web会議ツールなどで製品のご案内をすることも可能ですので、お気軽にお申し付けください。

関連記事：

• Flowmonコラム: 見えないものを見える化！ネットワーク可視化の重要性
• Flowmonコラム: サンプリングレートによる解析結果の変化

2024年11月01日

はじめに

昨今、コンピュータ性能向上や利用目的の多様化、接続されるホスト数の増加により、ネットワークトラフィックは日々増大しています。ネットワーク監視やトラフィック解析のニーズも相まって、ネットワーク全体のトラフィックを可視化するためには大規模なストレージが求められるようになってきています。HDDの価格は一昔前に比べればはるかに安価となっていますし、またNetFlowの情報はパケットのヘッダー情報のみを参照する為、パケットキャプチャに比べればはるかにデータ量は少ないですが、有限なストレージを有効活用する為、Flowmonのお客様でもFlow生成時のパケットサンプリングを検討されることがあります。パケットサンプリングは一般的な技術として広く認知されていますが、信頼性はサンプリングレートの設定に大きく依存しており、適切な設定を行わないと解析結果が大きく変わってしまう可能性があります。パケットサンプリングについては、お客様からしばしばお問合せがありますが、適切な回答が難しく、改めて弊社環境を用いて検証しました。
※あくまでも弊社検証環境における結果であり、お客様の環境によっては異なる結果となる可能性があります。

サンプリングレートとは

まずサンプリングレートについて説明します。NetFlow界隈におけるパケットサンプリングとはトラフィックとして流れるパケットをどのような粒度で収集するかを決定するパラメータです。例えば、1:1000のサンプリングレートは、1000パケットに1つ、1:4000のサンプリングレートでは4000パケットに1つのパケットを収集しFlow化することを意味します。つまり、サンプリングレートが高いほど、参照されないパケットが増え、ネットワークの詳細情報は少なくなります。これにより、生成されるFlow数が少なくなりFlowを保存するストレージが節約できます。一方、サンプリングレートが低いと、詳細な情報が得られる代わりにFlow数が増え、大容量のストレージが必要になります。

検証内容及び前提

以下の前提で弊社環境でのデータをもとに、異なるサンプリングレートが解析結果に与える影響を検証します。
• 本検証では同一のトラフィックを、異なるサンプリングレートでFlow生成しA（サンプリングなし）とB（サンプリングレートを動的に変更）の差分を比較し百分率で表示する。
• A、B共にサンプリングレート0の場合の差分は0として扱う。
（補足）FlowmonでサンプリングされたFlowを受信した際の処理について
トラフィック量にパケット数にサンプリングレートの倍率を乗算することで実際に流れたトラフィック量として出力します。

検証結果・解釈

今回の検証ではサンプリングレートが高くなるほど誤差が大きくなり、事前に想定していた通りの結果となりました。低いサンプリングレートでは、比較的正確なトラフィックパターンを出力します。反対にサンプリングレートが高いと誤差は増加傾向となります。全体的なトレンドや傾向把握では大きな問題にはなりませんが、異常トラフィックを見逃す可能性が増加します。

実際の事例

まとめ

• 120秒でざっくりわかる製品紹介動画
• 20分でデモまで見られる製品紹介動画
• 30日間無償で試せる評価版

関連情報

コラム記事：
Flowmon製品のお客様評価
ランサムウエア検知でのADSのシナリオ
ランサムウェア脅威への対策

2024年8月1日

ネットワークは今日のビジネスにおいて業務効率化や生産性の向上を図るため、なくてはならない重要な基盤となっています。誰しもが当たり前に利用しているネットワークですが、その複雑さは日に日に増しており、状態を把握することは簡単ではありません。インターネットは毎日利用しているものの、ネットワーク可視化に手を付けていなかったり、SNMPでトラフィック量だけは見てはいるものの詳細がわからず、どんな通信が流れているかはわからないといったケースが少なくありません。

何か問題が起きた時には原因調査をすることになりますが、日ごろのトラフィック情報の有無でトラブルシュートにかかる時間は大きく変わります。私たちが毎年健康診断を受けるのと同じように、ネットワーク環境も定期的な診断が必要で、日常の通信状態を把握することで障害発生時に問題の所在を推測することができます。そこでネットワークを定常的に監視することの重要性についてお話させていただきます。

どういったものを可視化するのか

まずネットワークを運用していく上で、可視化しなければならない情報について考えてみたいと思います。 サーバーやネットワーク機器などのハードウェア情報、アプリケーションの応答情報、通信のトラフィック量などのソフトウェア情報、セキュリティ関連項目まで含めると膨大になることが想定されます。どれも重要な情報ではありますが、今回はその中でもFlowmonが最も得意とする通信の可視化にフォーカスを当てたいと思います。

ネットワーク可視化の目的

ネットワークを可視化する目的について考えてみたいと思います。極端な話ネットワークを可視化しなくても、何も問題が発生しない限り不都合はありません。イーサネットはすでに成熟した技術であり、監視していないからと言って即座にトラブルが起きることはありません。ですが、いざ問題が起きたときには、その複雑さ故、どこから手を付ければいいかわからない、何が原因かわからないといった声をよく聞きます。

障害を未然に防いだり、障害発生時に迅速な解決を行うためにはネットワーク状況の把握が不可欠です。この時、部分的に把握するだけでなくできるだけ広い範囲を可視化することで、ネットワーク全体像が見え、より俯瞰的に原因調査ができます。 日々変化するトラフィックや状態を見て、現在の構成やスペックが適切であるかがわかると障害になりそうな原因をあらかじめ防ぐことができ、万が一障害が発生した際にもどこで問題が発生したのかが一目でわかるため、原因の特定と適切な対応を行うことができます。

また、アクセス集中による輻輳なども把握することができます。混雑する時間帯がわかっていれば、作業を行う時間を分散させて通信の集中を防ぐことが可能ですし、トラフィック量がわかれば回線の増強や見直しを検討することができます。このように、見えないものを見える化することで様々なケースに対応できることがイメージいただけると思います。

ネットワーク可視化を実現するために

可視化ツールには様々なものがあります。SNMP監視、NetFlow、パケットキャプチャなど、それぞれメリット/デメリットがありますが、自社のネットワークに必要な製品を選択していただきたいと思います。

例えば、Flowmonが利用するNetFlowは通信のヘッダ情報を使用することで、送信元・宛先のIPアドレス、ポートなど詳細な解析が可能です。 NetFlowには様々なメリットがありますが、一番の特徴はデータ量が軽いということです。つまり広範囲のトラフィックを取得しても、長期保存することができるということです。

終わりに

ネットワーク可視化は、複雑化する現代のITインフラを効率的に管理するために欠かせません。自社のニーズに合った可視化ツールを選び、定期的にネットワークの状態を確認することで、問題を未然に防ぎ、快適なネットワーク環境を維持することができます。 次のステップとして、自社のネットワーク構成を確認し、どのような可視化が必要か検討してみましょう。

• 120秒でざっくりわかる製品紹介動画
• 20分でデモまで見られる製品紹介動画
• 30日間無償で試せる評価版

細かく相談されたい方は、こちらよりお気軽にお問い合わせください。
担当営業が直接Web会議ツールなどで製品のご案内をすることも可能ですので、お気軽にお申し付けください。

関連コラム記事：

• Flowmon製品のお客様評価
• Progress社技術担当役員へのインタビュー

2025年1月6日

Flowmonはセキュリティー監視となるアドオンコンポーネントADSにより、高度な振る舞い検知機構を提供しています。そのほか、無償のオプションとして、オープンソースのIDSソフトウエア Suricata を稼働させ、それにより検知されるイベントをFlowmonのイベント処理機構に組み入れることも可能となっています。このコラム記事では、Flowmon社ブログ Augmenting behavior-based network detection with signature-based methods を参照し、このIDS Probe（プローブ）機構をご紹介します。

Suricataの取り込みによる多角的な検知の実現

Flowmonはネットフロー形式に変換されたネットワークデータをもとに、さまざまな解析を行いITインフラの可視化を行います。またアドオンコンポーネントの一つとなるADS (Anormaly Detection System）を付加することで、セキュリティー視点からの多様なイベントの検知が可能となります。Flowmon ADSではメソッドという検知パターンが用意されており、IPのブラックリストの他、特定のネットワーク上の振る舞いを検知し、サイバー攻撃などと疑われるリスクのある動きをイベントとして通知します。

一方、さまざまな製品により同様の検知機構は提供されていますが、一般的には、個々の製品の検知ロジックの実装は異なるため、その異なるロジックによるイベント検知度合いには差があるものと見られています。そのためより検知度合いを高めるためには、複数の製品を利用することが考えられますが、そのための管理コストなどから現実的には困難が伴います。 このような背景から、Flowmonでは侵入検知で定評のあるオープンソースのSuricataをFlowmon上で稼働する仕組みを整え、そこからのイベントをFlowmonのイベント表示等に取り入れる機構を整備いたしました。これにより追加費用なくより網羅性の高いイベント検知を実現することが可能となります。

統合された検知機構の利点

IDSツールのSuricataをFlowmonに統合することで、両方の検出手法の効果を最大限に引き出しました。Suricataが生成するアラートをFlowmonの機能で処理し、関連付けし、視覚化するために、Flowmonでは関連機能の拡張を継続的に行なってまいりました。この統合化されたアプローチにより、以下のような利用者のメリットをご確認いただけます。

防御の強化

Flowmonによる振る舞い検知とシグネチャベースのSuricataによるイベント検出を組み合わせることで、より強力な防御が構築されます。これにより、脅威を広範囲にカバーし、既知の脅威と新たな脅威の両方を捕捉して、セキュリティーを強化します。

ツールの効率性

他ベンダー製品の利用などによる複数ツールの運用管理の必要性が減り、簡素化され、ライセンスのみならず全体のコストが最適化されます。

より深い洞察

異なるテクノロジーのセキュリティー製品の統合で、包括的な脅威の観点が提供され、既知の脅威に関する情報と異常なアクティビティーの情報がより詳細に提供されます。

信頼性の高いアラート

アラートを相互検証することで検出精度が向上し、誤検知が減少し、応答の信頼性が高まります。これにより対応の優先順位付けなど、後続のプロセスの最適化に有効です。

コンプライアンスの担保

複数の製品による診断結果を統合することで、業界の規制に適合し、包括的なセキュリティー対策を実施することが可能となります。

Flowmonは、その製品機能の複数のレベルでSuricataを組み込みました。ダッシュボードやレポートには、FlowmonおよびSuricata両方のシステムからの重要な情報が含まれ、セキュリティー意識を高め、最も重要なイベントに迅速に優先順位を付けて対応を計画することができます。

Suricataのイベントは、通常の分析ワークフローとドリルダウンに統合され、インシデント調査のプロセスも均一化します。Flowmon ADSは、両方のシステムからのイベントを関連付けて、ノイズを減らし、アラートの相互検証をサポートし、CVEの説明などの関連脆弱性情報などをご提供します。

Suricata構成概要

Suricataの導入および有効化は、以下のステップにより実施可能となっています。実際の導入構成の際には、こちらのオリジナル文書 How to enable signature-based detection in Flowmon Probe and Flowmon ADS もご参照ください。

1. IDS Probeパッケージの導入

サポートポータルのガイド（Flowmon IDS Probe ） に従い、Suricata IDS を Flowmon プラットフォームにインストールします。
※ スタンドアロン プローブで ADS を実行している場合は、以下の2つの手順（２と３）をスキップできます。

2. Syslog転送設定

IDS Probe（プローブ）を使用して、すべてのプローブで Syslogイベントロギングを設定します。 これにより、IDSイベントが Flowmon ADS を使用してターゲット コレクターに Syslog 経由でエクスポートされるようになります。 これは、[Configuration Center] > [システム] > [システム設定] > [Syslogイベントロギング] で設定できます。 ここでは、Syslogイベントロギングを有効にし、新しいサーバーを追加する必要があります。 次に、ADSでコレクターのIPアドレスを入力し、ポートとプロトコルを指定し、保存します。

3. Syslogサーバー構成

コレクター側では、Syslog サーバーを構成する必要があります。 [Configuration Center] > [システム] > [システム設定] > [Syslogサーバ] に移動します。 外部Syslogを有効にし、新しいSyslogクライアントを追加します。 FlowmonプローブのIPアドレスを入力し、同じポートとプロトコルを使用して保存します。

4. ADSの有効化設定

プローブはSyslog経由でIDSイベントを送信し、コレクターはそれを受信していますが、それを処理、保存、視覚化する設定を行う必要があります。ADSの[設定]に移動し、[システム設定] > [IDSコレクター] で [有効化]ボタンをクリックします。 これが完了すると、[分析]ページで IDSイベントを確認できるようになります。

その他、Suricata IDS の実行に際しては Suricata IDS Configuration and Tuning をご参照ください。 ガイドより、誤検知の調整、検出ルールの管理、ネットワーク変数の設定、独自のカテゴリの作成など、Suricataを有効に利用する上での詳細をご確認いただけます。

終わりに

NDRツールで、振る舞い検知などの動作ベースの検出方法と、シグネチャベースの検出方法を組み合わせることが、サイバーセキュリティーを強化するための重要な取り組みの一つとなります。この組み合わせにより、さまざまな脅威に対する強力な防御機構が整い、重要な洞察が得られ、アラートの精度が向上することとなります。

IDSツールのSuricataは、Flowmon ADSにより無料のモジュールとして利用できます。導入のための新たな設定は不要で、簡単なインストール手順により、利用を開始することができます。 なお、Suricataはオープンソースのため、Flowmonの保守サポート対応範囲外となります。予めご了承ください。

• 120秒でざっくりわかる製品紹介動画
• 20分でデモまで見られる製品紹介動画
• 30日間無償で試せる評価版

細かく相談されたい方は、こちらよりお気軽にお問い合わせください。
担当営業が直接Web会議ツールなどで製品のご案内をすることも可能ですので、お気軽にお申し付けください。

関連記事：

• オープンソース Suricata: ホームページ
• Flowmon社ブログ: Beyond Traditional Defenses: Integrating IDS and NDR for Improved Detection Capabilities

2024年12月2日

クラウドの一般化した昨今のIT環境では、オンプレミス環境と統合されたハイブリッドIT基盤に対する、効率的なモニタリングやセキュリティー監視が重要なテーマとなっています。この記事はFlowmon社ブログ Multi-Cloud – Rise of Hybrid Networks and the Need to Monitor & Secure Them をベースとし、その課題とFlowmonによる対応について書かれています。

ハイブリッド環境の監視の課題

現行の多くの企業で利用されているIT基盤は、自社内のITシステムとAWS,Azure, Googleなどの大手クラウドサービスを複合的に利用する形態が一般的です。またそれらクラウドサービスでも、アプリケーションによっては異なるクラウドサービス基盤で利用されている場合や、災害対策やコストの最適化などの観点で複数のクラウドサービスに分散されることもあります。今後もこの複合的なIT基盤は広く普及してゆくものと予想されています。

この分散IT環境は、様々な視点から最適化のメリットがありますが、同時にIT基盤の監視やセキュリティーという面では課題があります。ダイナミックにITリソースを再配置したり、物理的な把握が難しいクラウド環境に対して、固定的なオンプレミスのIT基盤管理手法を適用することは困難です。 統合的な監視ができていないそれらの複合環境では、環境ごとに異なるツールで個々の状況を把握し、そこで取得されたそれぞれのデータを手動で統合しなければなりません。手動で統合されたデータにより、最終的に自社のIT基盤の状態を把握するというステップは、IT部門にとってはかなりの負担となります。

これら大手のクラウドサービスでは、それぞれ独自の監視機能を提供しています。ただしその設定の複雑さやキャプチャーされた膨大な監視トラフィックデータの保存など、別の側面で課題があります。独自ツールはそのクラウドサービス特有のトラフィック監視には強力ですが、他のクラウドサービスを含めた横断的なトラフィック監視が必要とされる場合、その特有さが問題となってしまいます。

ハイブリッド環境の監視の簡素化

主なクラウドサービスでは、個々に持つ独自のトラフィック監視の仕組みの他、外部の監視ツールが活用できるデータ（フローログ）を提供する仕組みが実装されています。フローログはNetFlowデータと同等の情報を含んでおり、Flowmonのような外部システムが、オンプレミス環境のみならず、様々なクラウド環境も包含した分析処理を実現します。これにより個々のクラウド環境に依存しない外部システムが、オンプレミス環境のみならず、様々なクラウド環境も包含した分析処理が実現されます。

これらのクラウド基盤から提供されるフローログにより、Flowmonのプラットフォームを横断した解析・レポート機能に組み込み、統合的な可視化が可能となります。各クラウドが個別に提供する監視オプションを使用するよりも、低コストでハイブリッドなマルチクラウド監視を行うことができます。また必要に応じFlowmonプローブも構成に加えることで、アプリケーションレベルの可視化まで、その監視範囲を広げることも可能です。

構成概要

下図は、Flowmonのハイブリッド展開の全体的なイメージを示しています。 ここではクラウドプラットフォームからのネイティブフローログと組み合わせ、ハイブリッドネットワーク内の異なる場所にあるプローブからメタデータを収集する、中央アグリゲーターとしてFlowmonコレクターが構成されています。

また、以下の場合には、展開に際してFlowmonプローブを含める必要があります。

• 高度なネットワーク分析とネットワークパフォーマンスメトリックのための信頼性の高い正確なデータが必要な場合。
• ネットワークトラフィックの詳細な可視性が必要で、アプリケーション層の可視性（L7プロトコル）も含まれる場合。
• Flowmon Application Performance Monitoring（APM）やFlowmon Packet Investigator（FPI）などの高度な機能が必要な場合。

Flowmonブログ記事 How to Optimize Cloud Monitoring Costs Using Flow Logs in Progress Flowmon では、このトピックを詳しく解説し、Google CloudでのFlowmonプローブとフローログの利用に基づいてコストを比較しています。フローログを利用することで、最大で89%のコスト削減が可能です。

終わりに

複数のクラウドプロバイダーを使うことが多くの企業にとって新しい標準になっています。IT部門がすべてのパブリックプロバイダーやオンプレミスインフラをしっかり把握できるように、統合された使いやすい監視ソリューションが重要です。Flowmonのネットワーク監視ソリューションは、各プラットフォームのネイティブ監視ツールよりも格段に低コストでこの課題を解決します。

Flowmonのバージョン12は、AWS、Azure、Google Cloudが提供する全ての既存のネットワークテレメトリーソース（VPCフローログ）と、ルーターやスイッチ、パケットブローカーなどの標準的なオンプレミスフローソースを活用できる業界初のソリューションです。Flowmonは、既存のネットワークテレメトリーソースを利用するか、専用の軽量Flowmonプローブを使うことで、クラウドとオンプレミス環境に対して優れた可視性を提供します。これは、単一の画面でハイブリッド環境に一貫したレベルのネットワーク可視性を提供いたします。

• 120秒でざっくりわかる製品紹介動画
• 20分でデモまで見られる製品紹介動画
• 30日間無償で試せる評価版

細かく相談されたい方は、こちらよりお気軽にお問い合わせください。
担当営業が直接Web会議ツールなどで製品のご案内をすることも可能ですので、お気軽にお申し付けください。

関連記事：

• Flowmonコラム: クラウドネットワーク可視化の課題
• Flowmonコラム: マルチクラウド戦略を支えるFlowmon 12について