Cato は DHCP をどのように使用してデバイスを識別するか

この記事では、Cato が DHCP メッセージを使用してネットワーク内のデバイスを識別および分類する方法と、DHCP 配置の選択がデバイスインベントリページに表示されるデバイスデータとファイアウォールルールで利用可能なデータにどのように影響するかを説明しています。

概観

デバイスインベントリエンジンは、WANバウンドおよびアウトバウンドトラフィックを分析して、ネットワーク内のデバイスを発見し、識別し、分類します。 IoT/OT セキュリティサービスや Cato 管理アプリケーション (CMA) でのデバイスインベントリの使用方法については、デバイスインベントリとは？を参照してください。.

エンジンは、DHCP、HTTP、MAC、TCP/IP、およびFTPを含むさまざまな識別プロトコルを使用します。しかし、DHCPはデバイスデータを取得するための最も価値のあるプロトコルです。 DHCP交換の際、デバイスは自分のMACアドレス、しばしばホスト名、そしてOSに関するヒントを発表します。これは、デバイスがネットワークに参加するか、リースを更新するときに予測可能なスケジュールで発生します。 Catoはこのデータを利用して、MACアドレス、メーカー、デバイス名、デバイスIPなどの属性をデバイスに対して設定し、その後、ファイアウォールルールのデバイス属性条件として利用可能になります。ファイアウォールルールでデバイスデータを使用する詳細は、デバイス条件をファイアウォールルールに追加するを参照してください。

CatoがDHCPデータにアクセスするには、CatoがDHCPメッセージパス上にいなければなりません。 CatoがDHCPサーバーまたはネットワーク範囲のDHCPリレーである場合、Cato Cloudは処理するDHCPメッセージを読み込み、抽出した識別子をデバイスインベントリエンジンに入力します。

注：

• デバイス属性条件を利用したファイアウォールルールは、MACアドレスが検出されたデバイスにのみ適用されます。実際には、これはDHCPを通じて確認されたデバイスを意味します。 Catoは、MACアドレスの検出を保証するために、Cato DHCPサービスを使用するようサイトを構成することを推奨します。

• デバイスインベントリに保存されているMACアドレスは、イーサネットフレームのヘッダーからではなく、DHCPメッセージのペイロード（chaddr）から取得されます。中間のDHCPリレー、ルーター、およびソケットは、この値を上書きしません。

DHCPメッセージパスがデバイスデータの取得に与える影響

サイトネットワーク範囲内のクライアントがIPアドレスを必要とする場合、DHCP DISCOVERメッセージを送信します。これが発生したときにCatoが目にするものは、範囲に対してDHCPがどのように構成されているかに依存します：

• Cato CloudをDHCPサーバーとして使用する - CMAでDHCP範囲設定で範囲が構成されている場合、Cato PoPがDHCPサーバーです。範囲内のすべてのDISCOVER、REQUEST、RENEW、およびRELEASEはPoPに配信され、IPアドレスを割り当ててペイロードを解析します。このモードは、最も完全で最新のデバイスデータを生成します。

• DHCPリレーとしてのCato - 範囲がDHCPリレー設定で構成されている場合、データセンター内のMicrosoft DHCPサーバーなどのDHCPサーバーがリースを割り当てます。 Catoソケットは、クライアントとサーバーの間でDHCPメッセージを中継し、その間にペイロードを読み取ります。
  注: Cato は、Cato Socket が DHCP リレー エージェントでない場合でも、Cato クラウドを通過する DHCP リレー メッセージから DHCP 識別子を抽出することができます。これは、リレートラフィックが Cato を経由して DHCP サーバーに到達する場合に適用されます。

• LAN上でローカルに提供されるDHCP - ローカルルーター、サードパーティのアクセスポイント、またはWindows ServerなどのサードパーティのDHCPサーバーは、Catoによる中継なしで同じブロードキャストドメインのクライアントに応答します。これらのDHCPメッセージはLANを離れることなく、Catoには見えません。この範囲上のデバイスは、WANバウンドトラフィックを介してデバイスインベントリに表示される場合がありますが、通常は限定的なデータ（MACアドレス、メーカー、ホスト名なし）であり、デバイス属性の条件を使用したファイアウォールルールは適用されません。

