| ［運用］ 常時接続時代のパーソナル・セキュリティ対策 （第1回） 8．セキュリティ対策その３：パケット・フィルタを設定する（3） デジタルアドバンテージ2000/12/23 |
 |
|
|
|
全パケットを禁止すると……
ところで先ほどの画面の例では、「インターネット接続」側のインターフェイスでは、TCPもUDPもIPも、すべてのパケットを禁止するという設定にしていた（通過させるリストが空のまま、
、
、
を選択している）。これにより、「インターネット接続」側は外部（インターネット側）から一切アクセスされなくなるので、安全になると思うだろう。実際、インターネット側からのアクセスはすべてブロックされているので、安全であることは確かである。だが大きな問題が1つある。外部へのアクセスもできなくなってしまっているのだ。具体的には、たとえばローカルのLAN上のWindows
MeクライアントからInternet Explorerを使って、＠ITのWebページ（http://www.atmarkit.co.jp/）を見ようとしても、いつまでたっても画面が表示されないのである（「ページを表示できません」というエラーになる）。それだけではなく、さらには、接続共有を実行しているWindows
2000上でもやはりWebブラウザを使うことができない。
これらの原因は実はDNSによる名前解決にある。次の画面を見てもらいたい。これは、内部のLAN上にあるWindows Me上で、winipcfg.exeコマンドを実行したところである。
 |
