13-3. ファイアウォ−ルとＤＮＳ (1) named.boot でのフォワ−ド指定 '96〜 * フォワ−ド指定の概要 DNS の "単一スプリット・ドメイン構成" は、外部に内部ネットのホスト名情報をさらし たくない場合の DNS の設定方法である。外部用の DNS と内部用の DNS を設ける。 内部 用の DNS には、内部ホストの情報しか基本的に載せない。 これでは内部ホストから外部 にアクセスができない。そこで内部用 DNS に細工をし、この DNS で分からないホスト名 を、外部用 DNS に問い合わせるようにする。これは DNS の "フォワ−ド指定" という機 能である。そして "単一スプリット・ドメイン構成" を実装するためには、DNS の "管理 ゾ−ンの範囲" と "複数の nameserver 指定の意味" を理解する必要がある。さらに外部 用 DNS に内部ホストの情報が無いことによる問題、 DNS の逆引きに答えられないという 問題にも実運用では解決しなければならない。 * ＤＮＳフォワ−ド指定のテスト hostA hostB named ■ 1 □ 2 ｜ ｜ -------------------------------- 192.9.200.0 | ------ | | hostX hostY ------ named ■ 3 □ 4 | ｜ ｜ -------------------------------- 192.9.201.0 [ hostA の named の設定 ] /etc/named.boot ----------------------------------------------------- |cache . /etc/named.ca |primary nix.co.jj /etc/named.hosts |primary 200.9.192.in-addr.arpa /etc/named.rev |primary 0.0.127.in-addr.arpa /etc/named.local named.hosts と named.rev には、hostA の 192.9.200.1 と hostB の 192.9.200.2 の情 報のみ記述する。 /etc/named.ca ------------------------------------------ |. IN NS hostA.nix.co.jj. << '.' のところ nix.co.jj. でもいい。 |hostA.nix.co.jj. IN A 192.9.200.1 [ hostX での named の設定 ] /etc/named.boot ------------------------------------------ |cache . /etc/named.ca << 一応これも入れておくこと。 |forwarders 192.9.200.1 << cache, forwarders, slave はお揃い |slave で使うと思ってよい。 /etc/named.ca ------------------------------------------ |. IN NS hostX.nix.co.jj. << '.' のところ nix.co.jj. でもいい。 |hostX.nix.co.jj. IN A 192.9.201.3 上記 cache の記述はフォワ−ド指定には関係ないはずである。 しかしこれをなしにする と、下記 ping は応答しなかった。また cache の項目があるため、hostX の named には hostA に問い合わせた時のデ−タを保持することになる。 hostX の named は代理検索し、 かつ結果を蓄えて、同じ検索要求がきたら、直ちに答えるという働きをするわけである。 [ hostY の resolver の設定 ] /etc/resolv.conf ------------------------ |nameserver 192.9.201.3 hostY % ping hostB.nix.co.jj 上記のように ping をかけると hostB.nix.co.jj のＩＰアドレスを検索するため、 自ホ ストの /etc/resolv.conf を見て、192.9.201.3 の named に問い合わせる。 この named は何も知らない。しかしどこに聞いたら分かるかは知っている。これが forwarders 部で ある。言ってみれば代理で聞いてくれるわけだ。 hostX の named には forwarders の他、 slave も指定してある。 これは forwarders 指定したＩＰアドレスの named にのみ聞く ように制限する。forwarders 指定する場合は、slave も必ずつけた方が named の設定と して間違いがなくてよい。slave の記述がないと、 forwarders 先で名前解決ができなか ったら named.ca のル−トキャッシュ情報や、これまでキャッシュした情報を元に、問い 合わせしていくことになる。 * ある時期から意味合いが変わって来た `2h/09/M かなり前から Windows サ−バというのがあって、 簡単にファイル共有が実現できるとい うことで少しずつ用いられていた。２０００年前後のことか、ISO とか情報漏洩対策であ るとか、だんだんとパソコンの管理ということが言われるようになった。そこでようやく 日の目を見出したのが Active Directory である。Windows サ−バには初期の頃から、ら しい機能はあったようだが、あまり利用されることはなかった。Active Directory でパ ソコンのログオンのユ−ザ認証がだんだんと当り前のようになっていった。 Active Directory は Windows サ−バによる広範囲な資源管理機能をもっている。ユ−ザ 認証だけでない。LDAPサ−バ機能も包含していると言われる。しかし管理情報が多過ぎて 使いこなすクライアントのソフトウェアが追い付いてないのが現状である。単なるログオ ン管理とパソコンのホスト名管理ぐらいしか実際に使われていない。しかし、このホスト 名管理が実は癖者になった。これをやるためにパソコンのネットワ−ク設定で、ＤＮＳ指 定を Active Directory が動く Windows サ−バのＩＰアドレスにしないといけない。 Active Directory の中にＤＮＳサ−バが組み込まれているのである。 ここでは社内にあ るサ−バなどをＵＲＬ名でアクセスするように記述ができる。http://server1.syanai 何 て指定でイントラサ−バにアクセスできるのである。これはこれで有難い話である。社外 のつまりインタ−ネットへのアクセスでは、別途設けてあるインタ−ネット用のＤＮＳサ −バを参照することになる。 Active Directory でＤＮＳのル−トファイルを持てるのな ら、その必要はないが。さあ−、できるのかな。できないという認識で今まで来たが。 -------------------------------------------------------------------------------- Active Directory が外のＵＲＬ名を解決するために、 別途ＤＮＳサ−バを指定するのが フォワ−ド指定である。これは今日、企業などでの一般的な形態になっていると思われる。 -------------------------------------------------------------------------------- * ＤＮＳサ−バと Active Directory の配置の設計 `2h/09/e [ その１ ] DNS２次はプロバイダになってもらっている。DNS１次は自社で持っている。ＤＭＺに設置 し仮想ＩＰアドレスで、バリアセグメントに出している。Active Directory(AD)を設置し て社内のパソコンのホスト名管理を始めた図。パソコンはネットワ−ク設定でＤＮＳ指定 を 3.4にしている。ADはインタ−ネットのホスト名解決はしないようにしていて、ホスト 名検索はＤＮＳのフォワ−ド指定 1.2 で、DNS１次サ−バに問い合わせる。ADの出現以前 はパソコンのＤＮＳは直接 1.2を指定していた。2000年頃までの一般的な形態。 仮想■DNS1次 1.0 ｜.2 -------------------------- ■ | 2.0 ｜.3 ----- -----------| | AD PC ----- ■ △ 3.0 | ｜.4 ｜ -------------------------- AD でもインタ−ネットの名前解決はできると思うが、 インタ−ネット接続はＵＮＩＸ系 の人等がやってきて、Windows ＯＳの AD には詳しくない。ADの設置は従来の基幹系の人 がホストコンピュ−タのアクセス制限のために行なう場合が多かったようである。ＤＮＳ の指定先はこれと言った指針はない。ＪＰＮＩＣが何らかのガイドラインを出していると かそう言ったことはない。自社内の DNS１次でなく、DNS２次を指定したりもあるだろう。 [ その２ ] 社内にプロキシサ−バを導入したのは、2005年頃だったと思う。とりあえず記憶だけで書 いた。マシンのＯＳは当初は Solaris で Linux に変わっていった。パソコンのブラウザ でプロキシ指定すると、参照ＤＮＳはパソコンのネットワ−ク設定でなくなる。プロキシ サ−バに指定しているＤＮＳを見ることになる。分かりにくい挙動だが、事実なのでしっ かり頭に入れて置きたい。Proxy のＤＮＳ参照先は 1.2 という事になる。 プロキシサ− バはセキュリティ対策の一つとしてこの後、設けられるのが一般的になった。 ■DNS1次 1.0 ｜.2 -------------------------- ■ | 2.0 ｜.3 ----- -----------| | AD SV Proxy■ ----- ■ ○ 3.0 ｜.5 | ｜.4 ｜ -------------------------- プロキシサ−バを専用アプライアンスでなく、Linux などのマシンを使うとホスト名の名 前解決にＤＮＳの他に /etc/hosts が利用できる。社内にいろいろサ−バが増えて、ＩＰ アドレスでアクセスするのを、ホスト名で http://nix_server1 とかでアクセスできれば ということになる。Linux なんかでは /etc/nsswitch.conf で "hosts: files dns" と書 けば名前解決は先ず /etc/hosts を見て、次にＤＮＳサ−バを見る順番になる。 [ その３ ] DNS１次はクラウドサ−ビスを利用して外に出した。 近くにＤＮＳサ−バはあった方が速 やかな名前解決が望めてブラウザ利用のレスポンスもいいはず。ということでＤＮＳキャ ッシュサ−バを社内に設置したという図。AD のＤＮＳフォワ−ドは 3.6 指定。 DNSc は ＤＮＳル−ト情報を持ちインタ−ネットのホスト名解決はできる。 DNS１次はインタ−ネ ットの他から自社ホ−ムペ−ジやメ−ルサ−バのホスト名が検索できるように設けられて いることになる。ＤＮＳの実装 BIND は未だに危険なバグが見つかる。このメンテナンス も含めて自社接続プロバイダなど外部業者に委託するのが望ましい。 ◇SSL-VPN こういうのが ｜仮想 まだあるかも -------------------------- ◇SSL-VPN | ｜ ----- -----------| | AD SV ■ ■ ----- ■ ○ ｜.6 ｜.5 | ｜.4 ｜ -------------------------- DNSc Proxy これからのプロキシサ−バの在り方は。かつては NetCache とか専用アプライアンスが幾 つかあったが姿を消した。今や FortiGateなどＵＴＭにプロキシ機能が入っていたりする。 プロキシ経由のパケットをウィルスやＩＰＳのチェックをさせることも普通である。特に 別途 Linux マシンを立ててプロキシサ−バを設けるまでもない。そんな気がする。 そこ ら辺りの検討は "25-3.インタ−ネットの回線とＤＮＳ" で行なった。また見て頂きたい。 (2) フォワ−ド指定とファイアウォ−ル `21/03 * DNS の forward 機能の確認 hostA はＷＷＷサ−バ、hostB はメ−ルサ−バとして実際に稼働している中でのテストで ある。hostB の named を hostA の named のフォワ−ド指定として設定、 稼働させてみ る。内部ネットワ−クのホストは hostB の named を参照するようにする。つまり各ホス トでのネ−ムサ−バの指定を 192.168.1.1 とするのである。ここでは hostD,Windows 98 をネ−ムサ−バ 192.168.1.1、Netscape Communicator はプロキシを使わない直接インタ −ネット接続の設定にする。HTTP のプロキシの設定をすると、 DNS パケットの動きが違 ってくるので、ここではシンプルな設定にした。マシンは hostA,B とも Solaris 2.6 で ある。Solaris 2.6 ではプログラム名は named ではなく、in.named である。 hostA ｜ WWW ■ □ Router named ｜.3 ｜ hostD の Windows パソコンの --------------------- 202.241.128.0 DNSの設定は、ネ−ムサ−バを | 192.168.1.1 とする。 FireWall-1 ------ | | hostB hostC hostD ------ ■ □ INDY □ Windows | named ｜.1 ｜.3 ｜.4 ---------------------------------------------- 192.168.1.0 [ hostB のＤＮＳのフォワ−ドの設定 ] /etc/named.boot --------------------------- |forwarders 202.241.128.3 << もう問い合わせは全部 hostA の named に回す。 |slave /etc/resolv.conf ファイルなし << このホストではＷＷＷブラウザも使わないため。 /etc/nsswitch.conf で dns なし --------------------------- |hosts: files | | [ hostB の Solaris 2.6 の in.named ] # ls -al /usr/sbin/in.* -r-xr-xr-x 1 bin bin 148972 .. in.named << これ。 -r-xr-xr-x 1 bin bin 6444 .. in.tnamed << DARPA trivial name server。 # /usr/sbin/in.named & << DNS の named デ−モンを起動する。 # /usr/sbin/in.named -d 1 & << named デ−モンを起動した後にやること。次のよ # cat /var/tmp/named.run うにデバッグ・ファイル named.run ができる。 Debug turned ON, Level 1 Version = named 4.9.4-P1 << バ−ジョンはこれ。 bootfile = /etc/named.boot ns_init(/etc/named.boot) forwarders 202.241.128.3 sched_maint: Next interrupt in 900 sec exit ns_init() * DNS パケットの流れの確認 hostB と hostA の間では UDP/53 を通せばいいことが以下で分かる。 フォワ−ドの DNS を設けることによって、ファイアウォ−ルのル−ル設定を絞り込むことができる。以下は hostC の INDY でパケットの流れをみたところである。 hostD の Windows パソコンから、 どこか外に http://www.iij.ad.jp/ などとアクセスすると、 www.iij.ad.jp のＩＰアド レスを hostB 192.168.1.1 の DNS に問い合わせる。ここでは分からないので、この DNS は hostA 202.241.128.3 の DNS に問い合わせる。そして結果を hostB の DNS に返して hostB が hostD に知らせていることが読める。 % tcpdump -n src 192.168.1.4 and udp 15:02:00.541072 192.168.1.4.1033 > 192.168.1.1.53: 1+ (36) １つのホスト名の問 15:02:14.682368 192.168.1.4.1036 > 192.168.1.1.53: 2+ (32) い合わせで１つ % tcpdump -n src 192.168.1.1 and udp 15:20:00.153734 192.168.1.1.53 > 202.241.128.3.53: 42794+ (31) (DF) ２つで１組 15:20:00.157453 192.168.1.1.53 > 192.168.1.4.1072: 1 1/3/3 (170) (DF) * hostB の named のキャッシュの確認 # ps -e | grep in.named 2963 ? 0:00 in.named # kill -INT 2963 << DNS のキャッシュ情報を /var/tmp/named_dump.db に吐き出す。 # cat named_dump.db << まだメモリに何も蓄えられていない。 ; Dumped at Thu Mar 22 13:41:00 2001 ;; ++zone table++ ;; --zone table-- ; Note: Cr=(auth,answer,addtnl,cache) tag only shown for non-auth RR's ; Note: NT=milliseconds for any A RR which we've used as a nameserver ; --- Cache & Data --- ; --- Hints --- # /usr/sbin/nslookup << www.iij.ad.jpのＩＰアドレスを問い合わせてみる。 Default Server: localhost このマシンでは、/etc/resolv.conf ファイルがな Address: 127.0.0.1 くても nslookupコマンドが使えることに注意した い。 > www.iij.ad.jp Server: localhost Address: 127.0.0.1 Non-authoritative answer: ※ＩＩＪを例にさせて頂きました。 Name: www.iij.ad.jp 有名税だと思って許して下さい。 Address: 202.232.2.13 > exit # kill -INT 2963 << さあ、今度は情報がキャッシュされているかな。 # cat named_dump.db ; Dumped at Thu Mar 22 13:43:13 2001 ;; ++zone table++ ;; --zone table-- ; Note: Cr=(auth,answer,addtnl,cache) tag only shown for non-auth RR's ; Note: NT=milliseconds for any A RR which we've used as a nameserver ; --- Cache & Data --- $ORIGIN ad.jp. iij 85759 IN NS dns0.IIJ.AD.jp. ;Cr=addtnl [202.241.128.3] 85759 IN NS dns1.IIJ.AD.jp. ;Cr=addtnl [202.241.128.3] 85759 IN NS ns.tokyo.wide.AD.jp. ;Cr=addtnl [202.241.128.3] $ORIGIN iij.ad.jp. dns0 85759 IN A 202.232.2.44 ;Cr=addtnl [202.241.128.3] dns1 85759 IN A 202.232.15.18 ;Cr=addtnl [202.241.128.3] www 85609 IN A 202.232.2.13 ;Cr=answer [202.241.128.3] $ORIGIN tokyo.wide.ad.jp. ns 171125 IN A 203.178.136.61 ;Cr=addtnl [202.241.128.3] $ORIGIN nix.co.jj. www 3507 IN A 202.241.128.3 ;Cr=addtnl [202.241.128.3] $ORIGIN 0.127.in-addr.arpa. 0 3507 IN NS www.nix.co.jj. ;Cr=addtnl [202.241.128.3] $ORIGIN 0.0.127.in-addr.arpa. 1 3507 IN PTR localhost. ;Cr=auth [202.241.128.3] ; --- Hints --- * モデル・ネットワ−クでの設定 << BIND 8.2.3 の named で >> 10.10.10.1 □hostZ □ .2 プロバイダによる ｜ ｜ DNS２次 ／￣￣￣￣￣￣￣￣￣￣￣￣￣＼ ………… ＼＿＿＿＿＿＿＿＿＿＿＿＿＿／ |hostA'| ： ………… □ Router |.3 仮想ＩＰ ｜.1 ----------*------------------------------------------- 202.241.128.0 ｜ hostA□ named DNS１次 ｜ ｜.1 hostX□ hostG□------------- 192.168.2.0 □hostB named ｜.9 ｜ ｜.1 ------------------------------------------------------ 192.168.1.0 [ hostB に forward の DNS サ−バを設置する：その１ ] 内部ネットワ−クの中でも named を起動し、 外部ヘの問い合わせは公式に稼働している hostA の DNS にフォワ−ドしてみる。制御ファイルは以下のこれだけの記述である。 内 部ネットワ−クの他のホストでは、/etc/resolv.conf などに記述する DNS のＩＰアドレ スは 192.168.1.1 とする。DNS のクライアントから見れば、 hostB もれっきとした DNS サ−バである。このように内部 DNS サ−バを設けるとホスト名解決が早くなる。 forward first; 指定の意味、もしフォワ−ド指定先の 202.241.128.3 マシンが停止して いて、hostB の DNS にキャッシュ情報 10.10.10.1 があったとする。すると 10.10.10.1 ヘも問い合わせに行く。もし 202.241.128.3 と 10.10.10.1 の DNS の情報が異なってい ると、例えば違った hostA.nix.co.jj のＩＰアドレスを返すことになる。 hostB が DNSサ−バとして働くのに、基本的には /etc/resolv.conf ファイルはなくても 構わない。/etc/nsswitch.conf の "hosts: files" の部分に dns の指定をしなくても構 わない。 /usr/local/etc/named.conf --------------------------------- |options { | directory "/usr/local/etc"; | forward first; | forwarders { 202.241.128.3; }; << オプションの forward xxxx 部は、デフォルト |}; は first であることに注意したい。 [ hostB に forward の DNS サ−バを設置する：その２ ] 内部ネットワ−クの中でも named を起動し、外部ヘの問い合わせは hostA の DNSサ−バ にフォワ−ドする。nix.co.jj ドメインの問い合わせは、hostB の DNSサ−バ自身のみに する。forward only; の指定がそうである。この場合 forward first; 指定しても意味が ない。hostA の DNSでは www.nix.co.jj は仮想ＩＰの 202.241.128.3 を返すが、こちら は 192.168.2.1 の実ＩＰアドレスを返すことになる。 内部のユ−ザさんは、特に仮想の ＩＰアドレスを叩くまでもないという場合の話である。 /usr/local/etc/named.conf /usr/local/etc/named.hosts ---------------------------------- ------------------------------------------- |options { |$TTL 86400 | directory "/usr/local/etc"; |@ IN SOA dns.nix.co.jj. katou.nix.co.jj. { | forward only; | 1 3600 360 3600 360 ); | forwarders { 202.241.128.3;}; | IN NS dns.nix.co.jj. |}; | |zone "nix.co.jj" { |localhost. IN A 127.0.0.1 | type master; |www IN A 192.168.2.1 << hostA。 | file "named.hosts"; |mail IN A 192.168.1.1 << hostB。 |}; |file IN A 192.168.1.9 << hostX。 (3) 単一スプリット・ドメイン構成 '96〜 * ネットワ−ク構成の例 一応分かりやすくするため、バリアネットと内部ネットのＩＰアドレスは公式なＩＰアド レスとした。これが基本でクラスＢをサブネットにする場合とか。hostG でＩＰアドレス 変換して、内部ネットにプライベ−トアドレスを使うとかいった応用になる。電子メ−ル については、DNS で内部ネットのホスト情報を隠したいということから、hostA で受けて hostB に中継する設定が自然である。もし hostA が直接、 内部ホストにメ−ルを配送し ようとすると hostA でも結局、内部ホストの情報を持たなくてはならなくなる。 メ−ルリレ−、メ−ルサ−バ構成だと hostA と hostB 間でのメ−ルの中継において、そ れぞれの sendmail は hostA,B のＩＰアドレスを知る必要がある。 このためには、それ ぞれのホストの /etc/hosts ファイルにＩＰアドレスを記述する。 hostA,B の DNS に相 手ホストの情報を追加するやり方もあるが、 hostA の named に内部ホストである hostB の情報を入れることになってしまう。これは面白くない。 メ−ルリレ− | インタ−ネットへ ------- named -------- |hostA| MX hostA |Router| ------- -------- | .1 | ---*-----------*----------*------------ 202.241.128.0、公式ＩＰアドレス | nix.co.jj ドメイン パケットフィ ------- ------- メ−ルサ−バ ルタリング |hostG| |hostB| named ------- ------- | | .1 ---------------*----------*------------ 202.241.129.0、公式ＩＰアドレス ｜.3 ｜.4 nix.co.jj ドメイン □ □ hostX hostY * hostA の named の設定 /etc/named.boot -------------------------------------------------------------- |cache . /etc/named.ca |primary nix.co.jj /etc/named.hosts |primary 128.241.202.in-addr.arpa /etc/named.rev |primary 0.0.127.in-addr.arpa /etc/named.local named.ca はインタ−ネット用のル−ト・キャッシュ・ファイルである。 /etc/named.hosts -------------------------------------------------------------- |@ IN SOA hostA.nix.co.jj. katou.hostA.nix.co.jj. ( | 1 3600 300 3600000 360000 ) | IN NS hostA.nix.co.jj. | IN MX 0 hostA.nix.co.jj. | |localhost. IN A 127.0.0.1 |hostA IN A 202.241.128.1 /etc/named.rev -------------------------------------------------------------- |@ IN SOA hostA.nix.co.jj. katou.hostA.nix.co.jj. ( ... 上に同じ。 | IN NS hostA.nix.co.jj. |1 IN PTR hostA.nix.co.jj. * hostB の named の設定 /etc/named.boot -------------------------------------------------------------- |cache . /etc/named.ca |primary nix.co.jj /etc/named.hosts |;primary 129.241.202.in-addr.arpa /etc/named.rev << 内部で使うだけだから |primary 0.0.127.in-addr.arpa /etc/named.local 別になくても構わない。 | |forwarders 202.241.128.1 << 分からないホスト名は、ここに聞きにいく。 |slave /etc/named.ca ------------------------------------------ |. IN NS hostB.nix.co.jj. |hostB.nix.co.jj. IN A 202.241.129.1 /etc/named.hosts -------------------------------------------------------------- |@ IN SOA hostB.nix.co.jj. katou.hostB.nix.co.jj. ( | 1 3600 300 3600000 360000 ) | IN NS hostB.nix.co.jj. | |localhost. IN A 127.0.0.1 |hostB IN A 202.241.129.1 |hostX IN A 202.241.129.3 |hostY IN A 202.241.129.4 * hostX,Y の resolver の設定 /etc/resolv.conf -------------------------- |nameserver 202.241.129.1 * 追加要求 a. 内部ホストから hostA のＷＷＷサ−バにドメイン名でアクセスしたい hostB /etc/named.hosts -------------------------------------------------------------- |@ IN SOA hostB.nix.co.jj. katou.hostB.nix.co.jj. ( ... |hostX IN A 202.241.129.3 |hostY IN A 202.241.129.4 | |hostA IN A 202.241.128.1 << 追加する。別にこの記述は問題ない。 b. 逆引きに答えるようにしたい hostA /etc/named.rev -------------------------------------------------------------- |@ IN SOA hostA.nix.co.jj. katou.hostA.nix.co.jj. ( ... | IN NS hostA.nix.co.jj. |1 IN PTR hostA.nix.co.jj. | |* IN PTR unknown.nix.co.jj. << 何でもいいから返答する。 内部のホスト hostX,Y からインタ−ネットのホストにアクセスして、 ＩＰアドレスの逆 引きをされた場合の対応である。 逆引きの結果ドメイン名は unknown.nix.co.jj を返す ことになる。 (4) ＩＰアドレスの逆引きチェック '96〜 * DNS による認証の問題 セキュリティを強化したＷＷＷサ−バや、anonymous FTP サイトへアクセスしようとする と許可されない場合が出てきたと、雑誌等に最近書かれている。本当にそうなのか確認し たわけではないが。これはどうもアクセス元のＩＰアドレスから、DNS を使ってちゃんと ホスト名があるか調べているだけのようである。つまり逆引きファイルもちゃんと設定さ れているかを見ている。DNS の逆引きによるチェックというが認証ではない。本当に認証 するならば、ＩＰアドレスからホスト名を検索して、そのホスト名から更にＩＰアドレス をゲットする。両者のＩＰアドレスが等しければ本物であるという判断を行う。 どうも現時点ではこのような認証を組み込んだアプリケ−ションは、ファイアウォ−ルの tcp_wrapper のオプション設定ぐらいしかない。anonymous FTP の wu-ftpdも設定できる みたいだが。rlogin、rsh、sendmail、netstat は DNS の逆引きを行うのみで、ホスト名 さえ引いてくればよしとするようである。アクセス拒否するわけではない。tcpdump でも 使って、どんなパケットが飛んでいるかチェックしてみたい。逆引きはＷＷＷサ−バへの アクセス・ログをＩＰアドレスでなく、ホスト名で記録する場合にも用いられる。 だいぶ長いこと、この逆引きの話は理解できなかった。DNS は当初、逆引き用の制御ファ イルは用意しなくても構わないということだったらしい。それとアクセス自体は、ＩＰア ドレスさえ分かれば DNS は無くてもできてしまう。 アクセス元のＩＰアドレスが信用に 足るものかどうか何も分からない。インタ−ネットに接続するホストは、基本的には全て 国内でいえば JPNIC の DNS の管理下にあるはずだし、そうでなければならない。それな らば逆引き用の制御ファイルもちゃんと用意し、DNS 管理下にあることをチェックできる ようにしようという狙いがあるものと考えられる。 [自ホスト] ---> 自ホストのＩＰアドレスで [相手ホスト] へアクセス % mosaic http://www.tcp-ip.or.jj/ 相手ホストではＩＰアドレスからホスト名を検索 ホスト名=gethostbyaddr(ＩＰアドレス) [ 検索できるかどうかだけをみている ] ↓認証する場合 さらに検索したホスト名からＩＰアドレスを引く ＩＰアドレス=gethostbyname(ホスト名) [ ＩＰアドレスが一致するかチェック ] * 何が問題か コネクションフィルタリング型のファイアウォ−ルの場合は、問題になることはない。内 部ホストから外部へのアクセスは全て、ファイアウォ−ルのホストからのアクセスになる。 このファイアウォ−ルのホストのバリアネット側のＩＰアドレスは、 自社の DNS に登録 することによって、相手ホストからの逆引きの問い合わせに答えることができる。しかし パケットフィルタリング型のファイアウォ−ルでは、DNS をバリアネットと内部ネットで を分けて管理する。 このため、バリアネットの DNS には内部ホストの情報を持っていな いため、逆引きの要求に答えられないのである。 -------------------------------------------------------------------------------- 内部ネットのホスト名情報を外部から隠したい。隠そうとするとアクセスできなくなる！。 -------------------------------------------------------------------------------- チェック ■ ftp.xx.xx.xx ｜ ／￣￣￣￣￣￣￣￣＼ hostA の DNS には DNS ｜ インタ−ネット ｜ hostC の情報がない ------- hostC なし ＼＿＿＿＿＿＿＿＿／ |hostA| ： アクセス拒否 ------- ： | ： -------*-------*------------------------- a ドメイン、バリアネット | ↑ ------- パケット ｜ |hostG| フィルタリング 単一スプリット・ドメイン構成 ↓ ------- | -------*-----*------------*------ a ドメイン、内部ネット | | ------- ------- |hostB| |hostC| % ftp ftp.xx.xx.xx ------- ------- DNS 内部ネット専用 上図にはもう１つ別な問題がある。JPNIC に登録する DNS のＩＰアドレスは hostA のも のである。上記例では hostB の DNS がインタ−ネットに問い合わせしている。DNS の機 能からすれば別段問題があるようには思えない（ただし内部ネットのＩＰアドレスも公式 の場合）。多分本来的には、hostB の DNS には hostA を forwarders 指定し、slave 指 定もすべきだろう。分からないＩＰアドレスの検索は、インタ−ネットのル−ト・キャッ シュに送るのでなく、自サイトの公式 DNS を経由させるのがまっとうではないだろうか。 * 逆引きチェックへの対応 幾つかの方法がある。設定は hostA の DNS で行う。 [b][c] のやり方はちゃんとテスト して確認する必要がある。注意点は、これらの設定をした場合 named デ−モンを再起動 しなければならない。それに named 制御ファイルのシリアル番号も更新して、 プロパイ ダに設置してもらっている２次ネ−ムサ−バにも変更を伝えなければならないことである。 [a] /etc/named.hosts ---------------------------- |hostC IN A 202.241.128.35 << 内部ネットのホスト hostC を追加する。 内部ネットのホスト全部が外部のＷＷＷなどにアクセスしたいというようなことは困 る。結局、内部ネットのホスト情報を外部に全部公開することになってしまう。この 方法が有効なのは特定の内部ホストが ftp をやりたいけどといった場合に限られる。 [b] /etc/named.hosts ---------------------------- | IN NS hostB.nix.co.jj. << 内部ネット用のネ−ムサ−バを追加する。 この設定はできない。内部ネットが nix.co.jjのサブドメインならできるが。しかし これも [a] と同じく、内部ネットのホストの情報を公開することになり面白くない。 [c] /etc/named.rev --------------------------------------------------- |*.3.2.127.in-addr.arpa. IN PTR UNKNOWN.bar.com. 本「ファイアウォ−ル」P.62〜63、ソフトバンク刊にあるやり方である。何でもいい からホスト名を返事してしまえということである。しかし、逆引きチェックだけでな く、認証も行うとなれば UNKNOWN.bar.com のＩＰアドレスは何ということになる。 * 電子メ−ル受取りの対応から [ その１] ------- DNS バリアネット用 |hostA| ------- MX hostC | -----*-----*---------------- a ドメイン（公式ＩＰアドレス） | | パケットフィ------- ------- hostA,B の DNS ルタリング | | |hostC| の２次サ−バ ------- ------- | -------*---------*------ b.a サブドメイン（公式ＩＰアドレス） | ------- |hostB| DNS ------- 「UNIX MAGAZINE」'95/06 に掲載されているマ−ジサ−バの話である。hostC をマ−ジサ −バと呼んでいる。ここの話は電子メ−ルの配送を、内部ネットのホスト情報を隠しつつ、 DNS で可能にするための方法である。外からの電子メ−ルは hostA の DNS の MX レコ− ドにより、hostC に中継される。 hostC まで来ると内部ネットの hostB で管理している DNS のコピ−情報があるため、それによって内部ホストに電子メ−ルが配送されるという ことである。 [ その２] これも本「ファイアウォ−ル」P.62〜63 に掲載されているやり方である。 電子メ−ルは とりあえず hostA に配送される。 hostA から各内部ホストのユ−ザに配送することにな る。この時に /etc/resolv.conf により、 内部ホスト用の DNS を見にいくという具合で ある。ただし、単一スプリット・ドメイン構成の場合は確認すること。 ------- DNS /etc/resolv.conf に hostB を指定 |hostA| ------- MX hostA | -----*-----*---------------- a ドメイン（公式ＩＰアドレス） | パケットフィ------- ------- ルタリング | | |hostB| DNS ------- ------- | | -------*---------*------ b.a サブドメイン（公式ＩＰアドレス） [ その３] ------- DNS |hostA| ------- MX hostA、メ−ルリレ− | -----*----*----------------- a ドメイン（公式ＩＰアドレス） | ------- ------- DNS または /etc/hosts | | |hostB| ------- ------- メ−ルサ−バ | | ------*---------*-------（プライベ−トＩＰアドレス） このケ−スは先の２つとは少し事情が違う。内部ネットのホスト名情報を外部から隠した いのではなく、外に出さないようにしなければならないのである。プライベ−トなＩＰア ドレスを外部に出してはならない。 外部からのメ−ルは hostA の sendmail が先ず受け る。すぐに hostB の sendmail に中継する。配送はここから行う。 hostB で内部ホスト のＩＰアドレスを、内部だけの DNS か /etc/hosts で管理すればいいのである。 (5) DNS 逆引きの確認テスト * DNS の逆引きに答える 本「ファイアウォ−ル」P.62〜63、ソフトバンク刊に書かれている、ＩＰアドレスの逆引 きに答えるやり方を検証してみる。 /etc/named.rev の "*.3.2.127.in-addr.arpa. IN PTR UNKNOWN.bar.com." テストの方法は、下記のようなテスト等価環境で、"12-1. CERN httpd サ−バ" のＷＷＷ サ−バのログのとり方でやってみた。その結果 CERN の % httpd -v によるアクセスログ を見ると、ちゃんと逆引きに答えていることが分かった。 % httpd -v | TCP......... Peer name is `unknown.nix.co.jj' << hostA からアクセスした。 Reading..... socket 6 from host 192.9.200.1 TCP......... Peer name is `hostB.nix.co.jj' << hostB からアクセスした。 Reading..... socket 6 from host 192.9.200.2 * 確認テストの環境 ------- hostB の DNSが、インタ−ネットにドメイン登録 |hostB| 外部用 DNS されている。hostA からインタ−ネットのホスト ------- にアクセスしようとすると、相手がＩＰアドレス | を逆引きする場合、hostB の DNSにホスト名を尋 ------------------ 192.9.200.0 ねにくる。 ｜ □ パケットフィルタリング ｜ --------------- 192.9.201.0 | ------- 外部も引ける内部用 DNS |hostA| ------- ‖ テスト等価環境：hostA,B の DNS の働きだけに注目する。下図では hostA には DNS はなし。hostA,B は同じセグメントに配置してある。 ------- ------- httpd (WWW) /etc/httpd.conf |hostA| |hostB| named (DNS) --------------- ------- ------- resolv.conf |DNS-lookup On | .1 | .2 -------*-----------------------*-------- nix.co.jj ドメイン 192.9.200.0 hostA のＷＷＷブラウザから、hostB のＷＷＷサ−バにアクセスする。ＷＷＷブラウザは この時 Mosaic を使用した。% mosaic http://192.9.200.2。 ＷＷＷサ−バはアクセスさ れると、httpd.conf の "DNS-lookup On" の設定により、 ＩＰアドレス 192.9.200.1 を 元に、ホスト名を調べようとする。 hostB の /etc/resolv.conf の名前解決を hostB 自 身にしてあれば、hostB の named に 192.9.200.1 について問い合わせをする。しかしこ の named の逆引きファイルには、192.9.200.1 は記載されていない。 しかし何でもマッ チする 192.9.200.* があるので 192.9.200.1 がマッチし、ホスト名 unknown.nix.co.jj を返すことになる。何でもマッチするといっても、192.9.200.0 ネットワ−クのＩＰアド レスの範囲である。つまり hostA が実際のネットワ−ク環境、上記では 192.9.201.0 に ある場合は、この方法では対応できないことになる。 * hostB の named 制御ファイル /etc/named.boot ----------------------------------------------------- |cache . /etc/named.ca << 一応これも用意すること。 |primary nix.co.jj /etc/named.hosts |primary 200.9.192.in-addr.arpa /etc/named.rev |primary 0.0.127.in-addr.arpa /etc/named.local << とりあえずなくてもよい。 /etc/named.hosts ------------------------------------------------------------- |@ IN SOA hostB.nix.co.jj. katou.hostB.nix.co.jj. ( | 1996040101 3600 300 3600000 360000 ) | IN NS hostB.nix.co.jj. |localhost. IN A 127.0.0.1 |hostB IN A 192.9.200.2 << hostA の部分が無いことに注意したい。 /etc/named.rev -------------------------------------- |;@ から 360000 ) まで同じ | IN NS hostB.nix.co.jj. |2 IN PTR hostB.nix.co.jj. << 2 と * の項目は逆でも構わない。ちゃん |* IN PTR unknown.nix.co.jj. とマッチしないＩＰアドレス以外は * こ れと扱われる。 * この現象はいかに '02/04 Fire ホストには FireWall-1を入れていて、内部ホストのＩＰアドレスをグロ−バルＩＰ アドレス 202.241.128.2 に変換する。 それにセキュリティ対策のため Fire ホストには ping も効かないようにしている。 そしてhostA の DNS は 202.241.128.2 の逆引きデ− タも含めている。設定に問題はなさそうである。しかしこれで、ftp アクセスが拒否され る場合が出てきた。 202.241.128.3 ftp.xxx.ne.jp ------- www ： |hostA| ｜ ------- DNS１次 □Router | ｜ ---------*-------*------------ nix.co.jj | fire 202.241.128.2 ------- ------- |Fire | |hostB| 192.168.1.2 ------- ------- | | 192.168.1.1 -----------------*---------*----- hostB % ftp ftp.xxx.ne.jp Connected to ftp.xxx.ne.jp. このサイトは wu-ftpd Ver. 2.6.0 を使っている。 220- 220- VALIDATION_CHECKING and DNS_PROOFING of the PASSWORD. 220- 220 FTP server (Version wu-2.6.0(WIN) Sun Dec 26 06:00:00 JST 1999) ready. Name (ftp.xxx.ne.jp:katou): anonymous 530- Sorry, we are unable to map your IP address [202.241.128.2] 530- to a hostname in the DNS. This is probably because your nameserver 530- does not have a PTR record for your address in its tables, or because 530- your reverse nameservers are not registered. We refuse service to 530- hosts whose name cannnot resolve. | アクセスが拒否された hostA % ftp ftp.xxx.ne.jp hostB から外部のある ftpサイトにアクセスした ＯＫ．アクセスできる。 ら、こんなようにアクセスが拒否されてしまった。 ＩＰアドレスの逆引きができないと出ている。そ hostB % nslookup こで念のため % nslookup コマンドで調べてみた。 Default Server: www.nix.co.jj ちゃんと逆引きもできている。hostA からだと問 Address: 202.241.128.3 題なくアクセスできるので、DNS 登録の不具合で はないといえる。それでは一体どうなっているの > fire.nix.co.jj か。多分 ftp.xxx.ne.jp から 202.241.128.2 に Server: www.nix.co.jj %ping のようなチェックをかけているのでないか。 Address: 202.241.128.3 一度 FireWall-1 の設定をかえて %ping、つまり Name: fire.nix.co.jj ICMP を 202.241.128.2 が受け付けるようにして Address: 202.241.128.2 みる。これで確認してみるしかないか。具体的に ＩＰアドレスの逆引きチェックに、ひっかかった > 202.241.128.2 のは初めてだ。 これからは ftp サイトのみなら Server: www.nix.co.jj ず、 HTTP サイトでもチェックをかけるところが Address: 202.241.128.3 出てくるかも知れない。 Name: fire.nix.co.jj Address: 202.241.128.2 * アクセス元チェックのいろいろ `24/05 自分がどこかにアクセスする場合。IIJ のＷＷＷサ−バ、www.iij.ad.jp としようか。最 寄りのＤＮＳサ−バに www.iij.ad.jp のＩＰアドレスを問い合わせる。 返ってきたその ＩＰアドレスで IIJ のＷＷＷサ−バにアクセスする。 この際ＷＷＷサ−バにアクセスさ れた方は、アクセスしに来た相手先に対して次の様な挙動をとることになる。 1) そのままノ−・チェックでアクセスさせる。Apache や sendmail など主要なサ−バソ フトでも、デフォルトは何もチェックしないようになっている。 2) アクセスしてきたＩＰアドレスを逆引きして、 そのホスト名がインタ−ネット上に存 在するか調べる。そして調べるだけでアクセスさせる、または拒否する。 3) 逆引きしてホスト名がインタ−ネット上に存在し、 かつ正引きしてホスト名からＩＰ アドレスを引いて一致するか調べる。調べるだけでアクセスさせる、または拒否する。 * 逆引きに対応するソフト `24/05 *** Solaris 2.x などで *** [ tcp_wrapper ] /etc/inetd.conf ------------------------- tcp_wrapper のプログラム | | ↓ |telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd /etc/hosts.deny --------------- |ALL: PARANOID ソ−スを展開したままでは Makefile に PARANOID= -DPARANOID と記述があり、アクセス してきたＩＰアドレスからホスト名を検索し、更にホスト名からＩＰアドレスを検索して 一致するか調べる。これを PARANOID と言う。アクセス制御ファイルは/etc/hosts.allow と /etc/hosts.deny である。hosts.denyに拒否したいサ−ビス:ホストを列挙する。許可 するのは hosts.allow に記述する、allow 指定が優先される。上の /etc/hosts.deny の 記述は、コンパイルする際には PARANOID 指定なしで tcpd プログラムを作り、稼働時に PARANOID 指定するやり方である。 tcp_wrappers_7.6 の README を見たら、"4.2 - Host name spoofing" に PARANOID のこ とが、"4.3 - Host address spoofing"、"4.4 - Client username lookups" に IDENT の ことが書かれていた。Makefile には HOSTNAME= -DALWAYS_HOSTNAME の記述、どうやらい ろいろアクセス制限ができるようである。他、参考としては http://www.linux.or.jp/JM には hosts_access と tcpd のマニュアルがある。「UNIX MAGAZINE」1992/02,"ＵＮＩＸ の玉手箱 tcp_wrappers と NIS サ−バ−の設定"も詳しい。その後追加「UNIX MAGAZINE」 2004/07, P.62〜66, "プログラミング・テクニック TCP Wrappers"、`27/11。 [ wu-ftpd ] ftpaccess ファイルに次のように記述すると、アクセスしてきたホストで、そのドメイン のネ−ムサ−バが動いてないと拒否する。拒否する際には で指定したフ ァイルを表示する。 /etc/ftpaccess --------------------------------- |deny !nameserved WU-FTPD Development Group がメンテンスをしている。http://www.wu-ftpd.org/ が公式 サイト。最新は "WU-FTP SERVER, RELEASE 2.6.2 - November, 2001"。 展開した doc 内の ftpaccess のマニュアルには次のように書かれている。"Always deny access to host(s) matching . is displayed. may be "!nameserved" to deny access to sites without a working nameserver. [ tcpserver ] % tcpserver -H -R -v -x /etc ... このプログラムはどうか？、分かりにくいですが。 djbdns や qmail の作者が作った ucspi-tcp パッケ−ジに入っているソフト。 オリジナ ルはここ、 http://cr.yp.to/ucspi-tcp/tcpserver.html に "Data-gathering options:" 以下にオプションの説明がある。デ−タ収集オプションということで、要はリモ−トホス トの名前やＩＰアドレスなど調べるけど、どうするかは設定する人にお任せということら しい。日本語訳は http://tools.qmail.jp/ucspi-tcp/tcpserver.html にある。 オプションの説明。 -p はパラノイド( PARANOID )を行なってＩＰアドレスが結果、一致 すれば環境変数の $TCPREMOTEHOSTをセットする。-P はパラノイドは行わない、デフォル ト。-h はリモ−トホスト名を調べ $TCPREMOTEHOST をセットする、デフォルト。-H はリ モ−トホスト名は調べない。-r は IDENT を行ない環境変数 $TCPREMOTEINFO をセットす る、デフォルト。-R は IDENT は行なわない。果て、環境変数の仕組みがどうだったか？。 [ OpenSSH ] 2004/04/19 にリリ−スされた移植版 OpenSSH の 3.8.1p1 でも確認。 逆引きチェックの オプションにかつて VerifyReverseMapping no(デフォルト) というのがあった？。 今は UseDNS に変わり、デフォルトはチェックするの yesになっている。 しかしチェックして も拒否はしないようである。 /usr/local/etc/sshd_config --------------------------- | | |#UseDNS yes | | openssh-3.7.1p2 を展開した ChangeLog -------------------------------------------------------------------------- |20030603 | | deprecate VerifyReverseMapping since it's dangerous if combined | with IP based access control as noted by Mike Harding; replace with | a UseDNS option, UseDNS is on by default and includes the | VerifyReverseMapping check; with itojun@, provos@, ... openssh-3.7.1p2 を展開した sshd_config.5.out -------------------------------------------------------------------------- |UseDNS Specifies whether sshd should lookup the remote host name and | check that the resolved host name for the remote IP address maps | back to the very same IP address. The default is ``yes''.