Catoが処理する各DHCPメッセージについて、次のフィールドから識別子を抽出し、それらをデバイスプロファイルに入力します：

CatoはこれらのDHCP由来の属性を他のプロトコルの信号やWANバウンドトラフィックの行動分析と組み合わせて分類を洗練します。

デバイス識別のためのDHCPの構成

各サイトでデバイスインベントリエンジンがデバイスを識別できるようにするために、監視したい各ネットワーク範囲のDHCPメッセージパスにCatoが位置するようにDHCPを構成します。 2つのモードのいずれかを使用できます。

CatoをDHCPサーバーとして使用する（推奨）

このモードでは、Cato Cloudはネットワーク範囲のクライアントにIPアドレスを割り当て、すべてのDHCPメッセージを直接読み取ります。

注意：

デバイス識別範囲と運用のシンプルさの両方のために、このモードをCatoが推奨します。詳細については、DHCPの推奨事項を参照してください。

Cato CloudをDHCPサーバーとして使用する方法の詳細については、DHCP設定の構成をご覧ください。

CatoをDHCPリレーとして使用する

独自のDHCPサーバー（例：集中化されたMicrosoft DHCPサーバー）を保持したい場合でも、CatoがDHCPメッセージを見ることができるようにこのモードを使用します。
CatoをDHCPリレーとして使用する詳細については、DHCPリレーとしてのCatoの構成を参照してください。

DHCPベースのデバイスデータが表示される場所

Catoは、次のCMAページでDHCPに由来する識別子を使用します：

• デバイスインベントリ - 上記のDHCPフィールドからMACアドレス、メーカー、デバイス名、およびデバイスIP列が埋められます。デバイスのクイックビューを開いて、MACアドレスと完全な属性リストを確認します。詳しくは、デバイスインベントリページの使用 をご覧ください。

• WAN、インターネット、LANファイアウォールルールベース - デバイスインベントリエンジンによって識別された値は、ルールのデバイス属性条件内で選択可能な値になります。デバイス属性条件を使用したルールは、MACアドレスが検出されたデバイスにのみ適用されます。

既知の制約

[デバイスインベントリページの使用]で記載された制限（3日間のエイジング、多ID分割、共有ID衝突）に加えて、DHCPベースの識別には以下の制限があります：

• 静的IPデバイスはDHCP信号を出しません。静的IPアドレスを持つデバイスはDHCPメッセージを送信しないため、デバイスインベントリにはMACアドレスがなく、デバイス属性条件を使用するファイアウォールルールと一致しません。

• ローカルで提供されるDHCPはCatoにとって不可視です。 DHCPがLAN上のデバイスによって提供され、それがDHCPメッセージをCato Cloud（サーバーとしてまたはリレーとして）に送信しない場合、CatoはそれらのメッセージからデバイスIDを抽出することはできません。

• MACランダム化。モダンなオペレーティングシステム（iOS、Android、Windows 11、macOSの最近のバージョン）は、ネットワークごとにランダム化されたMACアドレスを提示できます。ランダム化されたMACアドレスには実在のメーカーに対応するOUIがなく、同じ実物のデバイスが異なるネットワークで異なるMACアドレスで現れる可能性があります。

• DHCPスヌーピングやオプション82の書き換え。クライアントとCatoソケットの間のデバイスがDHCPメッセージを変更した場合（例: オプション82を追加する、またはchaddrを変更する）、デバイスインベントリに格納される識別子はその変更を反映します。

関連記事

• デバイスインベントリとは何か？

• デバイスインベントリページの使用方法

• DHCP設定の設定

• CatoをDHCPリレーとして設定する

• DHCPの推奨事項

• ファイアウォールルールへのデバイス条件の追加