Fig. d41
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.jp /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.jp. << '.' のところ nix.co.jp. でもいい。
|hostA.nix.co.jp. 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.jp. << '.' のところ nix.co.jp. でもいい。
|hostX.nix.co.jp. 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.jp
上記のように ping をかけると hostB.nix.co.jp のＩＰアドレスを検索するため、 自ホ
ストの /etc/resolv.conf を見て、192.9.201.3 の named に問い合わせる。 この named
は何も知らない。しかしどこに聞いたら分かるかは知っている。これが forwarders 部で
ある。言ってみれば代理で聞いてくれるわけだ。 hostX の named には forwarders の他、
slave も指定してある。 これは forwarders 指定したＩＰアドレスの named にのみ聞く
ように制限する。forwarders 指定する場合は、slave も必ずつけた方が named の設定と
して間違いがなくてよい。slave の記述がないと、 forwarders 先で名前解決ができなか
ったら named.ca のル−トキャッシュ情報や、これまでキャッシュした情報を元に、問い
合わせしていくことになる。
(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 では 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
| |
# /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.177.65
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 ---
# 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: ※ IIJ さんを例にさせて頂きました。
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.jp.
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.jp. ;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 ---
(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.jp ドメイン
パケットフィ ------- ------- メ−ルサ−バ
ルタリング |hostG| |hostB| named
------- -------
| | .1
---------------*----------*------------ 202.241.129.0、公式ＩＰアドレス
｜.3 ｜.4 nix.co.jp ドメイン
□ □
hostX hostY
* hostA の named の設定
/etc/named.boot
-------------------------------------------------------------
|cache . /etc/named.ca
|primary nix.co.jp /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.jp. katou.hostA.nix.co.jp. (
| 1 3600 300 3600000 360000 )
| IN NS hostA.nix.co.jp.
| IN MX 0 hostA.nix.co.jp.
|
|localhost. IN A 127.0.0.1
|hostA IN A 202.241.128.1
/etc/named.rev
--------------------------------------------------------------
|@ IN SOA hostA.nix.co.jp. katou.hostA.nix.co.jp. ( ... 上に同じ。
| IN NS hostA.nix.co.jp.
|1 IN PTR hostA.nix.co.jp.
* hostB の named の設定
/etc/named.boot
--------------------------------------------------------------
|cache . /etc/named.ca
|primary nix.co.jp /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.jp.
|hostB.nix.co.jp. IN A 202.241.129.1
/etc/named.hosts
--------------------------------------------------------------
|@ IN SOA hostB.nix.co.jp. katou.hostB.nix.co.jp. (
| 1 3600 300 3600000 360000 )
| IN NS hostB.nix.co.jp.
|
|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.jp. katou.hostB.nix.co.jp. ( ...
|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.jp. katou.hostA.nix.co.jp. ( ...
| IN NS hostA.nix.co.jp.
|1 IN PTR hostA.nix.co.jp.
|
|* IN PTR unknown.nix.co.jp. << 何でもいいから返答する。
内部のホスト hostX,Y からインタ−ネットのホストにアクセスして、 ＩＰアドレスの逆
引きをされた場合の対応である。 逆引きの結果ドメイン名は unknown.nix.co.jp を返す
ことになる。
(4) ＩＰアドレスの逆引きチェック '96〜
* DNS による認証の問題
セキュリティを強化したＷＷＷサ−バや、anonymous FTP サイトへアクセスしようとする
と許可されない場合が出てきたと、雑誌等に最近書かれている。本当にそうなのか確認し
たわけではないが。これはどうもアクセス元のＩＰアドレスから、DNS を使ってちゃんと
ホスト名があるか調べているだけのようである。つまり逆引きファイルもちゃんと設定さ
れているかを見ている。DNS の逆引きによるチェックというが認証ではない。本当に認証
するならば、ＩＰアドレスからホスト名を検索して、そのホスト名から更にＩＰアドレス
をゲットする。両者のＩＰアドレスが等しければ本物であると分かる。
どうも現時点ではこのような認証を組み込んだアプリケ−ションは、ファイアウォ−ルの
tcp_wrapper のオプション設定ぐらいしかない。anonymous FTP の wuftpd も設定できる
みたいだが。rlogin、rsh、sendmail、netstat は DNS の逆引きを行うのみで、ホスト名
さえ引いてくればよしとするようである。アクセス拒否するわけではない。tcpdump でも
使って、どんなパケットが飛んでいるかチェックしてみたい。逆引きはＷＷＷサ−バへの
アクセス・ログをＩＰアドレスでなく、ホスト名で記録する場合にも用いられる。
だいぶ長いこと、この逆引きの話しは理解できなかった。DNS は当初、逆引き用の制御フ
ァイルは用意しなくても構わないということだったらしい。それとアクセスにあたっては
ＩＰアドレスさえ分かれば DNS は無くてもできてしまう。 アクセス元のＩＰアドレスが
信用に足るものかどうか何も分からない。インタ−ネットに接続するホストは、基本的に
は全て DNS の管理下にあるはずだし、そうでなければならない。 それならば逆引き用の
制御ファイルもちゃんと用意し、DNS 管理下にあることをチェックできるようにしようと
いう狙いがあると考えられる。
[自ホスト] ---> 自ホストのＩＰアドレスで [相手ホスト] へアクセス
% mosaic http://www.tcp-ip.or.jp/
相手ホストではＩＰアドレスからホスト名を検索
ホスト名=gethostbyaddr(ＩＰアドレス) [ 検索できるかどうかだけをみている ]
↓認証する場合
さらに検索したホスト名からＩＰアドレスを引く
ＩＰアドレス=gethostbyname(ホスト名) [ ＩＰアドレスが一致するかチェック ]
* 何が問題か
コネクションフィルタリング型のファイアウォ−ルの場合は、問題になることはない。内
部ホストから外部へのアクセスは全て、ファイアウォ−ルのホストからのアクセスになる。
このファイアウォ−ルのホストのバリアネット側のＩＰアドレスは、 自社の DNS に登録
することによって、相手ホストからの逆引きの問い合わせに答えることができる。しかし
パケットフィルタリング型のファイアウォ−ルでは、DNS をバリアネットと内部ネットで
を分けて管理する。 このため、バリアネットの DNS には内部ホストの情報を持っていな
いため、逆引きの要求に答えられないのである。
--------------------------------------------------------------------------------
内部ネットのホスト名情報を外部から隠したい。隠そうとするとアクセスできなくなる！。
--------------------------------------------------------------------------------
Fig. d41
上図にはもう１つ別な問題がある。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.jp. << 内部ネット用のネ−ムサ−バを追加する。
この設定はできない。内部ネットが nix.co.jpのサブドメインならできるが。しかし
これも [a] と同じく、内部ネットのホストの情報を公開することになり面白くない。
[c] /etc/named.rev
---------------------------------------------------
|*.3.2.127.in-addr.arpa. IN PTR UNKNOWN.bar.com.
本「ファイアウォ−ル」P.62〜63、ソフトバンク刊にあるやり方である。何でもいい
からホスト名を返事してしまえということである。しかし、逆引きチェックだけでな
く、認証も行うとなれば UNKNOWN.bar.com のＩＰアドレスは何ということになる。
* 電子メ−ル受取りへの対応から
[ その１]
Fig. d42
「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/27
200.241.128.3 ftp.xxx.ne.jp Fire ホストには FireWall-1 を入れて
------- www ： いて、内部ホストのＩＰアドレスをグロ
|hostA| ｜ −バルＩＰアドレス 200.241.128.2 に
------- DNS１次 □Router 変換する。それにセキュリティ対策のた
| ｜ め Fire ホストには ping も効かないよ
-------*-------*----------- nix.co.jp うにしている。 そしてhostA の DNS は
| fire 200.241.128.2 の逆引きデ−タも含めて
200.241.128.2 ------- ------- いる。設定に問題はなさそうである。し
|Fire | |hostB| かしこれで、ftp アクセスが拒否される
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 [200.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.jp ちゃんと逆引きもできている。hostA からだと問
Address: 200.241.128.3 題なくアクセスできるので、DNS 登録の不具合で
はないといえる。それでは一体どうなっているの
> fire.nix.co.jp か。多分 ftp.xxx.ne.jp から 200.241.128.2 に
Server: www.nix.co.jp %ping のようなチェックをかけているのでないか。
Address: 200.241.128.3
一度 FireWall-1 の設定をかえて %ping、つまり
Name: fire.nix.co.jp ICMP を 200.241.128.2 が受け付けるようにして
Address: 200.241.128.2 みる。これで確認してみるしかないか。具体的に
ＩＰアドレスの逆引きチェックに、ひっかかった
> 200.241.128.2 のは初めてだ。 これからは ftp サイトのみなら
Server: www.nix.co.jp ず、 HTTP サイトでもチェックをかけるところが
Address: 200.241.128.3 出てくるかも知れない。
Name: fire.nix.co.jp
Address: 200.241.128.2
* アクセス元チェックのいろいろ `24/05
自分がどこかにアクセスする場合。IIJ のＷＷＷサ−バ、www.iij.ad.jp としようか。最
寄りのＤＮＳサ−バに www.iij.ad.jp のＩＰアドレスを問い合わせる。 返ってきたその
ＩＰアドレスで IIJ のＷＷＷサ−バにアクセスする。 この際ＷＷＷサ−バにアクセスさ
れた方は、アクセスしに来た相手先に対して次の様な挙動をとることになる。
1) そのままノ−・チェックでアクセスさせる。Apache や sendmail など主要なサ−バソ
フトでも、デフォルトは何もチェックしないようになっている。
2) アクセスしてきたＩＰアドレスを逆引きして、 そのホスト名がインタ−ネット上に存
在するか調べる。そして調べるだけでアクセスさせる、または拒否する。
3) 逆引きしてホスト名がインタ−ネット上に存在し、 かつ正引きしてホスト名からＩＰ
アドレスを引いて一致するか調べる。調べるだけでアクセスさせる、または拒否する。
* 逆引きに対応するソフト `24/05
[ tcp_wrapper ]
/etc/inetd.conf /etc/deny
------------------------- tcp_wrapper のプログラム ---------------
| | ↓ |ALL: PARANOID
|telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
コンパイルはソ−スを展開したままでは、 Makefile に PARANOID= -DPARANOID と記述が
あり、アクセスしてきたＩＰアドレスからホスト名を検索し、さらにホスト名からＩＰア
ドレスを検索して一致するか調べる。 そのこと自体を tcp_wrapper では PARANOID と言
っている。アクセス制御ファイルは /etc/allow と /etc/deny である、 自分で記述する。
/etc/deny でアクセスを拒否したい サ−ビス:ホスト を列挙する。上の /etc/deny の記
述は、コンパイルで PARANOID 指定なしで tcpd プログラムを作って、稼働時にPARANOID
指定する場合である。/etc/allow と /etc/deny では allow 指定が優先される。
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 サ−バ−の設定" も詳しい。
[ 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 ]
/usr/local/etc/sshd_config 2004/04/19 にリリ−スされた移植版 OpenSSH の
--------------------------- 3.8.1p1 でも確認。逆引きチェックのオプション
| | にかつて VerifyReverseMapping no(デフォルト)
|#UseDNS yes というのがあった？。今は 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''.