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

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


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

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

唐突ですが、個人的にちょっと気になるものを見つけました。

真夜中のインターネット
第18回 あなたも感染している?インターネット症候群に要注意!!
http://www.networkworld.jp/midnight/-/50490.html

いわゆる「インターネット症候群」とは、インターネットのナニかに熱中して、 生活などに支障をきたしてしまうことを指し、 20世紀末くらいの頃から言われてきたことのように思います。
今は、SNS やブログ、動画など、昔にはなかったサービスがたくさんありますので、 それに合わせた症例を、10個ほど紹介してくださっています。

読んでみるとわかると思いますが、なにかしらインターネットに関わりのあるひとは、 どれかに必ず当てはまるんじゃなかろうかと思いました。
(わたしの場合、合致はしませんが、自閉型RSS強迫観念と、 ブログ失調症あたりが当てはまっているように思います。)

なにか危機感のようなものを、じんわりと感じております。
視野を広げるという意味でも、PC の前に座る必要のない、 ぜんぜん別のことをやんなきゃいけないですよね。

みなさんも、たまには PC から離れて、体を動かすなどしてみてはいかがでしょうか。

というわけで、今週も、はりきってまいりましょう!

今週のお題 - BIND にいろいろ制限をかける

DNS サーバといえば、BIND のことを指すといっても過言ではないように思います。

BIND にはさまざまな機能があり、それにあわせてさまざまな設定ができるのですが、 設定次第では、セキュリティ上好ましくない状態にしてしまうことも、 しばしば起こりえます。

とはいえ、試行錯誤しながら設定を行い、なんとか動作するところに到達しますと、 それで満足してしまいますよね。

しかし、適切な設定にしていないと、外部から悪用されたり、 不正な情報を送り付けられたりなど、悪いことをされるおそれがあります。
自分の管轄のサイトを悪用されるのもいやですが、 踏台にされてまわりに迷惑をかけてしまうと、 自分だけの責任では済まされなくなります。
ですので、われわれシステム管理者は、そのような事態を極力避ける努力を、 常に行うべきだと言えましょう。ええ、言えますとも。

というわけで今週は、BIND に適切な制限をかける方法を、ご紹介したいと思います。


なにもない状態から、named.conf の書き方をご説明しますと、 とっても時間がかかりますので、すでに設定がされている状態の named.conf に、 設定を足したり引いたりしてみたいと思います。

今回、みなさんにご紹介したい設定内容は、以下の通りです。

  • ゾーン転送の制限。
  • 再帰的な問合せの制限。
  • 問合せ自体の制限。
  • いやな相手には返事を返さない。

順番にご紹介していきますが、面倒くさかったら、 興味のある項目に目を通すだけでも構いません。 ちょっとでも読んでいただけますと幸いです。


それではまず、ゾーン転送に制限をかけてみましょう。
それには、allow-transfer を用います。

通常は、セカンダリサーバからプライマリサーバに対して、ゾーン転送を行います。 ですので、本来であれば、それ以外にゾーン転送の必要はないはずです。
しかし、デフォルトでは誰でもゾーン転送できてしまいますので、以下のように、 options ステートメントでゾーン転送できない設定にします。

  options {
      ...従来の設定たち;
      allow-transfer { none; };
  };

そして、許可するゾーンそれぞれに対して、 ゾーン転送を許すセカンダリサーバを指定します。
以下の例では、usupi.org は 192.168.1.1 からのみ、ゾーン転送を許可しています。

  zone "usupi.org" IN {
      ...従来の設定たち;
      allow-transfer { 192.168.1.1; };
  };

もし、許可するゾーンがなければ、zone ステートメントの中に記述する必要はありません。


次に、再帰的な問合せに制限をかけてみましょう。
それには、allow-recursion や recursion を用います。

デフォルトでは、再帰的な問合せが許可されています。
しかし、ゾーンサーバとしてもキャッシュサーバとしても動作させている場合に、 外部からの問合せには再帰的に答えさせたくないと思います。
そんなときには、組織内からの再帰的な問合せは許可し、 そうでないひとたちからの再帰的な問合せは許可しないようにしたいですよね。
それには、options ステートメントで、以下のように allow-recursion を記述します。

  options {
      ...従来の設定たち;
      allow-recursion { 192.168.1.0/24; };
  };

上記の場合、192.168.1.0/24 に対しては再帰的な問合せを許可し、 それ以外に対しては許可しません。

そうではなく、ゾーンサーバとしてしか動作させていないなら、 再帰的な問い合せ自体を許可しない設定にしてしまいましょう。
それには、options ステートメントで、recursion no と指定します。

  options {
      ...従来の設定たち;
      recursion no;
  };

ただ、再帰的な問合せに制限を加えても、 再帰的な問合せが必要なときにそれを行わなくなるだけです。 すでに、再帰的な問合せを行って、 最終的な答えをキャッシュとして持っている場合は、そのデータを返します。

たとえば、www.linux.or.jp の A レコードがすでにキャッシュにあると、 再帰的な問合せを許可されていないクライアントが www.linux.or.jp を問い合せても、 きちんと答えを返してしまいます。

  % dig @DNSサーバ www.linux.or.jp a in
  ...
  ;; ANSWER SECTION:
  www.linux.or.jp.      86400   IN     CNAME   mizuho.linux.or.jp.
  mizuho.linux.or.jp.   86400   IN     A       210.171.226.47
  ...

ちなみに、キャッシュにない(空っぽの)状態だと、以下のように、 ルートサーバしか返しません。

  % dig @DNSサーバ www.linux.or.jp a in
  ...
  ;; AUTHORITY SECTION:
  .                    3600000 IN      NS      C.ROOT-SERVERS.NET.
  .                    3600000 IN      NS      D.ROOT-SERVERS.NET.
  .                    3600000 IN      NS      E.ROOT-SERVERS.NET.
  ...

