第19章 アドレス オブジェクトの設定


ネットワーク > アドレス オブジェクト

アドレス オブジェクトは、SonicOS の4つのオブジェクト クラス (アドレス、ユーザ、サービス、スケジュール) の1つです。アドレス オブジェクトを使用することで、1度定義したエンティティをSonicOSインターフェース全体の複数の参照インスタンスで再利用することができます。例えば、IPアドレスが67.115.118.80の内部ウェブ サーバがあるとします。アクセス ロールやNATポリシーを作成する際にIPアドレスを繰り返し入力するのではなく、アドレス オブジェクトを使用して、例えば“マイ ウェブ サーバ”という1つのエンティティをIPアドレス67.115.118.80のホスト アドレス オブジェクトとして作成します。この“マイ ウェブ サーバ”アドレス オブジェクトは、アドレス オブジェクトを定義条件として使用する任意の設定画面で、ドロップダウン メニューから簡単に選択できます。

アドレス オブジェクトの種類

ネットワーク アドレスの表現にはさまざまな種類があるため、現在は以下の種類のアドレス オブジェクトが用意されています。


・ ホスト - IPアドレスによって1つのホストを定義するホスト アドレス オブジェクト。ホスト アドレス オブジェクトのサブネット マスクは、単独のホストを識別できるように自動的に32ビット (255.255.255.255) に設定されます。例えば、“マイ ウェブ サーバ”のIPアドレスが“67.115.118.110”のとき、既定のネットマスクは“255.255.255.255”になります。

・ 範囲 - 連続するIPアドレスの範囲を定義する範囲アドレス オブジェクト。範囲アドレス オブジェクトにはサブネット マスクは関連付けられませんが、内部ロジックでは通常、指定範囲の各アドレスは32ビットでマスクされたホスト オブジェクトとして扱われます。例えば、“マイ公開サーバ”の開始IPアドレスが“67.115.118.66”、終了IPアドレスが“67.115.118.90”であるとします。この場合、この範囲にある25個のホスト アドレスはすべて、この範囲アドレス オブジェクトに含まれます。

・ ネットワーク - ネットワーク アドレス オブジェクトは、複数のホスト アドレスで構成されているという点では範囲オブジェクトと似ていますが、アドレスの上限と下限を指定するのではなく、有効なサブネット マスクによってアドレスの境界を定義します。ネットワーク アドレス オブジェクトは、ネットワークのアドレスとそれに対応するサブネット マスクによって定義する必要があります。例えば、ネットワーク値が“67.115.118.64”、サブネット マスクが“255.255.255.224”の“マイ公開ネットワーク”のアドレスは、67.115.118.64~67.115.118.95になります。一般的なルールとして、ネットワークの最初のアドレス (ネットワーク アドレス) およびネットワークの最後のアドレス (ブロードキャスト アドレス) は使用できません。

・ MACアドレス - MACアドレス オブジェクトを使用することで、ハードウェア アドレス、つまりMAC (メディア アクセス コントロール) アドレスによってホストを識別できます。MACアドレスは、ハードウェアの製造元によって有線または無線のすべてのネットワーク機器に個別に割り当てられており、変更できないようになっています。MACアドレスは、6バイト16進数形式で表記される48ビット値です。例えば、“マイ アクセス ポイント”のMACアドレスは“00:06:01:AB:02:CD”などとなります。MACアドレスは、セキュリティ装置のARPキャッシュを参照することでIPアドレスに解決されます。MACアドレス オブジェクトは、SonicOSのさまざまな無線設定コンポーネントで使用されます。

・ FQDNアドレス - FQDNアドレスを使用することで、例えば“www.sonicwall.com”など、ホストの完全修飾ドメイン名 (FQDN) を使ってホストを指定することができます。FQDNは、セキュリティ装置の設定で指定されているDNSサーバを使用してIPアドレスに解決されます。ワイルドカード エントリもサポートされており、ワイルドカードを指定すると、承認済みDNSサーバへの問い合わせに対する応答が収集されるようになります。

アドレス オブジェクト グループ

SonicOS には、アドレス オブジェクトをアドレス オブジェクト グループにグループ化する機能があります。アドレス オブジェクトのグループを定義することで、参照の効率を向上させることができます。グループは、ホスト アドレス オブジェクト、範囲アドレス オブジェクト、ネットワーク アドレス オブジェクトを任意に組み合わせて構成できます。MACアドレス オブジェクトは別にグループ化する必要がありますが、IPベースのアドレス オブジェクトのグループにMACアドレス オブジェクトを追加すること自体は安全です。IPアドレス オブジェクトのグループに追加されたMACアドレス オブジェクトは、処理のコンテキストにおいてその参照が無意味なとき (NATポリシーの場合など) には無視されます。たとえは、“マイ公開グループ”にはホスト アドレス オブジェクトである“マイ ウェブ サーバ”と、範囲アドレス オブジェクトである“マイ公開サーバ”を含められるので、IPアドレス67.115.118.66~67.115.118.90、およびIPアドレス67.115.118.110を効率的に表すことができます。

