運用常時接続時代のパーソナル・セキュリティ対策(第4回)3.インターネット接続共有におけるNPFW(1) デジタルアドバンテージ |
||
Norton Personal Firewall 2001はその名のとおり、パーソナルな用途で使われているコンピュータ・システムのセキュリティを確保するために開発された製品である。企業などにおいて、インターネットとの間に設置するファイアウォール・システムとして作られているわけではなく、各エンド・ユーザーが使用している(ネットワーク的に見て)末端のコンピュータにインストールして、そのユーザーのシステムを守るという使い方を想定している。エンド/ユーザーが複数いるのなら、それぞれのエンド・ユーザーごとにインストールして使用するのが正しい/望ましい使い方である。
しかし本稿で取り上げているような、インターネット接続共有環境の場合はどのように運用するのがよいのであろうか。考えられるパターンとしては、2つしかないだろう。インターネット接続共有を実行しているマシン(以下、単にWindows 2000マシンと呼ぶことにする)にインストールするか、それともそれらのクライアントとなっている、LAN上のマシン(以下、Windows 9xマシンと呼ぶことにする)にインストールするか、である。この製品の趣旨からいうと、当然クライアントとなっているすべてのWindows 9xマシン上にNPFWをインストールするべきであるが、これは現実的ではない。ライセンス的に複数台分のNPFWを購入しなければならないので金銭的負担が大きいというのはもちろんであるが、これではインターネット接続共有を実行しているWindows 2000マシン自体のセキュリティを確保することができないからである。
では接続共有を実行しているマシンにNPFWを導入するとどうだろうか。セキュリティ的には、これによってWindows 2000マシンの安全性を確保することができる。接続共有(NAT)経由で接続されている内部のLAN上のマシンは、NATの持つ特性により、(ポート・フォワードの設定をしない限り)インターネット側からは直接アクセスすることはできない。というわけでこの方法が望ましい。だがNPFWのデフォルト状態では、セキュリティ設定が厳しすぎて、クライアントのマシンからインターネットにアクセスすることができない。つまりNAT機構自体もNPFWによって外部から守られているので、クライアントからのアクセス要求もブロックされてしまうのである。実際には、DHCP要求すらブロックされているので、クライアントはブート時にIPアドレスを取得することすらできなくなってしまう。
これを解決するには2通りの方法がある。1つはセキュリティレベルを下げる方法であり、もう1つは、必要なパケットを通すようにNPFWを設定する方法である。ここでは、この2つの方法について見ていこう。
方法1――セキュリティレベルを下げてクライアントからのアクセスを許可する
いちばん簡単な解決方法は、NPFWのセキュリティ設定画面(画面については [ここ] を参照)において、 セキュリティレベルをデフォルトの「中レベル」から「低レベル」に変更することである。セキュリティレベル全体を下げたくないのなら、セキュリティ設定のカスタマイズ画面(画面については [ここ] を参照)において、[ファイアウォール]のレベルを[高レベル]から[中レベル]へと下げればよい。この設定の意味は、すでに述べたように、ルールが未定義の場合のパケット・フィルタの動作を変えるものである。デフォルトでは、ルールが未定義のパケットはすべてブロックされ、ブロックされたことがイベントログにも記録されるようになっている。しかし[ファイアウォール]のレベルを[中レベル]に下げると、未定義のパケットはそのまま通過するようになる。
インターネットの接続共有がWindows 2000マシン上で動作している場合、ローカルのLAN上のクライアントから送信されたパケットは、Windows 2000マシンにとっては、すべて「未定義のパケット」という扱いになる。このため、セキュリティレベルを下げることにより、接続共有(NAT)のためのパケットはNAT変換モジュールに届き、正しく処理されるようになる。
逆にインターネット側からやってきた、NATで変換されるべきパケット(ローカル側のLANへ届けられるべきパケット)も、同様にNATモジュールを経由して変換され、ローカル側へ渡される。
方法2――必要なパケットを通すようにフィルタを設定する
方法1は、セキュリティ的にはやや弱くなるものの、ほとんど何も設定しなくてもインターネット接続共有が利用できるので、ネットワークのプロトコルに詳しくないユーザーにとっては簡便な方法である。しかしせっかくNPFWを導入しておきながら、未定義パケットの検出/ブロック機能を使わないというのではセキュリティ的に不安が残るかもしれない(たとえこれだけでも、Windows 2000を何の対策もなしに使うのに比べれば安全性は十分高いが)。
これを解決するためには、自分でパケット・フィルタのルールを追加して、ローカルLAN側からのパケットを通過するようにすればよい。といっても、どのようなルールを定義しておけばよいのかはなかなか分かりにくいだろう。とりあえず必要なのは、クライアントのLAN上のマシンがブートするために必要なDHCP/BOOTPプロトコルと、名前解決のためのDNSプロトコルである。この2つだけは接続共有を行っているWindows 2000マシンに直接向けて発信されているため、これが利用できなければ、クライアントのマシンそのもののネットワークが動作しない。
■DHCPプロトコル
DHCPプロトコルは、クライアント・マシンが起動時に、IPアドレス情報やデフォルト・ルータ、DNSサーバ・アドレス情報などを得るために使われるプロトコルである。接続共有環境では、クライアントのWindow 9xマシンが起動時にDHCP要求を出して、Windows 2000マシンにIPアドレスを要求する。デフォルトでは、Windows 2000マシンは、DHCPクライアントとして動作するように設定されているが、DHCPサーバとしては動作しないようになっている。そこで以下のようなフィルタを追加して、クライアントからのDHCP要求を受け付けるようにする。なお、プロトコル的には、DHCPはBOOTPプロトコルと同じなので、セットするサービス名は「bootps/bootps」となっている。
設定項目 | 設定値 |
ルール名 | RULE11-DHCP |
サービス | DHCP/BOOTPプロトコル |
処理 | 許可 |
方向 | インバウンドとアウトバウンドの両方 |
プロトコル | UDP |
カテゴリ | 一般 |
アプリケーション | svchost.exe |
リモートサービス | 単一のサービス:bootpc (68) |
ローカルサービス | 単一のサービス:bootps (67) |
リモートアドレス | (任意のアドレス) |
ローカルアドレス | ホストアドレス:myserver |
DHCPプロトコルのフィルタ・ルール | |
アプリケーションは「任意のアプリケーション」でも構わないし、サービスの値は数値で入力してもよい。ローカルアドレスにある「myserver」は、Windows 2000マシンに付けたマシンの名前を入力すること。 |
以上のフィルタ・ルールをNPFWに追加するためには、NPFWの[オプション]メニューから[拡張オプション]をクリックし、[ファイアウォール]タブにある[追加]ボタンをクリックする。ファイアウォールのルール名は、後で識別しやすいように、優先順位に応じた番号を付けて管理すると便利だろう。表中で、「ローカル」とはWindows 2000マシンのことを、「リモート」とはクライアントのWindows 9xマシンのことをそれぞれ指している。パケットのフィールド名のように、「ソース・アドレス」とか「宛先アドレス」というふうに区別していないので注意が必要である(送信パケットと受信パケットで呼び方が変わらないように、NPFWでは「ローカル」と「リモート」で使い分けている)。
NPFWのルールの追加画面は、全部で4つのページに分かれている。ルール名やプロトコルの種別(TCP/UDP/ICMP)は共通になっている。そして、使用するアプリケーションやサービス・ポート番号などの入力は各ページに分かれている。
DHCPルールの追加――アプリケーションの指定 | ||||||||||||||||||
指定されたルールを追加する場合には、アプリケーションの種別やパケットの種類などを指定する。 | ||||||||||||||||||
|
サービスの指定は、数値で入力してもよいが、「%windir%\system32\drivers\etc\services」ファイル中にあるサービス名を使った方が分かりやすいだろう(Windows 9xの場合は「%windir%\services」ファイル)。
DHCPルールの追加――サービスの指定 | ||||||
DHCPの使用するUDPポートの指定。BOOTP/DHCPでは、常にクライアント側はBOOTPC(BOOTP Client)、サーバ側はBOOTPS(BOOTP Server)という固定的なサービス・ポート番号を使用しているので、それらをルール中に記述し、安全性を高める(無関係なパケットがフィルタによって「許可」される可能性が低くなる)。 | ||||||
|
[リモートアドレス]や[ローカルアドレス]フィールドには、パケットが送受信されるホストを限定するための条件を記述する。DHCPサービスの場合、リモートアドレスはLAN上のクライアントのIPアドレスになるが、DHCPはシステムがブートする前に使われるプロトコルなので、特定のアドレス値を指定することはできない。実際には、「0.0.0.0」か、以前にDHCPで割り当てられたIPアドレス(192.168.0.*)になっている。ここでは数値ではなくホスト名で指定しておこう。
DHCPルールの追加――アドレスの指定 | ||||||
DHCPパケットが送受信されるアドレスを指定する。インターフェイスごとの直接指定ができないので、代わりにmyserverという名前を使ってローカル接続側からのパケットだけを許可している。もしインターネット側からDHCPの要求パケットが届いても、それはデフォルトのルールによってブロックされる。 | ||||||
|
このようにしてルールを追加し、定義したルールの優先度を一番上まで上げておく(最優先にしておく)。なお、ルール定義の4つめのタブに[ログ記録]というページがあるので、ここにある「通信がこの規則に一致したときにイベントログエントリを書き込む」というチェックボックスをオンにしておく。これは、ルールが適用された場合に、イベントログに記録を残すための指定である。運用当初しばらくは必ずこれを行って、NPFWが正しく動作しているかどうかをチェックしておくことを忘れないでいただきたい。
INDEX | ||
[運用]インターネット常時接続時代のパーソナル・セキュリティ対策(第4回) | ||
1.NPFWの内部アーキテクチャ | ||
2.ファイアウォール・ルールの追加設定 | ||
3.インターネット接続共有におけるNPFW(1) | ||
4.インターネット接続共有におけるNPFW(2) | ||
運用 |
- Azure Web Appsの中を「コンソール」や「シェル」でのぞいてみる (2017/7/27)
AzureのWeb Appsはどのような仕組みで動いているのか、オンプレミスのWindows OSと何が違うのか、などをちょっと探訪してみよう - Azure Storage ExplorerでStorageを手軽に操作する (2017/7/24)
エクスプローラのような感覚でAzure Storageにアクセスできる無償ツール「Azure Storage Explorer」。いざというときに使えるよう、事前にセットアップしておこう - Win 10でキーボード配列が誤認識された場合の対処 (2017/7/21)
キーボード配列が異なる言語に誤認識された場合の対処方法を紹介。英語キーボードが日本語配列として認識された場合などは、正しいキー配列に設定し直そう - Azure Web AppsでWordPressをインストールしてみる (2017/7/20)
これまでのIaaSに続き、Azureの大きな特徴といえるPaaSサービス、Azure App Serviceを試してみた! まずはWordPressをインストールしてみる
|
|