それでは次に、問合せ自体に制限をかけてみましょう。
それには、allow-query を用います。

デフォルトでは、誰からの問合せにも、素直に答えます。
しかし、自前でこっそり立ち上げてるなど、特定のひとたちだけのサーバですと、 問合せに制限をかけたいですよね。
それには、options ステートメントで、以下のように allow-query を記述します。

  options {
      ...従来の設定たち;
      allow-query { 192.168.1.0/24; 127.0.0.1; };
  };

上記では、192.168.1.0/24 と 127.0.0.1 からの問合せのみ許可します。

また、allow-query は、ゾーンに対しても設定できます。
たとえば、社内向けのドメインのゾーンに対しては、 社内からしか問合せを許可したくないのではないかと思います。 そんなときには、そのゾーンの中で allow-query を指定します。
以下の例では、in.usupi.org のゾーン情報は、 10.0.0.0/8 にだけ教えるようになります。

  zone "in.usupi.org" IN {
      ...従来の設定たち;
      allow-query { 10.0.0.0/8; };
  };

最後に、特定の相手からの問合せを無視してみましょう。
それには、blackhole を用います。

得たいのしれない相手から、必要に問合せを受けてうっとおしいときなどに、 その相手を無視することができます。
それには、options ステートメントで、以下のように blackhole を記述します。

  options {
      ...従来の設定たち;
      blackhole { 192.168.1.17; };
  };

上記の場合、192.168.1.17 からの問合せには、一切答えなくなります。


以上、BIND の制限の設定について、簡単にご紹介しました。

その時期正しいとされていた設定も、時とともに変化していき、 その設定が無意味になったり、よくないとされるようになることがあります。
ちゃんと設定したからと安心して放置せず、常にアンテナを張って、 最新の正しい状態を保つよう、心がけたいですね。

宿題の答え

先週の宿題は、

  rndc を使って、各 named の動作を確認し、おかしければメールでその
  旨を通知する、というのを定期的に実行する設定をしてください。

でした。

各 named の動作を確認し、おかしければメールで通知するスクリプトは、 こんなふうに仕上げてみました。

  #!/bin/sh
  TMPFILE=/tmp/rndc-all-$$
  trap "rm -f $TMPFILE" 0 1 2 3 9 11 15

  for host in tamao ngw ; do
      output=`rndc -s $host status 2>&1 > /dev/null`
      if [ "z$output" != z ] ; then
          echo "+++ $host"
          echo $output
      fi
  done > $TMPFILE 2>&1
  if [ -s $TMPFILE ] ; then
      Mail -s '[rndc] Alert' root < $TMPFILE
  fi

trap や for あたりは、以前ご紹介した通りです。
for 文の中で、rndc の標準エラー出力を output という変数に代入し、 なにか出力されていれば、echo で出力します。
これらは $TMPFILE というファイルに出力されます。$TMPFILE になにか入っていれば、 その内容を、Mail コマンドを用いてメールします。

あとは、cron で毎日とか毎時とかに起動されるよう設定しておけば、 各所の namedの監視になりますね。
上記スクリプトを /usr/local/sbin/rndc-all.sh というファイル名で保存して、 以下を /etc/crontab に記述すれば、毎朝6時に実行されます。

  0 6 * * * root /usr/local/sbin/rndc-all.sh

あるいは、/etc/cron.daily/rndc-all.sh というファイル名にしますと、 crontab に設定しなくても、毎日実行されるようになります。
(毎時間がいいなら、/etc/cron.hourly/rndc-all.sh です。)

また、エラーメッセージだけでなく、rndc status の出力をすべてメールして、 毎回しっかり確認するようにしても、よいかもしれませんね。

今週の宿題

今週の宿題は、

  allow-query で指定されていない場合と、blackhole で指定された場合
  の動作の違いを、確認しましょう。

です。

どちらも、答えを教えてくれなくなりますが、どう教えてくれないのか、 というところがやや異なります。

ちゃちゃっと設定してみて、dig コマンドで確認してみてください。

あとがき

このメルマガのバックナンバーも、それなりに数が増えてきました。

今までは、バックナンバーをシーケンシャルに並べていたのですが、自分でも、 このネタはいつやったか忘れてしまった、 ということが頻繁に出てくるようになりました。

それではいかんと思い、ちょっとカテゴリに分けてみました。

バックナンバー (目的別)
http://www.usupi.org/sysad/backno2.html

よかれと思ってやったのですが、今見ると、あまりわかりやすくないかもしれません。 相変わらずちょっとごちゃごちゃしています。
もうちょっと、逆引きのような感じで仕上げればいいんでしょうか…。

あと、宿題とその答えのコーナーも作ろうかと思っています。
スクリプトを書いて、宿題と答えの部分を抜き出して、張り付けるようにすれば、 半自動的に作成できそうです。

他に、だいぶ前に知人から指摘された、Linux お試し環境の構築のページも、 用意したいなと思っています。Virtual PC や VMware Player など、 いろいろ無料で使えるものが揃ってきましたので、 設定方法などをうまく書けたらなーと思っています。

以上、中途半端な宣伝でした。

いま、子どもがカゼをひいていて、親2人も、ややその気配があります。
季節の変わり目だからでしょうか。ちょっとは気をつけようと思います。
みなさんも、お体には十分ご注意ください。

 

今週も、ここまで読んでいただき、ありがとうございました。
それでは、また来週に、お会いしましょう!

 

「いますぐ実践! 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://www.fumido.co.jp/kuriniki/ (栗日記ぎゃらりー)


[バックナンバーのトップへ] [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

▼ せんでん




▼ 最近読んだ本

▼ 気に入ってる本