いますぐ実践! Linuxシステム管理

[バックナンバーのトップへ] [Linux システム管理のトップへ]


いますぐ実践! Linux システム管理 / Vol.204 / 読者数:1860名

こんばんは、うすだです。

前号を発行してからの2週間は、ものすごくテンパっていました。

あるお仕事で、お客様から、レベルが低い! と叱咤されてしまいました。

今までの仕事が割と順調だったため、テングになっていました。
すべては、驕りと、自分の認識の甘さが原因です。
そして、それを指摘してくださるお客様は、よいお客様なのだということを、 上司の指摘と己れの無駄に長い経験から、再認識しました。
(フツーは、2度と仕事の依頼がきません…お、おそろしいですね…。)

というわけで、あとは反省して誠実に作業をすればよい…のですが、 基本的に小心者ですので、ここのところのすべての作業が、 ビクビクしながらになってしまっています。

ですので、ずるずる引きずらないで、すぱっと気持ちを切り替える方法がないか、 模索中です。
よい方法がありましたら、ご教示いただけますと幸いです。> みなさま

今回は、ビクビクしながら、はりきってまいりたいと思います。

今回のお題 - BIND のアクセス制限について考える

前回は、host や dig, nslookup などのコマンドを使って、 DNSの動作を確認する方法をご紹介しました。

Vol.203 - DNSサーバの動作を確認する
http://www.usupi.org/sysad/203.html

今回は、DNSサーバであるBIND側のアクセス制限について考えてみたいと思います。
基本的には、allow- で始まるオプションで設定します。
ああもう知ってるよと思われた貴兄は、 宿題まで読み飛ばしていただいてもおそらく問題ないと思います。

ちなみに、遠い遠ーい昔に、一度取り上げております。
ただ、当時とは状況が異なり、オプションが増えるなどしていますので、 再度取り上げようと思った次第です。

Vol.078 - BIND にいろいろ制限をかける
http://www.usupi.org/sysad/078.html

allow- で始まるオプションの種類

まず、/etc/named.conf(あるいは /etc/bind/named.conf*) に記述できるアクセス制限に関するオプションのうち、 「allow-」で始まる主なものを以下に列挙しました。

  • allow-query
    問合せそのものを許可します。
  • allow-recursion
    再帰問合せを許可します。
    各ドメインのDNSサーバは、通常は、 自分のところのドメイン情報だけを教えてくれます。 これを「コンテンツサーバ」と呼びます。ですが、Windows などの PC のために、 他のDNSサーバに対して再帰的に問い合わせて解決するDNSサーバがいます。 組織やプロバイダの中で使われるサーバです。 これを「キャッシュサーバ」と呼びます。
    ですので、キャッシュサーバとして動かすには、 この allow-recursion で再帰問合せを許可してあげる必要があります。
  • allow-query-cache
    キャッシュされた情報に対する問合せを許可します。
    一度解決した情報は、同じ手順で何度も問合せるのではなく、 一定期間キャッシュして残しておきます。 この情報に対して許可するかどうかを指定するためのオプションです。
  • allow-transfer
    ゾーン転送を許可します。
    通常は、マスターサーバがスレーブサーバに対して許可します。
  • allow-notify
    マスターサーバが自身の情報を更新したときスレーブサーバに通知する notify の受信を、 許可するかどうか指定するオプションです。
    デフォルトではマスターサーバからのみ許可しますし、 それ以外の用途を思いつきませんので、今回は対象外とさせていただきます。
  • allow-update
    Dynamic DNS で、クライアントからの update 要求を許可します。
    Dynamic DNS に関しては別の機会に取り上げたいと思いますので、 今回は対象外とさせていただきます。
  • allow-update-forwarding
    その update 要求を、マスターサーバに転送することを許可します。
    同様に、今回は対象外とさせていただきます。

…ふぅ、主なものだけなのに、たっくさんあるように見えますね。
でも、今回の対象は前半の4つだけなので、ご安心ください。

制限をかける範囲の指定

それぞれに対して、どのように制限をかけるかなんですが、基本的には、 単体のIPアドレスかネットワークアドレスで指定します。

たとえば、192.168.1.1 にだけ allow-transfer を設定したい場合、 以下のように記述します。

  allow-transfer { 192.168.1.1; };

複数のアドレスを指定することもできます。

  allow-transfer {
        192.168.1.1;
        192.168.1.2;
        192.168.1.4;
  };

ネットワークアドレスの場合は、「IPアドレス/プレフィックス」の形式で指定します。

  allow-transfer { 192.168.1/24; };

もちろん、複数指定することもできます。

  allow-transfer {
        192.168.1/24;
        192.168.2.1;
        10.1/16;
  };

こいつは除外したい、という場合は、先頭に「!」をつけます。
たとえば、192.168.1/24 は許可するけれど、 192.168.1.11 は例外で許可したくないという場合は、以下のように設定します。
(順番が逆だと意味がありませんので、ご注意ください。)

  allow-transfer {
        !192.168.1.11;
        192.168.1/24;
  };

よく使う組合せは、acl ステートメントで定義すると便利です。

  acl "internal-nets" {
        192.168.1/24;
        192.168.2.1;
        10.1/16;
  };

