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

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

概観

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

エンジンは、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メッセージについて、次のフィールドから識別子を抽出し、それらをデバイスプロファイルに入力します：

DHCPフィールド	デバイスインベントリ属性
クライアントハードウェアアドレス（`chaddr`）	MACアドレス - デバイスレコードのアンカーであり、デバイス属性ファイアウォールルールの前提条件です。
MAC OUI（最初の24ビット）	IEEE OUIレジストリから派生した初期メーカー。
割り当てまたは要求されたIPアドレス	デバイスIP、および後のトラフィックをデバイスに帰属させるために使用されるIP-to-MACバインディング。
オプション12（ホスト名）	デバイス名、クライアントが広告した場合。
オプション55（パラメータリクエストリスト）	OSおよびOSバージョンの識別に貢献します。
オプション60（ベンダークラス識別子）	ベンダークラスを広告するデバイス（IoTやOTデバイス、プリンタ、VoIP電話、カメラなど）のためのタイプ、メーカー、およびモデルを洗練します。

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

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

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

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

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

注意事項:

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

Catoを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を書き換える）、デバイスインベントリに格納される識別子はその修正を反映します。