アドレス オブジェクトの作成と管理

ネットワーク > アドレス オブジェクト」ページでは、アドレス オブジェクトの作成と管理を行えます。

表示形式」メニューを使って、以下の方法でアドレス オブジェクトを表示できます。


・ すべてのアドレス オブジェクト - 設定済みのすべてのアドレス オブジェクトを表示します。

・ ユーザ定義アドレス オブジェクト - ユーザ定義のプロパティを持つアドレス オブジェクトを表示します。

・ 既定のアドレス オブジェクト - SonicWALLセキュリティ装置に既定で設定されているアドレス オブジェクトを表示します。

アドレス オブジェクトを並べ替えることで、SonicWALLセキュリティ装置に設定されているアドレス オブジェクトを簡単に探すことができます。

補足 アドレス オブジェクトは、NATポリシー、アクセス ルール、サービスを設定する前に定義する必要があります。

アドレス オブジェクトとアドレス グループ エントリのナビゲートと並べ替え

「アドレス オブジェクト」テーブルと「アドレス グループ」テーブルは、多数のアドレス オブジェクトやアドレス グループを表示できるように簡単にページ付けすることができます。テーブルの右上にあるナビゲーション コントロール バーを使用して、「アドレス オブジェクト」テーブルまたは「アドレス グループ」テーブルに表示された多数のエントリをナビケートできます。ナビゲーション コントロール バーには4つのボタンがあります。左端のボタンは、テーブルの最初のページを表示します。右端のボタンは、最後のページを表示します。内側の左矢印ボタンと右矢印で、それぞれ前または次のページに移動します。