||||||
|
クライアントのTCP/IP環境 |
||||||
| これは、LAN上にあるWindows Meマシンでwinipcfg.exeコマンドを実行した結果である。「DNSサーバ」のフィールドに注目していただきたい。「192.168.0.1」となっていることから分かるように、DNSサーバは、接続共有を実行しているWindows 2000マシンが代理で実行している（DNS Proxy機能）。 | ||||||
|
DNSサーバのIPアドレスが「192.168.0.1」となっていることから分かるように、クライアント側から見ると、DNSサーバはインターネット上に存在するのではなく、接続共有を実行しているWindows 2000マシンが実行しているように見える。実際には、Window 2000マシンに届いたDNSの名前解決要求は、そこで中継されてインターネット上のDNSサーバに届くようになっている。このあたりのパケットのやりとりをまとめると、次のようになる。
- クライアントのInternet Explorer上で、「http://www.atmarkit.co.jp/」のページを開こうとする。
- クライアントは、「www.atmarkit.co.jp」というFQDNをDNSサーバ（「192.168.0.1」のマシン）に送って、名前解決（ホスト名やドメイン名から、そのIPアドレスを求めること）を依頼する。
- Windows 2000マシンは、DNS要求を受け取り、それをインターネット上の本来のDNSサーバに送って、名前解決を依頼する。
- DNSサーバから、DNSの応答を受け取る。
- それをクライアントのマシンへ、DNS応答として、再送する。
- クライアント側では、受け取ったDNS応答から、「www.atmarkit.co.jp」のIPアドレスが「211.2.XXX.XX」であることを知る。
- アドレス「211.2.XXX.XX」のWebサーバに対して、HTTP（TCPのポート80番）プロトコルを使ってアクセスし、HTMLファイルの情報を得る。
- 以下省略。
ここで問題となっているのは、4．のDNSサーバからその応答を受け取るところである。先ほどの設定では、「インターネット接続」側の全TCP/UDPポート（TCPとUDPのすべてのインバウンドのパケット）をブロックしているが、この結果、4．の応答が受け取れなくなってしまうのである。それ以外のパケット、つまり「インターネット接続」側のアウトバウンド・パケットと、「ローカル接続」側のインバウンド／アウトバウンド・パケットは、すべてそのまま通過する。
以上のような事情により、すべてのパケットをフィルタリングするように設定すると、DNSによる名前解決が正しく機能しなくなってしまうのだ。これが本当かどうかを確認するには、名前ではなく、IPアドレスでWebブラウザを使ってみればよい。クライアント・マシン上のInternet Explorerで、「www.atmarkit.co.jp」ではなく「211.2.XXX.XX」を直接開いてみるのである。今度は正しく表示できるはずである。
DNSパケットを通過させる
さてそれでは、どうしたらよいのであろうか？ すぐに考え付くのは、先ほどのパケット・フィルタリングの設定で、「UDPの53番（DNSプロトコル）」だけを通過するように設定することであろう。具体的には、をチェックして、
のリストに「53」を追加するのである。これでDNSパケットだけは通過できるようになり、名前解決ができるようになると考えられる。
だが結論から言うと、これでは正しく動かない。なぜなら、DNSの返答のパケットは、宛先ポート番号が53番ではないからだ。次に示すのは、DNSの問い合わせパケットの構造である（UDP層の部分だけを示す）。
| DNSの問い合わせ（Query）パケット | ||
|
宛先ポート |
ソース・ポート |
データ |
|
53 |
nnnn |
DNS-Query（“www.atmarkit.co.jp”） |
ここで、「nnnn」は、UDPのソース・ポート番号（16bitの整数）を表している。この数値は、新しいDNSの問い合わせが発生するたびに、（通常は）1024以上の数値からランダムに選ばれる。
この問い合わせに対する応答パケットは、次のような構造をしている。データ部には、問い合わせのあった名前に対するIPアドレスが含まれている。
| DNSの応答（Response）パケット | ||
|
宛先ポート |
ソース・ポート |
データ |
|
nnnn |
53 |
DNS-Response（“211.2.XXX.XX”） |
先頭の2つのポート番号（宛先ポートとソース・ポート）フィールドに注目していただきたい。問い合わせパケットのときとは内容が入れ換わっている。TCPやUDPプロトコルでは、応答（逆方向）のパケットでは、ポート番号が入れ換わる（UDPの場合は、使い方によっては変わらないようにすることもできるし、もっと異なる使い方もできるが、通常はこのように使われる）。
このように、インバウンドの（応答の）DNSパケットでは、宛先ポート番号が53番ではなく、しかも固定的な値になることはない。Windows 2000のTCP/IPプロトコルル・スタック組み込みのパケット・フィルタリング機能では、すでに述べたように、「宛先ポート」でしかフィルタリングできないので、このようなパケットだけを通すように設定することは不可能である（専用のルータならば、『「宛先ポート番号が53」か「ソース・ポート番号が53」のパケットを通す』などという設定ができるのが普通である）。
クライアントのDNS設定を変える方法
Windows 2000の組み込みのUDPパケット・フィルタリング機能がうまく使えない以上、何らかの別の方法を考える必要がある（それにしてもこのUDPのフィルタリング機能を使うのは、事実上不可能ではないかと思われる。ただしRRASを使えば、より柔軟で高機能なパケット・フィルタリング機能が利用できる）。
Windows 2000 Professional（接続共有のサーバ）側のフィルタ設定をこのままにするなら（つまりUDPのパケット・フィルタ機能やDNS Proxy機能を有効にしたままなら）、できることは1つ、クライアント側のDNS設定を変更することぐらいしかないであろう。クライアント・マシンには、DHCPで自動的にDNSサーバ・アドレス（192.168.0.1）が割り当てられるが、それをやめ、DNSサーバのアドレスだけは手動で設定するのである（プロバイダから与えられたDNSサーバ・アドレスを、各クライアントのTCP/IPプロトコルのコントロール・パネルへセットする）。こうすると、クライアント・マシンから発信されたDNSの問い合わせパケットは、接続共有を提供しているマシンでNAT／IPマスカレード変換されてインターネット側へ送り出され、その応答パケットは逆のルートでクライアント・マシンへ戻ってくる。UDPのパケット・フィルタリングでブロックされることはない。
以上の設定により、少なくともクライアント・マシンだけは透過的にインターネットに接続できるようになる。しかしサーバ側のマシンでは、DNSパケットの応答を正しく受け取ることができないので、DNSを使うようなアプリケーションを実行することはできない。せいぜいLAN側のクライアントに対して、ファイルやプリンタの公開サービスを提供するぐらいの使い方しかできないだろう。それに、各クライアントの設定を忘れずにこのように行うというのはかなり大変であろうから、あまり実用的な方法とはいえないかもしれない（セキュリティ的には望ましいのだが）。
より現実的なフィルタリング設定
上記の方法では、Windows 2000マシン自体がインターネットを利用することができないので、あまり現実的ではない。実際には、さらにマシンのIPアドレスを決めるためのDHCPのパケットも受け取れないのだが、これは、許可するUDPのポートとして68番（BOOTPクライアント・ポート）を追加しておけばよいだけである（BOOTP／DHCPでは、DNSと違って、ソース・ポート番号と宛先ポート番号は固定である）。
このような事情があるため、セキュリティ的にはやや劣るが、もう少し実用的な方法として、「UDPのパケット・フィルタリング機能を無効にする」という方法がある。これならDNSを始めとするUDPを使ったアプリケーションはそのまま利用可能であるので、クライアント側の設定なども不要であるし、Windows 2000マシンからもほぼ自由にインターネット側のリソースを利用することができる。
もちろん外部からのUDPに対する接続がそのままパスすることになるが、TCP側はすべてブロックされているし、ファイル／プリンタ共有サービスやNBTプロトコルなどはすでにブロックしているので、セキュリティ的には（何もしない状態よりは）かなり安全性が高い。「TIPS：ポート445（ダイレクト・ホスティングSMBサービス）に注意」についても、TCP側の445番がブロックされているので、外部からのアクセスはできないようである（Windows 2000のダイレクト・ホスティングSMBサービスでは、TCPの445番ポートは利用されているが、UDPの445番ポートは使われていないようである）。
 |
||||||||||||||||||
| ［TCP/IPフィルタリング］の設定（より現実的な設定） | ||||||||||||||||||
| UDPパケットをすべてブロックすると、DNSサービスなど、UDPを使った通信ができなくなってしまうので、UDPについてはフィルタリングを無効にする。TCPとIPについては、完全にブロックする。 | ||||||||||||||||||
|
| 関連記事（Windows Server Insider） | ||
 |
Windows TIPS：ポート445（ダイレクト・ホスティングSMBサービス）に注意 | |
| 更新履歴 | |
|
 |
 |
 |
「運用 」 |
- 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をインストールしてみる
 |
|
|
|
|
注目のテーマ
Windows Server Insider 記事ランキング
転職／派遣情報を探す
