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

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


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

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

今日は、弁当を持って、ちょっと遠くの公園へ行ってきました。

最近、寒い日が続いていたとはいえ、風の中に、春の匂いが感じられて、 もうすぐ春かなと思わせるものがありました。しかし、今日は、春の匂いどころか、 冬そのもの的な強い風が吹いていて、じっとしていると凍えてしまいそうなので、 老体に鞭打って、常に体を動かしていました。

そんなわけで、結構な運動量をこなし、大人たちは心地よく疲れたのですが、 子どもはまだまだ物足りないようで、さっき寝る前も、やや不満そうにしていました。

子どもの運動量というか成長の速度には、日頃から驚かされていますが、 今日はいつも以上に驚かされました。
いつもなら、足が痛いとか疲れたとかヘタレなことを言うのに、 そういう発言は一度も聞くことがありませんでした。
うれしいような、ちょっとさみしいような、なんとも言えない感じです。

…いやいやいや、親なら、子どもの成長を喜ばなきゃいけませんね。
それでは、今週も、はりきってまいりましょうかね。(年寄り風に…)

今週のお題 - 内部の DNS 情報を見えなくする

それほど規模の大きくない企業や組織では、ゲートウェイ・マシン上で、 外部用の DNS サーバと内部用の DNS サーバを兼ねているところがあると思います。 (マルチホームとかデュアルホームとか言うやつですね。)

しかし、外部の情報と内部の情報を、一緒くたに扱っていると、 外部から内部の情報が、うっかり見えてしまうことがあります。
昨今の情報漏洩に対する厳しい世間の目を考えても、 これは由由しき問題ではないかと思います。

というわけで、会社の存続を担ってしまったシステム管理者各位のため、 今週は、内部向けの DNS 情報が漏洩しないための方法について、 いくつかご紹介したいと思います。


もっとも簡単な方法は、以前にもご紹介しましたが、 問合せやゾーン転送に制限をかけることです。

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

制限したい zone の中で、allow-query や allow-transfer を用いれば、 指定したクライアントからしか見えなくなります。
たとえば、usu.usupi.org の情報を、 192.168.1.0/24 に該当するマシンだけに限定したい場合は、以下のように設定します。

  zone "usu.usupi.org." IN {
      ...既存の設定...;
      allow-query { 192.168.1/24; };
      allow-transfer { 192.168.1/24; };
  };

ちなみに、acl で抽象化すると、変更が楽ですし、見た目もきれいです。

  acl acl_local {
      192.168.1/24;
      127.0.0.1;    /* お好みでどうぞ */
  };

  zone "usu.usupi.org." IN {
      ...既存の設定...;
      allow-query { acl_local; };
      allow-transfer { acl_local; };
  };

ただ、制限したい zone が増えると、ごちゃごちゃしてしまいますね。
また、外部からの再帰的な問合せに応じないように設定したい場合、 この方法ではうまくいきません。


そんなときには、view を使うと、うまくいきます。
zone などの情報を view で囲むと、囲んだ範囲に対して、 同じ制限や設定を適用することができます。
大雑把な書式は、以下の通りです。

  view 名前 {
      match-clients { この view で問合せを許可するクライアント };
      zone とかの設定;
  }

match-clients で、 その view 内の情報を提供してもよいクライアントを指定します。
ちょっと長いですが、例を以下に示します。

  /* 内部情報(ゾーンサーバ兼キャッシュサーバ) */
  view "local" {
      match-clients { 192.168.1/24; };  /* 内部に限定 */
      recursion yes;                    /* 再帰問合せ許可 */
      zone "." IN {
          type hint;
          file "named.root";
      };
      zone "0.0.127.in-addr.arpa" IN {
          type master;
          file "localhost.rev.zone";
      };
      zone "usu.usupi.org" IN {         /* 内部ドメインの設定 */
          type master;
          file "usu.usupi.org.zone";
      };
      zone "1.168.192.in-addr.arpa" IN {
          type master;
          file "usu.usupi.org.rev.zone";
      };
  };
  /* 外部情報(ゾーンサーバ) */
  view "global" {
      match-clients { any; };           /* 誰でもおっけー */
      recursion no;                     /* 再帰問合せに応じない */
      zone "." IN {
          type hint;
          file "named.root";
      };
      zone "0.0.127.in-addr.arpa" IN {
          type master;
          file "localhost.rev.zone";
      };
      zone "usupi.org" IN {             /* 外部ドメインの設定 */
          type master;
          file "usupi.org.zone";
      };
  };

内部向けの "local" と外部向けの "global" に分けた設定です。
"local" は、192.168.1.0/24 からの問合せにのみ応じます。 キャッシュサーバとしても使用しますので、recursion は yes にしています。
かたや "global" の方は、いわゆるゾーンサーバとして動作させるため、 誰からの問合せにも応じますが、再帰的問合せには応じません。


これで、当初の目的は達成できたように思います。
しかし、同じプロセス上(アドレス空間上)に情報がある限り、 バグなどによって漏洩する危険性が、わずかながらでもあるかもしれません。

…という心配症・潔癖症な貴兄は、情報毎に named を立ち上げてしまいましょう。

通常ですと、 すべてのネットワーク・インターフェースで listen しようとしますので、 複数の named を動作させることができません。
しかし、listen-on を使って、 listen するインターフェースを明示的に指定することで、 複数動作させることができます。

たとえば、内部用の named の named.conf は、以下のように記述します。

  options {
      ...既存の設定...;
      listen-on {
          192.168.1.1;        /* 内側のインターフェース */
          127.0.0.1;
      };
  };
  ...内部向けの設定...;