表示範囲」フィールドにポリシー番号 (「#名前」カラムにおいてポリシー名の前に記載されている番号) を入力することにより、特定のエントリに移動できます。既定のテーブル設定では、ページあたり50個のエントリが表示されます。この既定のテーブル エントリ数は、「システム > 管理」ページで変更できます。

テーブルのエントリを並べ替えるには、列見出しを選択します。エントリは昇順または降順で並べ替えられます。列エントリの右側にある矢印が、並べ替え状況を示します。下向きの矢印は昇順を意味します。上向きの矢印は降順を示します。

既定のアドレス オブジェクトおよびアドレス グループ

既定のアドレス オブジェクト」表示では、SonicWALLセキュリティ装置の既定のアドレス オブジェクトおよびアドレス グループが表示されます。「既定のアドレス オブジェクト」エントリは、変更や削除ができません。そのため、既定エントリの編集アイコンと削除アイコンは淡色表示になります。

アドレス オブジェクトの追加

アドレス オブジェクトを追加するには、「すべてのアドレス オブジェクト」表示または「ユーザ定義アドレス オブジェクト」表示の「アドレス オブジェクト」テーブルの下にある「追加」ボタンを選択して、「アドレス オブジェクトの追加」ウィンドウを表示します。
手順 1  このネットワーク オブジェクトに付ける名前を「名前」フィールドに入力します。
手順 2 タイプ」メニューで、「ホスト」、「範囲」、「ネットワーク」、「MAC」、または「FQDN」を選択します。

・ 「ホスト」を選択した場合、「IPアドレス」フィールドと「サブネット マスク」フィールドにIPアドレスとサブネット マスクを入力します。

・ 「範囲」を選択した場合、「開始アドレス」フィールドと「終了アドレス」フィールドに開始アドレスと終了アドレスを入力します。

・ 「ネットワーク」を選択した場合、「ネットワーク」フィールドと「サブネット マスク」フィールドにIPアドレスとサブネット マスクを入力します。

・ 「MAC」を選択した場合、「ネットワーク」フィールドと「MACアドレス」フィールドにMACアドレスとサブネット マスクを入力します。

・ 「FQDN」を選択した場合、「FQDNホスト名」フィールドに単独のサイトのドメイン名または一連のサイトのドメイン名 (ワイルドカードを使用) を入力します。
手順 3 ゾーンの割り当て」メニューで、アドレス オブジェクトに割り当てるゾーンを選択します。

アドレス オブジェクトの編集と削除

アドレス オブジェクトを編集するには、「アドレス オブジェクト」テーブルの「設定」カラムにある編集アイコン を選択します。「アドレス オブジェクトの編集」ウィンドウが開き、「アドレス オブジェクトの追加」ウィンドウと同じ設定項目が表示されます。

アドレス オブジェクトを削除するには、「設定」カラムで、削除するアドレス オブジェクトに対応する削除アイコン を選択します。削除を確認するダイアログ ボックスが表示されます。「OK」を選択すると、アドレス オブジェクトが削除されます。アクティブなアドレス オブジェクトを複数削除するには、削除するアドレス オブジェクトを選択して「削除」ボタンを選択します。

グループ アドレス オブジェクトの作成

SonicWALLセキュリティ装置に追加されたアドレス オブジェクトの数が増えてきたら、アドレスのグループを作成することで、アドレスやアクセス ポリシーの管理を容易にすることができます。グループに加えた変更は、グループ内の各オブジェクトに適用されます。アドレス オブジェクトのグループを追加するには、以下の手順を実行します。

手順 1 グループの追加」を選択して、「アドレス オブジェクト グループの追加」ウィンドウを表示します。
手順 2  グループの名前を「名前」フィールドに入力します。
手順 3  リストから「アドレス オブジェクト」を選択して、右向きの矢印を選択します。そのオブジェクトがグループに追加されます。Ctrlキーを押しながら選択すると、複数のオブジェクトを選択できます。
手順 4 OK」を選択します。
ヒント グループからアドレスまたはサブネットを削除するには、右側のカラムでIPアドレスまたはサブネットを選択して、左向きの矢印を選択します。選択した項目が右側のカラムから左側のカラムに移動されます。

アドレス グループの編集と削除

グループを編集するには、編集アイコンを選択します。

グループを編集するには、「アドレス グループ」テーブルの「設定」カラムにある編集アイコン を選択します。「アドレス オブジェクト グループの編集」ウィンドウが表示されます。変更を加えた後、「OK」を選択します。

アドレス グループを個別に削除するには、「設定」カラムにある削除アイコン を選択します。削除を確認するダイアログ ボックスが表示されます。「OK」を選択すると、アドレス グループが削除されます。アクティブなアドレス グループを複数削除するには、削除するアドレス グループを選択して「削除」ボタンを選択します。

公開サーバ ウィザード

SonicOS には、SonicWALLセキュリティ装置を公開サーバ用に設定する作業を自動化する公開サーバ ウィザードが用意されています。このウィザードは、例えば、ネットワーク上の電子メール サーバおよびウェブ サーバをインターネット上のユーザがアクセスできるように公開する場合などに使用できます。

公開サーバ ウィザードを使用すると、サーバの種類 (HTTP、FTP、電子メール)、プライベート (外部) アドレス オブジェクト、公開 (内部) アドレス オブジェクトを選択または定義できます。サーバの種類、プライベート ネットワーク オブジェクト、公開ネットワーク オブジェクトを設定すると、セキュリティ装置にそのサーバ用の適切なNATポリシー エントリおよびアクセス ルール エントリが作成されます。SonicWALL管理インターフェースを使って、その他の設定オプションも指定できます。

ウィザードを使用してSonicWALLセキュリティ装置を設定する手順の詳細については、第22部「ウィザード」を参照してください。

動的アドレスの使用

SonicOS では初期のバージョンから常に、ユーザ インターフェースのほとんどの領域において、IPアドレスを表すためにアドレス オブジェクト (AO) が使われてきました。アドレス オブジェクトは以下の種類に分類されます。


・ ホスト - 個々のIPアドレスと、それに関連付けられているサブネット マスクおよびゾーン。

・ MAC (旧バージョン) - メディア アクセス コントロール (イーサネット ホストに割り当てられている固有のハードウェア アドレス)。MAC AOはSonicOS 2.5で初めて導入され、最初は以下の目的で使用されていました。

・ SonicPointを識別する

・ ホストにおいて、ゲスト サービスの認証をバイパスできるようにする

・ 無線スキャンで検出された無線アクセス ポイントのBSSID (基本サービス セット識別子、WLAN MAC) を許可する
導入当初のMAC AOは、管理インターフェースの他の領域 (アクセス ルールなど) ではターゲットとして指定することが許可されていなかったため、初期のバージョンでは、ホストのアクセスをハードウェア アドレスによって制御する目的で使用することはできませんでした。

・ 範囲 - 開始アドレスと終了アドレスによって指定される特定範囲内のすべてのIPアドレス。

・ グループ - さまざまな種類のアドレス オブジェクトをまとめて扱うためのアドレス オブジェクトの集まり。グループには、他のグループ、ホスト、MAC、範囲、またはFQDNのアドレス オブジェクトを含めることができます。

SonicOS 3.5ではMAC AOの動作が再定義され、完全修飾ドメイン名 (FQDN) AOが導入されました。


・ MAC - SonicOS 3.5以降では、SonicWALL上のARPキャッシュを参照することによって、MAC AOがIPアドレスに解決されます。

・ FQDN - 完全修飾ドメイン名 (例えば“www.reallybadwebsite.com”など) は、SonicWALLの設定で指定されているDNSサーバを使用して (1つまたは複数の) IPアドレスに解決されます。ワイルドカード エントリもサポートされており、ワイルドカードを指定すると、承認済みDNSサーバへの問い合わせに対する応答が収集されるようになります。

アドレス オブジェクトの作成は単にIPアドレスを入力するよりも手間がかかりますが、アドレス オブジェクトはSonicOS の管理機構を補完する目的で実装されており、それによって以下の特徴が実現されています。


・ ゾーンの関連付け - ホスト、MAC、およびFQDNのアドレス オブジェクトを定義する際は、明示的にゾーンを指定する必要があります。インターフェースのほとんどの領域 (アクセス ルールなど) では、指定されたゾーンは参照のためにしか使われません。指定されたゾーンが機能上の目的で使用されるのは、「アドレス オブジェクト」ドロップダウン リストの項目をコンテキストに合わせて正確に表示するために利用される場合と、ユーザおよびグループに割り当てる“VPNアクセス”を定義する場合です。アドレス オブジェクトを使用してVPNアクセスを定義する際には、アクセス ルール自動作成プロセスによってアドレス オブジェクトのゾーンが参照され、そのルールを割り当てるべきVPN[ゾーン]の共通部分が適切に決定されます。例えば、LANゾーンに属する“192.168.168.200ホスト”というホスト アドレス オブジェクトが“Trusted Users”ユーザ グループの“VPNアクセス”に追加された場合、自動的に作成されるアクセス ルールはVPN LANゾーンに割り当てられます。

・ 管理と処理 - 多用途の種別に属するアドレス オブジェクト群はSonicOS インターフェース全域で容易に使用できるため、(アクセス ルールなどからの) ハンドルの定義と管理を簡便に行うことができます。また、アドレス オブジェクト グループのメンバーは単純な操作によって簡単に追加または削除できるので、それを参照するルールやポリシーを直接操作する必要なしに、ルールやポリシーの内容を効率的に変更することができます。

・ 再利用性 - オブジェクトを定義する必要があるのは一度だけで、定義したオブジェクトは必要に応じて何度でも容易に参照できます。

動的アドレス オブジェクトの主要な機能

動的アドレス オブジェクト (DAO) とは、MAC AOおよびFQDN AOの使用を可能にする基底フレームワークのことを表す用語です。「ファイアウォール > アクセス ルール」は、アドレス オブジェクトを静的な構造から動的な構造に変換することによって、ネットワークの変化に自動的に対応できます。

補足 当初の段階では、SonicOS 4.0、5.0および5.1で動的アドレス オブジェクトがサポートされるのはアクセル ルール内のみです。SonicOS の将来のバージョンでは、NATやVPNなどのその他のサブシステムにもDAOのサポートが導入される可能性があります。

機能
利点
FQDNワイルドカードのサポート FQDNアドレス オブジェクトでは“*.somedomainname.com”のようなワイルドカード エントリがサポートされています。ワイルドカード エントリが指定された場合は、まず基本ドメイン名が解決されて、それに対して定義されているすべてのホストIPアドレスに変換され、その後、ファイアウォールを通過するDNS応答のアクティブな収集が継続的に行われます。
例えば、“*.myspace.com”のFQDN AOを作成すると、まずファイアウォールの設定で指定されているDNSサーバが使用されて、“myspace.com”が63.208.226.40、63.208.226.41、63.208.226.42、63.208.226.43に解決されます (このことは
nslookup myspace.com、またはそれと同等のコマンドによって確認できます)。ほとんどのDNSサーバではゾーン転送は許可されないので、通常はドメイン内のすべてのホストを自動的に列挙することはできません。それに代わる方法として、SonicWALLは、ファイアウォールを通過するDNS応答を監視して、承認済みDNSサーバから発信されたDNS応答を探します。そのため、ファイアウォールの背後のホストが外部DNSサーバに対して問い合わせを行った場合、そのサーバがSonicWALL上の設定済み/定義済みDNSサーバであるときには、その応答がSonicWALLによって解析され、いずれかのワイルドカードFQDN AOのドメインに一致するかどうかが調べられます。
補足:“承認済みDNSサーバ”とは、SonicWALLファイアウォールが使用するDNSサーバとして設定されているDNSサーバのことです。承認済みDNSサーバからの応答のみをワイルドカードの学習プロセスで使用する理由は、意図的に不正なホスト エントリが設定された未承認DNSサーバの使用によってFQDN AOのポイズニングが発生する危険を防止するためです。SonicOS の将来のバージョンでは、すべてのDNSサーバからの応答をサポートするオプションが提供される可能性があります。アクセス ルールを使うと、承認済みDNSサーバの使用を強制することができます。その方法については、この後の「ネットワーク上の承認済みサーバの使用の強制」で説明します。
例として、4.2.2.1と4.2.2.2のDNSサーバを使用するようにファイアウォールが設定されていて、ファイアウォールで保護されているすべてのクライアントに対してDHCP経由でこれらのDNSサーバが提供されている場合を考えてみましょう。ファイアウォールで保護されているクライアントAが“vids.myspace.com”に対応するアドレスの問い合わせを4.2.2.1または4.2.2.2に対して行ったとすると、ファイアウォールでは、それに対する応答が検査され、定義済みの“*.myspace.com” FQDN AOに一致するものと判断されます。そして、その問い合わせの結果 (63.208.226.224) は、“*.myspace.com” DAOに対応する解決済みの値として追加されます。
補足:上記の例で、“*.myspace.com” AOが作成される前に、クライアントAのワークステーションが“vids.myspace.com”を解決して、その結果をキャッシュしていたとすると、クライアントは新しいDNS要求を発行する代わりにリゾルバのキャッシュを使用するので、ファイアウォールによる“vids.myspace.com”の解決は行われません。そのため、別のホストによって“vids.myspace.com”の解決が行われない限り、ファイアウォールは“vids.myspace.com”について学習する機会を得られないことになります。マイクロソフト ウィンドウズを使用しているワークステーションでは、ipconfig /flushdnsコマンドを使用して、ローカル リゾルバのキャッシュを消去することができます。このキャッシュの消去を行うと、クライアントはすべてのFQDNを解決するようになるので、それらのアクセス時にファイアウォールがその解決の情報を取得することが可能になります。
ワイルドカードFQDNエントリは、そのドメイン名のコンテキストに含まれるすべてのホスト名に解決されます (アドレス オブジェクトあたり最大256エントリまで)。例えば、“*.sonicwall.com”と指定されている場合、
www.sonicwall.com、software.sonicwall.com、licensemanager.sonicwall.comは、それぞれのIPアドレスに解決されますが、sslvpn.demo.sonicwall.comは別のコンテキストのドメイン名であるため解決されません。ワイルドカードFQDN AOによってsslvpn.demo.sonicwall.comを解決するには、“*.demo.sonicwall.com”というエントリを指定する必要があります。このエントリを指定した場合は、sonicos-enhanced.demo.sonicwall.com、csm.demo.sonicwall.com、sonicos-standard.demo.sonicwall.comなどのドメイン名も解決されます。
補足:FQDN アドレス オブジェクト複数可能サポート
SonicOS 5.8.1 ではアドレス オブジェクトの記載で FQDN 複数階層の指定をサポートしています。
DNSの使用によるFQDNの解決 FQDNアドレス オブジェクトは、SonicWALLの「
ネットワーク > DNS」ページで設定されたDNSサーバを使用して解決されます。DNSエントリは複数のIPアドレスに解決される場合が多いので、FQDN AO解決プロセスは、AOあたり最大256エントリまでの範囲で、ホスト名に対応するアドレスをすべて取得します。解決プロセスでは、FQDNのIPアドレスへの解決だけでなく、DNS管理者による設定に基づいて、エントリのTTL (存続期間) の関連付けも行われます。このTTLは、古くなったFQDN情報が使われることを防ぐために利用されます。
FQDNエントリのキャッシュ FQDNの最初の解決以後に解決の試行が失敗した場合には、解決済みの値がキャッシュされます。例えば、“www.moosifer.com”が71.35.249.153に解決されて、TTL値として300が設定されたとすると、TTLが失効した時点での解決が (DNSサーバの一時的な障害などが原因で) 失敗した場合には、71.35.249.153がキャッシュされ、次に解決が成功するまで、またはキャッシュが手動で削除されるまでの間はこの値が使用されます。新規作成後に1度も解決が成功していないFQDNエントリや、キャッシュの削除後に解決が失敗したエントリは、
未解決状態として表示されます。
動的ARPキャッシュ データの使用によるMACアドレスの解決 SonicWALLのいずれかの物理セグメントにおいて、ARP (Address Resolution Protocol) メカニズムによってノードが検出されると、SonicWALLのARPキャッシュが更新され、そのノードのMACアドレスとIPアドレスが追加されます。この更新が発生した場合、そのノードのMACアドレスを参照するMACアドレス オブジェクトが存在するときには、解決されたアドレスのペアを使用して、そのアドレス オブジェクトが直ちに更新されます。ノードが使われなくなって、そのノードのARPキャッシュがタイムアウトした場合 (ホストとファイアウォールのL2接続が切断された場合など) には、そのMAC AOは“未解決”状態に移行します。
MACアドレス オブジェクトによるマルチホームのサポート MAC AOではマルチホームのノードをサポートする設定を使用できます。マルチホームのノードとは、物理インターフェースごとに複数のIPアドレスが割り当てられているノードのことです。各AOでは最大256個の解決済みエントリを指定できます。この方法を使用すると、1つのMACアドレスが複数のIPアドレスに解決される場合でも、そのすべてのIPアドレスに対して、そのMAC AOを参照するアクセス ルールなどが適用されるようになります。
自動と手動の更新処理 MAC AOエントリはSonicWALLのARPキャッシュに自動的に同期され、FQDN AOエントリにはDNSエントリのTTL値が適用されるため、解決済みの値は常に新しい状態に保たれます。これらの自動的な更新処理に加えて、個々のDAOまたは定義済みのすべてのDAOを対象として手動で更新および削除を実行することもできます。
DNSの使用によるFQDNの解決 FQDNアドレス オブジェクトは、SonicWALLの「
ネットワーク > DNS」ページで設定されたDNSサーバを使用して解決されます。DNSエントリは複数のIPアドレスに解決される場合が多いので、FQDN AO解決プロセスは、AOあたり最大256エントリまでの範囲で、ホスト名に対応するアドレスをすべて取得します。解決プロセスでは、FQDNのIPアドレスへの解決だけでなく、DNS管理者による設定に基づいて、エントリのTTL (存続期間) の関連付けも行われます。このTTLは、古くなったFQDN情報が使われることを防ぐために利用されます。

ネットワーク上の承認済みサーバの使用の強制

ネットワーク上の承認済みサーバ (許可されたサーバ) の使用を強制することは必須ではありませんが、そのような設定を行うことをお勧めします。この設定は不正なネットワーク活動の抑止に有効であるだけでなく、FQDNワイルドカードの解決プロセスの信頼性を確保するためにも役立ちます。一般に、既知のプロトコルによる通信のエンドポイントは可能な限り明確に定義することが望ましいと言えます。そのためには、例えば、以下のような方法を使用することが考えられます。


・ 承認済みサーバ (SMTPサーバ、DNSサーバなど) のアドレス オブジェクト グループを作成します。

・ 該当するゾーンのアクセス ルールを作成して、内部ネットワーク上の承認済みSMTPサーバにのみSMTP通信の発信を許可し、それ以外のすべてのSMTP発信トラフィックを遮断することにより、意図的または意図しないスパムの送信を防止します。

・ 該当するゾーンのアクセス ルールを作成して、内部ネットワーク上の承認済みDNSサーバに対して、すべての宛先ホストとのDNSプロトコル (TCP/UDP 53) による通信を許可します。内部ネットワーク上にDNSサーバを設置している場合は、必ずこのルールを定義したうえで、アクセスを制限する次のDNSルールを設定する必要があります。.

・ 該当するゾーンのアクセス ルールを作成して、ファイアウォールで保護されたホストからのDNS (TCP/UDP 53) 通信を承認済みDNSサーバに対してのみ許可し、それ以外のすべてのDNSアクセスを遮断することにより、未承認のDNSサーバとの通信の発生を防止します。

・ 上記のルール設定後に、許可されていないアクセスが試行された場合は、ログの表示によってそのことを確認できます。

MACおよびFQDN動的アドレス オブジェクトの使用

MACおよびFQDNの動的アドレス オブジェクトを使用すると、アクセス ルールを非常に柔軟な形で構築できるようになります。MACアドレス オブジェクトおよびFQDNアドレス オブジェクトの設定は、静的アドレス オブジェクトの場合と同じ方法で「ネットワーク > アドレス オブジェクト」ページから行います。動的アドレス オブジェクトの作成後に、その表示項目にマウスを合わせると、そのオブジェクトの状況が表示されます。また、動的アドレス オブジェクトの追加や削除を行うと、その操作がイベントとしてログに記録されます。

動的アドレス オブジェクトは、さまざまな用途に使用できます。以下に示す例は、可能な活用方法のごく一部にすぎません。SonicOS の将来のバージョンでは、動的アドレス オブジェクトの汎用性がさらに拡張される可能性があります。

FQDN DAOの使用による、ドメインに対するすべてのプロトコルのアクセス遮断

非標準ポートを使った処理や、未知のプロトコルの使用、暗号化やトンネル化 (またはその両方) によるトラフィックの意図的な不明瞭化などを行っているという理由から、特定の送信先IPアドレスへのすべてのプロトコルのアクセスを遮断することが望ましい場合があります。具体的な例としては、ホーム ネットワークのトンネルを通すことによってトラフィックを不明瞭化するという目的で、DSLモデムまたはケーブル モデムに接続されたホーム ネットワーク上にHTTPSプロキシ サーバを設定した場合 (あるいはその他の方法で、53、80、443などの“信頼できる”ポート、および5734、23221、63466などの非標準ポートのポート転送/トンネル化を行っている場合) などが考えられるでしょう。このようなネットワークではポートが予測不能であるだけでなく、多くの場合、IPアドレスも動的に設定されるため同様に予測不能となり、状況はさらに複雑化します。

これらのシナリオでは、通常、ユーザがホーム ネットワークを特定することを可能にするために動的DNS (DDNS) が利用されるので、FQDN AOを積極的に活用することによって、DDNSレジストラに登録されているすべてのホストに対するアクセスを遮断することができます。

補足 ここでは例としてDDNSターゲットの場合を示しています。非DDNSターゲット ドメインも同様に使用できます。

想定条件


・ SonicWALLファイアウォールは、10.50.165.3および10.50.128.53のDNSサーバを使用するように設定されているとします。

・ SonicWALLは、ファイアウォールで保護されているすべてのユーザに対してDHCPリースを提供しているものとします。ネットワーク上のすべてのホストは上記の設定済みDNSサーバを使用して解決を行います。

・ 必須ではありませんが、「ネットワーク上の承認済みサーバの使用の強制」で説明した方法により、アクセス ルールを使って未承認DNSサーバへのDNS通信を遮断することもできます。

・ DSLホーム ネットワークのユーザがDDNSプロバイダのDynDNSに登録しているドメイン名は、moosifer.dyndns.orgであるとします。このセッションでISPがこのDSL接続に割り当てたアドレスは、71.35.249.153であるとします。

・ 同じIPアドレスに対して別のホスト名を登録することは容易なので、後からホスト名が追加されることを想定してFQDN AOを使用しています。必要に応じて、別のDDNSプロバイダに対応するエントリを追加することもできます。

ステップ1 - FQDNアドレス オブジェクトの作成


・ 「ネットワーク > アドレス オブジェクト」ページで「追加」を選択し、次のアドレス オブジェクトを作成します。

・ 最初に作成された時点では、このエントリの解決先はdyndns.orgのアドレス (63.208.196.110など) のみです。

ステップ2 - ファイアウォール アクセス ルールの作成


・ 「ファイアウォール > アクセス ルール」ページで「追加」を選択し、「送信元ゾーン」を「LAN」に、「送信先ゾーン」を「WAN」にそれぞれ設定して、次のアクセス ルールを追加します。
補足 送信元として“LAN Subnets”を指定する代わりに、必要に応じて、より限定的な送信元を指定することによって、特定のホストからの送信のみを対象としてターゲットへのアクセスを禁止することもできます。

・ ファイアウォールで保護されているホストが承認済みDNSサーバを使用してmoosifer.dyndns.orgの解決を試行した場合、その問い合わせに対する応答として返された (1つまたは複数の) IPアドレスがFQDN AOに動的に追加されます。

・ このFQDNに含まれるターゲット ホストへのアクセスはプロトコルに関係なく遮断され、アクセスが試行された場合は、そのイベントがログに記録されます。

FQDNベースのアクセス ルールに適した内部DNSサーバの使用

DHCPで動的に構成されるネットワーク環境は、内部ホストの登録を動的に行うために、内部DNSサーバと組み合わせて運用されるのが一般的であり、広く使われているマイクロソフトのDHCPサービスとDNSサービスもその一例です。このようなネットワークでは、ネットワーク上のホストを設定することによって、適切に設定されたDNSサーバ上のDNSレコードの動的更新を容易に実現することができます (詳細については、マイクロソフトのサポート技術情報「Windows Server 2003でDNS動的更新を構成する方法」 〈http://support.microsoft.com/kb/816592/ja〉 などを参照してください)。

次の図は、典型的なDNS動的更新プロセスのパケットの詳細情報を示したものです。この例では、動的に設定されたホスト (10.50.165.249) が、(DHCPで提供された) DNSサーバ (10.50.165.3) に対して、完全なホスト名 (bohuymuth.moosifer.com) を登録していることがわかります。

このような環境では、FQDN AOを利用して、ホスト名によるアクセス制御を行うことが有益な場合があります。この方法が最も有効に適用できるのは、ネットワーク内のホスト名が既知の場合 (ホスト名のリストが保持されている場合や、一貫した名前付け規則が使用されている場合など) です。

MACアドレスによる動的ホストのネットワーク アクセスの制御

ほとんどのネットワークでは静的なアドレス設定よりもDHCPが利用されることの方がはるかに多いため、特に、動的なDNS更新が行われていない場合や、ホスト名が常に確定しているとは言えない環境では、動的に設定されるホストのIPアドレスを予測するのが困難な場合があります。このような状況では、MACアドレス オブジェクトを使用することにより、ほぼ不変のMAC (ハードウェア) アドレスに基づいてホストのアクセスを制御することができます。

その他のほとんどのアクセス制御方法と同様、MACアドレスによるアクセス制御も、アクセスを原則的に許可して特定のホストまたはホストのグループを送信先/送信元とするアクセスのみを禁止する方法と、アクセスを原則的に禁止して特定のホストまたはホストのグループに対してのみアクセスを許可する方法のどちらでも利用できます。ここでは、例として後者の場合を示します。

DHCPに対応した複数の無線クライアントがあり、これらのクライアントでは独自のオペレーティング システムが実行されているため、ユーザ レベルの認証は一切利用できないと仮定しましょう。そして、これらのクライアントに対して、LAN上のアプリケーション固有サーバ (例えば、10.50.165.2) へのアクセスのみを許可する必要があるとします。WLANセグメントではセキュリティのためにWPA-PSKが使用されていますが、これらのクライアントからのアクセスを許可する対象は10.50.165.2のサーバのみであり、LAN上のそれ以外のリソースへのアクセスはすべて禁止しなければなりません。また、その他のすべての無線クライアントに対しては、10.50.165.2へのアクセスのみを禁止し、それ以外の場所へのアクセスはすべて許可する必要があります。

ステップ1 - MACアドレス オブジェクトの作成


・ 「ネットワーク > アドレス オブジェクト」ページで「追加」を選択し、次のアドレス オブジェクトを作成します (マルチホームのオプションは必要に応じて選択します)。

・ アドレス オブジェクトの作成完了時点において、対象のホストがSonicWALLのARPキャッシュに含まれている場合は、直ちにその解決が行われます。ARPキャッシュ内にホストの情報が存在しない場合は、ホストが有効化されてARPによって検出されるまでの間、「アドレス オブジェクト」テーブルにはそれらのアドレスが「未解決」状態として表示されます。

・ ハンドヘルド機器をメンバーとして含むアドレス オブジェクト グループを作成します。

ステップ2 - ファイアウォール アクセス ルールの作成


・ アクセス ルールを作成するには、「ファイアウォール > アクセス ルール」ページに移動して「すべてのルールを表示」ラジオ ボタンを選択し、ページの下部が表示されるまでスクロールして「追加」ボタンを選択します。

・ 次の4つのアクセス ルールを作成します。
設定
アクセス ルール1
アクセス ルール2
アクセス ルール3
アクセス ルール4
送信元ゾーン
WLAN WLAN WLAN WLAN
送信先ゾーン
LAN LAN LAN LAN
サービス
MediaMooseサービス MediaMooseサービス すべて すべて
送信元
ハンドヘルド機器 すべて ハンドヘルド機器 すべて
送信先
10.50.165.3 10.50.165.3 すべて すべて
許可するユーザ
すべて すべて すべて すべて
スケジュール
常に有効 常に有効 常に有効 常に有効
補足 この例では、ハンドヘルド機器によって使用される特定のアプリケーションを表すために「MediaMooseサービス」というサービスを使用しています。固有サービスの宣言はオプションであり、必要に応じて行ってください。

ドメイン全体へのアクセスの帯域幅管理

ストリーミング メディアは、ネットワークの帯域幅を最も大量に消費するサービスの1つです。ストリーミング メディアを配信しているサイトでは、ほとんどの場合、多数のサーバからなるサーバ ファームが利用されているため、これらのサイトへのアクセスを制御したり、サイトへの接続に割り当てられる帯域幅を管理したりすることは容易ではありません。さらに、これらのサイトではメディアが再エンコードされてからHTTPで送信される場合が多いので、種別による分類や分離を行うことはいっそう難しくなっています。これらのサイトを構成しているサーバのリストを手動で管理するのは困難な仕事ですが、ワイルドカードFQDNアドレス オブジェクトを使用すると、その作業を簡単化することができます。

ステップ1 - FQDNアドレス オブジェクトの作成


・ 「ネットワーク > アドレス オブジェクト」ページで「追加」を選択し、次のアドレス オブジェクトを作成します。

アドレス オブジェクトが最初に作成された時点では、youtube.comは208.65.153.240、208.65.153.241、208.65.153.242のIPアドレスに解決されますが、内部ホストがyoutube.comドメイン内のすべての要素に対応する各ホストの解決を開始した後は、v87.youtube.comサーバ (208.65.154.84) のエントリなど、内部ホストからの問い合わせによって取得されたホスト エントリが追加されていきます。

ステップ2 - ファイアウォール アクセス ルールの作成


・ 「ファイアウォール > アクセス ルール」ページで「追加」を選択し、「送信元ゾーン」を「LAN」に、「送信先ゾーン」を「WAN」にそれぞれ設定して、次のアクセス ルールを追加します。
補足 「帯域幅」タブが表示されない場合は、WANインターフェース上の帯域幅を宣言することによって帯域幅管理を有効化します。帯域幅管理の詳細については、「Configuring QoS and BWM」 〈http://www.sonicwall.com/support/pdfs/configuring_qos_and_bwm.pdf〉 を参照してください。

・ 「アクセス ルール」テーブル内に、帯域幅管理が有効であることを示す帯域幅管理アイコンと統計情報が表示されるようになります。*.youtube.comのすべてのホストに対するアクセスは、どのプロトコルを使用している場合でも、累積的に、すべてのユーザ セッションで利用可能な合計帯域幅の2%までに制限されます。