としておくと、"internal-nets" という名前で参照できます。

  allow-transfer { internal-nets; };

ちなみに BIND では、デフォルトで以下の名前が定義済です。

  • any
    すべてのアドレスを指します。(すべて許可するときに使います)
  • none
    いずれのアドレスも含まれません。(すべて拒否するときに使います)
  • localhost
    そのDNSサーバの、すべてのネットワークインタフェースに設定されたアドレスを指します。
  • localnets
    そのDNSサーバの、すべてのネットワークインタフェースに設定されたアドレスが属するネットワークを指します。

これらをうまいこと使って、named.conf をすっきり記述すると、 管理者は混乱しなくて済むという寸法です。

options, view, zone 各ステートメントでの設定

allow- なオプションは、options, view および zone ステートメントで設定できます。

options ステートメントでは、そのDNSサーバのデフォルトの設定を記述しておき、 view や zone ステートメントで個々に設定する、という流れになると思います。

たとえば、options ステートメントに、以下の設定を加えます。

  acl "intranet" {
      192.168.1/24;
      fd41:28b7:be11::/64;
      localhost;
  };

  options {
      ...前略...
      allow-query { any; };
      allow-transfer { none; };
      allow-query-cache { intranet; };
      allow-recursion { intranet; }:
      ...後略...
  };

問合せは誰でもOK、ゾーン転送はすべて拒否、 再帰問合せとキャッシュに関しては内部のネットワーク(intranet)だけ許可、 としています。

そして、ゾーン転送に関しては、個々のゾーンで許可します。
また、他が参照する必要のない内部的なゾーンに関しては、 問合せ自体を自分以外できなくします。

  zone "local.usupi.org" {
      type master;
      file "db.local-usupi";
      allow-transfer { intranet; };
  };

  zone "1.168.192.in-addr.arpa" {
       type master;
      file "db.local-usupi.rev";
      allow-transfer { intranet; };
  };

  zone "secret.usupi.org" {
       type master;
      file "db.secret-usupi";
      allow-query { localhost; };
  };

named-checkconf コマンドで確認後、rndc コマンドで再起動します。

  # named-checkconf
  # rndc reload

たとえば、intranet に属するホストから、 local.usupi.orgなどに対するゾーン転送が許可されています。ですので、

  $ host -l local.usupi.org

と実行すると、ごっそりゾーン転送ができます。

ですが、secret.usupi.org に対しては、ゾーン転送はおろか、 問合せもlocalhostしか許可されていません。ですので、 localhost以外から問合せを行っても、

  $ host -t ns secret.usupi.org
  ...中略...
  Host secret.usupi.org not found: 5(REFUSED)

拒否されてしまいます。
もちろん、localhostからは取得できます。

  $ host -t ns secret.usupi.org
  secret.usupi.org name server sec-ns.secret.usupi.org.

おわりに

以上、BINDのアクセス制限について、ざっくりとご紹介しました。

BIND はしょっちゅうバージョンが上がり、 仕様も微妙に変わっていっているように思います。
ですので、上記を鵜呑みにせず、man や付属のドキュメントを見て、 確認してから使うようにしてくださいませ。

宿題の答え

前回の宿題は、

  hostコマンドで行った確認を、dig コマンドでも行ってみましょう。

でした。

まずは、AAAA レコードの問合せです。
ホスト名の後に、知りたいタイプを指定します。

  $ dig foo.local.usupi.org aaaa
  ...中略...
  ;; QUESTION SECTION:
  ;foo.local.usupi.org.         IN      AAAA

  ;; ANSWER SECTION:
  foo.local.usupi.org.  86400   IN      AAAA    fd41:28b7:be11::11
  ...後略...

NS や PTR なども同様です。

  $ dig 11.1.168.192.in-addr.arpa ptr
  ...中略...
  ;; QUESTION SECTION:
  ;11.1.168.192.in-addr.arpa.    IN     PTR

  ;; ANSWER SECTION:
  11.1.168.192.in-addr.arpa. 86400 IN   PTR   foo.local.usupi.org.
  ...後略...

ゾーン転送も、axfr を指定するだけです。(ので割愛します。)

非再帰的な問合せは、「+norecurse」オプションをつけます。
下記の例では、再帰的に問合せていないため、 jp の DNSサーバまでしかわかっていません。

  $ dig www.yahoo.co.jp +norecurse
  ...中略...
  ;; QUESTION SECTION:
  ;www.yahoo.co.jp.		IN	A

  ;; AUTHORITY SECTION:
  jp.			104509	IN	NS	d.dns.jp.
  jp.			104509	IN	NS	c.dns.jp.
  jp.			104509	IN	NS	e.dns.jp.
  ...後略...