かたや、外部用の named の named.conf は、以下のように記述します。

  options {
      ...既存の設定...;
      listen-on {
          1.2.3.4;            /* 外側のインターフェース */
      };
  };
  ...外部向けの設定...;

これで、かち合うことなく、2つの named を立ち上げられます。
情報も、それぞれの named が持っていますので、 うっかり洩れるということもありません。
(ただし、起動スクリプトなどを書く必要があります。)


以上、内部の DNS 情報を外から見えなくする方法を、ご紹介しました。

どの方法を用いるかは、ケースバイケースですので、どれがもっともよいかを、 うまいこと見極めて使ってみてください。
とりあえず全部試してみる、というのもいいかもしれませんね。

宿題の答え

先週の宿題は、

  ファイルを分割して送信するスクリプトを作りましょう。

でした。

perl5-MIME-tools を使って作りますよと言いましたので、 以下のように作ってみました。

  #!/usr/bin/perl
  use MIME::Entity;
  use strict;

  if($#ARGV < 3) {
      print STDERR "Usage: $0 from to subject attaches...\n";
      exit 1;
  }
  my $fadr = shift;      # 送信元アドレス
  my $tadr = shift;      # 宛先アドレス
  my $subj = shift;      # 件名(の一部)
  my $atts = $#ARGV+1;   # 添付ファイルの総数

  # 添付ファイルを1つずつメールで送信
  for(my $cnt=1; my $file = shift; $cnt++) {
      my $ent = MIME::Entity->build(
          From => $fadr, To => $tadr,
          Subject => sprintf("%s [%d/%d]", $subj, $cnt, $atts),
          Type => 'application/octet-stream', Path => $file);
      &send_mail($fadr, $ent);
  }
  exit 0;

  # メールの送信は sendmail におまかせ
  sub send_mail {
      my ($fadr, $ent) = @_;
      if(open(MAIL, "|/usr/sbin/sendmail -oi $fadr")) {
          $ent->print(\*MAIL);
          close MAIL;
      } else {
          print STDERR "cannot exec sendmail.\n";
          exit 2;
      }
  }

特にひねりはありません。
例えば、secret_file.zip を 1MB 単位で分割し、 foo@example.com さんに送りたいときは、 このファイルを splitsend.pl という名前で保存した場合、 以下のように実行します。

  % chmod +x splitsend.pl
  % split -b1048576 secret_file.zip
  % ./splitsend.pl usu@usupi.org foo@example.com "Secret file" x??
  (rm x?? はお好みで…)

上記は、添付ファイルだけをそっけなく送っていますが、マルチパートなものにして、 メッセージや復元のスクリプトを付加すると、親切かもしれません。 興味のある方は、いろいろいじくってみてください。

今週の宿題

今週の宿題は、

  view を使う場合と listen-on を使う場合の利点を、考えましょう。

です。

view でいいじゃん、の一言で終わらせてしまうと、元も子もありませんので、 せっかくですから、それぞれの利点を考えてみましょう。
はっきりとした答えはないかもしれませんが、わたしも、 数少ない経験を思い出しつつ、考えてみたいと思います。

あとがき

レンタルホストなどを利用していて、サーバが外にある場合、 SSH で侵入できるように設定していると思います。

特定のところからしか SSH で侵入しないなら、 tcp_wrappers でアクセス制限できますが、 外出先などからでもメンテナンスできるようにしたいという場合、 制限をかけられません。

しかし、どこからでも入れるようにしておくと、 あちこちから不正侵入を試みられますので、心穏やかでいられませんよね。

とかいいつつも、わたしは Logwatch の報告メールで満足していました。
でも、同じような悩みを持つひとは多いようで、先日、 オレンジニュースをみていたら、DenyHosts なるものが紹介されていました。

DenyHosts
http://denyhosts.sourceforge.net/

SSH で不正と思われるアクセスがあると、 そこからの SSH のアクセスを禁止する設定を、 /etc/hosts.deny に自動追加してくれる、大変かしこいデーモンさんのようです。 (ちなみに Python で記述されています。)

これは是非活用せねば、と思い、早速、自分のマシンに入れてみました。
幸い、ソースの束だけでなく、RPM なども公開されていましたので、 RPM を使わせていただきました。

設定は、そのまま的に使うのであれば、簡単です。
設定ファイルの雛型(/usr/share/denyhosts/denyhosts.cfg-dist)をコピーして、 chkconfig でサービスを起動するように設定するだけです。
(syslog のパスなどは、念のため確認したほうがよいです。)

とりあえず、自分のマシンに対して、root で侵入しようとしたところ、 以下のエントリがちゃんと追加されました。

  # DenyHosts: Sat Mar 10 22:35:11 2007 | sshd: 192.168.1.222
  sshd: 192.168.1.222

ログが regex.py に書かれたパターンに当てはまると、不正侵入を試みたと判定され、 エントリが追加されます。また、パターンを自由に追加することもできます。

他にも、一定時間経過したら hosts.deny のエントリを削除したり、 sshd 以外のサービスに適用したりなども、できるようです。
もう少し使い倒してみて、問題なさそうなら、 本サーバに入れてみようと思っています。興味のあるかたは、是非お試しください。

こういう、小粒でぴりり的なモノを、いつか作りたいと思っています。
普段から、こんなのがあったらいいなということを、 ピュアな視点で考えておくべきなのかもしれませんね。

 

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

 

「いますぐ実践! 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

▼ せんでん




▼ 最近読んだ本

▼ 気に入ってる本