あと、変わったオプションとして、「+trace」があります。
これをつけると、再帰的な問合せの過程を出力してくれます。

  $ dig www.nikkei.co.jp +trace
  ...中略...
  .                    274308  IN      NS      c.root-servers.net.
  .                    274308  IN      NS      b.root-servers.net.
  .                    274308  IN      NS      e.root-servers.net.
  ...中略...
  jp.                  172800  IN      NS      d.dns.jp.
  jp.                  172800  IN      NS      g.dns.jp.
  jp.                  172800  IN      NS      a.dns.jp.
  ...中略...
  nikkei.co.jp.        86400   IN      NS      george.nikkei.co.jp.
  nikkei.co.jp.        86400   IN      NS      wendy.nikkei.co.jp.
  nikkei.co.jp.        86400   IN      NS      ns.tokyo.spin.ad.jp.
  ...中略...
  www.nikkei.co.jp.    300     IN      A       138.101.3.199
  ...後略...

ルートサーバから順番にたどって、 最終的に知りたい情報にたどり着いていることがわかります。

他にもいくつかオプションがあります。
興味のある貴兄は、オンラインマニュアル(man dig)を確認するなどして、 いろいろ試してみてください。

今回の宿題

今回の宿題は、

  allow-query-cache の動作確認をしてみましょう。

です。

DNSサーバに情報をキャッシュさせておいて、 その情報を別のホストから取得できるかどうか、allow-query-cache の設定も交えて、 確認したいと思います。

あとがき

私の父は、75歳を過ぎた今も、いちおう現役で働いています。

ですが、私が物心ついたときから今まで、父が、友人とどこかに出かけていったり、 父の友人が我が家へ遊びに来たりといった記憶が、ほとんど…いえ、 まったくありません。

休日も仕事に追われていたり、録画していた番組の編集をしたり、 図書館に出かけたりと、そんなこんなで一日が終わっているようです。

今日、ふとしたことでそのことに気づき、そして、 自分も似たような生活を過ごしていることに気づき、 なんとも言えない気持ちになっています。

いえ、別に、休みの日は寂しくて死にそう…なんてことはなく、 やるべきことややりたいことがあって、それがだいたい一人で完結しているので、 特に誰かを必要としていないだけだ…と思うのです。
(私は友人が極端に少ないので、他の選択肢がない、とも言えますが…。)

ただ、おひとり様になってしまったとき、 同じように楽しく生活できるのだろうかと考えると、 少し不安になってしまったという次第です。

いちおう、120歳まで生きるつもりですので、 まだ 1/3 しか過ぎていないのにそんな心配をしてどうするんだ、 という気もしておりますが…。

休日の過ごし方はともかく、友人が少ない件については改善の余地がありますので、 今後はなるべく人と関わるようにしようと思います。

 

今回も、ここまで読んでいただき、たいへんありがとうございました。
次回は、8月7日(日) の未明にお会いしましょう!

 

「いますぐ実践! Linux システム管理」の解除は、以下からできます。
http://www.usupi.org/sysad/ (まぐまぐ ID:149633)

バックナンバーは、こちらにほぼ全部そろっています。
http://www.usupi.org/sysad/backno.html

「栗日記」- いま、せっせと劇のチラシを描いています…。
http://www.usupi.org/kuri/ (まぐまぐ ID:126454)
http://usupi.seesaa.net/ (栗日記ブログ)
http://usupi.org/k/ (モバイル栗日記)


[バックナンバーのトップへ] [Linux システム管理のトップへ]

トップ

バックナンバー
    [日付順] [目的別]

プロフィール

▼ リンク

独学Linux
Linuxデスクトップ環境に関する情報が満載です。 メルマガもありますよ。
Server World
CentOS 6をサーバとしたときの設定例が、これでもかというくらいたくさん載っています。 CentOS以外のディストリビューション(Fedora, Ubuntu)も充実しています。
LINUXで自宅サーバーを構築・導入(Fedora9)
Fedora9のインストールの仕方から管理方法まで、詳しく載っています。 SearchManには情報がもりだくさんです。
マロンくん.NET
〜サーバ管理者への道〜
Linuxをサーバとして使用するための、いろいろな設定方法が載っています。 マロンくんもかわいいです。 なんといっても、マロンくんという名前がいいですね!!
日経Linux
今や数少なくなってしまったLinuxの雑誌。ニュースやガイドもあります。
Linux Square − @IT
@ITが提供する、Linux の情報が満載。 載っていない設定方法はないんじゃないでしょうか。
gihyo.jp…技術評論社
Linuxに限らず様々な技術情報が満載のサイト。 SoftwareDesign誌も、 ソフトウェア技術者は必見です。
SourceForge.JP Magazine
Linux に限らず、オープンソース関連の記事が網羅されています。
ITmediaエンタープライズ:Linux Tips 一覧
Tips というより FAQ 集でしょうか。わからないことがあれば覗きましょう。
IBM developerWorks : Linux
開発者向けですが、勉強になりますよ。
Yahoo!ニュース - Linux
Yahoo!のLinuxに関するニュース一覧です。
栗日記
システム管理とかと全然関係ありませんが、毎日栗の絵を描いています。
システム管理につかれちゃったとき、癒されたいときに、ご覧ください。:-)
WEB RANKING - PC関連
ランキングに参加してみました。押してやってください。

▼ 作ってみました

Add to Google

▼ せんでん




▼ 最近読んだ本

▼ 気に入ってる本