各種のアプリケーション向けに F 「 eeBSD をチュー #ifndef COMPILING LINT #include "opt lint. h" #ifdef SMP メールサーバを最適化 #endif #endif #error DEVICE POLLING is not compatible with SMP 二ング ー 345 HACK # 69 一般にメールサーバでは、ネットワーク接続の数は非常に多いが、短時間で少量のデータ を転送するとすぐに接続を閉じる。このような場合、多数の小さなネットワークバッフアを 用意すると便利だ。 ネットワーク接続には、送信用と受信用の 2 つのバッフアが必要になる。バッフアのサイ ズは、どれくらいすばやくデータを転送できるかを左右する。また、ネットワークが遅延し た場合には、問題になる前にどれくらいのデータのバックアップをとっておくことができる かを左右する。ネットワークバッフアが小さすぎると、 CPU がネットワークをクリアするた めに待機してデータを処理する回数が増えるので、 CPU のオーバーヘッドが増大する。ネッ トワークバッフアが大きすぎると、バッフアの効率が悪くなりメモリを浪費してしまう。う まくバランスをとることがチューニングの鍵となる。 経験から言うと、確立される接続の数に 32 をかけた数を用意すれば、トラフィックが異常 に急増した場合でも余裕がある。筆者は、試行錯誤を繰り返してこの値を見つけた。例えば、 最大で 128 のサーバが同時にメールを送信すると予想するなら、それぞれ送信用と受信用の 2 つのバッフアを用意し、さらに 32 をかけて、ネットワークバッファクラスタの数を 8 , 192 にするとよい ( 128 x 送受信で 2 x 32 = 8 , 192 ) 。また、接続が完全に閉じるまでに 2 分以上 かかるかもしれないことも覚えておいてほしい。特定の 2 分の間に 128 通以上の電子メール を扱うことがあると予想するなら、それに応じて数を増やさなければならない。 もう 1 つ、調節すべき重要な値がある。ソケットの最大数である。ネットワークバッファ と同じ数のソケットで始め、そこから適切な数にチューニングすればよい。 ネットワークバッファクラスタの数を調べるには、 netstat -m コマンドを実行すればよい。 そして、これらの値を /boot/loader. conf で指定することができる。 kern. ipc. nmbclusters=8192 kern. ipc. maxsockets=8192 どんな性能をチューニングする場合でもそうだが、変更した後でシステムを観察する必要 がある。必要な項目を過大評価、あるいは過小評価していないだろうか。調査結果に基づい て、必ず調整を行わねばならない。

HAC K # 48 232 ー 5 章ネットワーク セージを受け取るのは好ましいことである。こでは、 nowhere. ( om の受信者にメッセージを 送信することを、 mycompany.com の SMTP サーバに要求した。この SMTP サーバは mycompany.com の受信者だけについて責任があるので、もちろん工ラーを出す。 nowhere. ( om の受信者にメッ セージを送信したければ、代わりに nowhere. ( om の SMTP サーノヾに接続すべきだ。 電子メールを送信するには正しい SMTP サーバに接続しなけれはならないが、受 信者の SMTP サーバの名前をどうやって見つければよいのだろうか。それは、と ても簡単だ。企業の DNS サーバは、その目的で MX レコードを保守しなければ ならないからである。詳しくは F[Hack # 47 ] DNS レコードとツールを理解」を 読んでほしい。 メールのリレーをテスト 先ほど述べたように、メールのリレーは有害だと考えられている。ある企業のメールリ レーが有効になっていると、スパマーはその企業の SMTP サーバを利用してスバムを中継さ せることができるからだ。 SMTP サーバを管理している人は、 SMTP のマニュアルを読み、デ フォルトでリレーが無効になっているかどうかを確認してほしい。そして、デフォルトでリ レーが有効になっている場合には、リレーを無効に設定するべきだ。その後で、 telnet セッ ションでポート 25 に接続し、 SMTP サーバが電子メールのリレーを拒否することを確認しよ う。例えば mycompany.com の SMTP サーバには、以下のような応答は返してほしくない。 rcpt to: く beastie@unix.ca 〉 250 Recipient く beastie@unix.ca> 0k このように応答したとすると、この SMTP サーバは unix. ( a の SMTP サーバに中継する意 図があることを示している。 自分の SMTP サーバに telnet で接続したとき、他にどこを見るべきだろうか。バナーに注 意して見てほしい。バナーはパッチレベルが遅れていることを示していないだろうか。どの SMTP 製品を使用しているかを、 telnet で接続してきた人に伝えたいだろうか。 telnet の使 い方を知っている人なら、その製品の既知の欠陥を探すために G 。 og 厄を使用する方法も知っ ているだろう。世界中の人が何を目にするかを正確に知っておくことが望ましい。そして、バ ナーで伝える情報を減らすべきかどうかを判断すればよい。バナーの変更方法については、 telnet は、かけがえのないトラブルシューティングッールだ。例えば、ユーザがメールサー SMTP サーバの状態をテスト 製品のマニュアルを読んでほしい。

HAC K # 47 DNS レコードとツールを理解 Server failed : Query refused Trying 204.101.251.2 Server failed, trying next server: Query refused Trying 204.101.251.1 Server failed, trying next server : Query refused Trying 209.226.175.237 Server failed, trying next server: Query refused Trying 209.226.175.236 Found 1 addresses for dns2. sympatico. ca Found 1 addresses for dnsl. sympatico. ca Found 1 addresses for ns6. bellnexxia. net Found 1 addresses for ns5. bellnexxia. net rcode = 0 (Success), ancount=4 % host -al sympatico ・ ca ー 229 host - al はゾーン転送を要求することを覚えておいてほしい。 DNS サーバは、 この要求を すべての 拒否すべきだ。この例では、 4 つのすべての DNS サーバが要求を受け取ったので、 DNS サーバが動いていることがわかる。 host ユーティリティは、それぞれのサーバからの 書を調べて、定期的に自分の DNS サーバの設定不良をテストすべきかどうかを確認する 自分の DNS サーバの管理を ISP などに依頼している場合、このテストは特に重要だ。契約 バが悪いかがわかるだろう。 否したが、 1 / 3 はゾーン転送を許可した。サーバの応答順序を記録しておけば、どの DNS サー は、数えきれないほど多くの DNS サーバをテストしてきた。そのうち 2 / 3 は問い合わせを拒 だ。特に、ネームサーバの 1 つがゾーン転送に応答する場合、この順序が重要になる。筆者 並んだネームサーバの IP アドレスだ。 2 番目の IP アドレスは、 2 番目のネームサーバのもの ゾーン転送を要求した。その順序に注意してほしい。最初の IP アドレスは、リストの最初に とよい。 参照 ring. pdf) 「 Securing an lnternet Name Server 」 (http : //www.acmebw.com/resources/papers/secu 分割 DNS の実装方法 (http : //www.relevanttechnologies.com/splitdns 081000. asp ) man host ・ man dig

HACK # 47 228 ー 5 章ネットワーク る。世界中からアクセスできるのは、 DMZ 内に置いた部分だけだ。少し時間をとって、どの レコードを世界中に知らせる必要があるかを考えてほしい。おそらく、 DNS サ—Ä(I)MZ 内 の DNS サーバや、 ISP などが提供する 2 番目に望ましい DNS サーバ ) のレコード、 Web サー バのレコード、そして SMTP サーバのレコードなどが該当するだろう。これらのレコードだ けを、 DMZ の小さなゾーンに入れるべきだ。 2 番目のアプローチは、ゾーン転送を厳格に管理する方法だ。最も起こってほしくない事 態は、 DMZ 内の DNS サーバが内部のゾーン全体のコピーを要求することだ。同様に、イン ターネットのユーザが、内部の DNS サーバにネットワーク内のレコードすべてを要求する事 態も避けたい。 ゾーン転送を制御するには複数の方法があり、すべての方法を実装すべきだ。ますは DNS サーバのマニュアルを読み、ゾーン転送を要求できる IP アドレスを制限する方法を調べる必 要がある。これを BIND で実現する方法については、「 Securing an lnternet Name server 」 (http://www.acmebw.com/resources/papers/securing.pdf) を参照してほしい。 2 番目に、ファイアウォールでゾーン転送の制御を設定しなければならない。 DNS は興味 深いプロトコルであり、 TCP と UDP の両方でポート 53 を使用する。まず、ファイアウォー ルで UDP53 を「許可」しなければならない。禁止するとすべての名前解決が止まってしま う。それは悪い事態だ。一方、ゾーン転送では TCP53 を使用する。 TCP53 を許可するにあ たって、ゾーン転送に関与すべき DNS サーバの IP アドレスだけを許可するよう、注意深く ファイアウォール規則を構成しなければならない。そして、変更内容をセカンダリサーバに 転送することを忘れないでほしい。 3 番目に、定期的に DNS サーバをテストするようにガイドラインを作成しておくべきだ。 ネームサーバを保護するのは複雑だということに留意してほしい。どんなことをすると問題 が発生するのだろうか。例えば、 OS のパッチや DNS サーバのアプリケーションパッチを適 用すると、新しい欠陥が生じてしまうことがある。また、ファイアウォールのルールを変更 すると、意図に反してゾーン転送を許可してしまうおそれがある。複数の DNS サーバを ( お そらく複数の場所で ) 使用し、さらに複数のファイアウォールも使用するとなると、誤りを起 こす危険性が増える。日常的なテスト計画を立てれば、そんな誤りを検出できる可能性を高 め、問題が長期にわたって残り続ける危険を排除できる。 DNS をテスト DNS サーバをテストするには、 dig に ax 幵スイッチを渡す方法もあるが、筆者は host -al の出力を好んでいる。このユーティリティに自分のドメイン名を渡して実行すると、以下の ような結果が得られるだろう。

DNS レコードとツールを理解ー 225 もう 1 つ指摘しておきたいのは、返ってきたレコードのタイプが出力の中に現れているこ とだ。各ネームサーバのレコードに NS が付いていることに気づくだろう。 DNS データベー スのレコードに NS があれば、 DNS サーバのレコードを見ていることがわかる。また、 DNS サーバ、 Web サーバ、メールサーバであるかどうかに関係なく、すべてのホストに A レコー ドがある。 A レコードは、ホスト名を IP アドレスにマップする。つまり、 DNS サーバには 2 つのレコードがある。 DNS サーバであることを示す NS レコードと、 IP アドレスのリストを 示す A レコードだ。 出力に現れた 4 つのネームサーバのうち、どれがプライマリネームサーバなのかがわかる だろうか。名前を見て判断してもかまわない。しかし、 SOA(startofauthority) レコードがプ ライマリネームサーバを示すことを知れば、簡単に確実に知ることができる。そこで、 dig コ ード マンドで SOA レコードを表示してみる。 HACK # 47 % dig 50a sympatico ・ ca くバナーを省路〉 ・ ANSWER SECTION : sympatico. ca. admin. sympatico. ca. ( く省略〉 ; AUTHORITY SECTION : sympatico. ca. sympatico. ca. sympatico. 〔 a. sympatico. ca. ; ADDITIONAL SECTION : dns2. sympatico. ca. ns5. bellnexxia. net. ns6. bellnexxia. net. dnsl. sympatico. ca. 16m18S IN SOA 13m38S IN A 18m57S IN A 9m55S IN A 8m36S IN A 3h22m20S IN NS 3h22m20S IN NS 3h22m20S IN NS 3h22m20S IN NS dnsl. sympatico. ca. dns- dns2. sympatico. ca. ns5. bellnexxia. net. ns6. bellnexxia. net. dnsl. sympatico. ca. 204.101.251.2 209.226.175.236 209.226.175.237 204.101.251.1 ; T0taI query time: 239 msec 問い合わせに対して、どのネームサーバが質問に答える「権限」を持っているかも示して バのようだ。さらに、追加のセクションとして AUTHORITY SECTION もある。 ns を除くすべての 答えがわかっただろうか。 dnsl. sympatico. ca つまり 204.101.251.1 がプライマリネームサー ; MSG SIZE sent: 30 rcvd: 228 ; WHEN: Sun NOV 23 17 : 36 : 22 2003 ; FROM: genisis t0 SERVER: default - - 198.235.216.111 ISP の DNS 情報を調べているとき、 SMTP サーバの名前を知りたくなることがある。これ と SOA レコードを一緒に表示できる。 ns でなく、 any の問い合わせを試すことを好む人もいるだろう。そうすれば、 NS レコ いる。

HACK 346 ー # 69 法 手 な 度 7 ファイルサーバを最適化 ファイルサーバをメールサーバと比べると、普通はネットワーク接続の頻度は少なく、接 続時間が長くなることが多い。大きなファイルを転送するのが一般的だからだ。 最適なネットワークバッファクラスタの数を決めるには、いくつのクライアントがあるか を考えればよい。一般に、ネットワークバッフアの数に 2 をかけるのが適切だが、複数のファ イル転送に対応するために 4 をかけることを好む管理者もいる。ファイルサーバに接続する クライアントが 128 ある場合、ネットワークバッファクラスタの数を 1 , 024 に設定するとよ い ( 128 x 送受信で 2 x 4 = 1 , 024 ) 。 Web サーバを最適化 Web ページに複数の要素がある場合 ( 例えば複数のイメージやフレームがある場合 ) 、 Web プラウザが Web サーバに複数の接続を作成すると予想すべきだ。 1 ページあたりで 4 つの接 続を作成することが一般的だ。また、サーバ側のスクリプトで作成するデータベースまたは ネットワーク接続の数も考慮しなければならない。 web サーバの稼働状況は浮き沈みが激しい。クライアントに提供するべージ数が平均で毎 分 100 ページだったとしても、最小のときには毎分 10 ページにすぎず、最大のときには毎分 1 , 000 以上に達するかもしれない。最大の毎分 1 , ページに備え、さらに 2 倍の余裕をみて、 クラスタとソケットを約 16 , 384 に設定するとよいだろう ( 1 , 024 x 送受信で 2 x ページごとに 4 x 余裕 2 = 16 , 384 ) 。 参照 man tuning ・ man gc ( ( GCC のマニュアルページに、 CPU 最適化のコンパイルの説明が載っている ) ・ man ifconfig 「 Tuning FreeBSD for different 叩 plications 」 (http://silverwraith.com/papers/freebsd- tuning. php) 「 ()ptimizing FreeBSD and its kernel 」 (http ://silverwraith.com/papers/freebsd-ker nel. php) ・ Apache サーバのチューニング上の注意 (http://vm.bolthole.com/uuala/webtuning.txt)

5 章 ネットワーク Hack # 42-53 あなたはおそらく、 1 日のほとんどの時間、インターネットまたは組織内ネットワークの サーバにアクセスしているだろう。実際、ネットワークがかなり浸透してきたので、ネット ワークの停止に耐えることは、たとえ短時間であっても困難になってきている。 本章では、通常の通信手段を使用できなくなったときでも、ネットワークサービスにアク セスするための手法をたくさん取り上げる。主要な通信手段が利用できない状態になったと き、新しいネットワーク構成を知らせてくれるようにシステムを整備したいと思ったことは ないだろうか。電子メールクライアントをインストールしていないシステムから、自分の電 子メールを読みたくなることがあるだろうか。 ISP ( インターネットサービスプロバイダ ) の DHCP サーバが自分の DHCP クライアントを認識してくれないとき、どうやってネットワー ク接続を確保すればよいだろうか。 さらに、我々が動いて当然と思っているネットワークサービスやツールが、どんな仕組み で動いているのかを眺めてみる。 t ( pdump の達人になることを目指し、少なくとも恐怖心を取 り払う。 DNS メッセージを理解し、 DNS サーバの問題の解決方法を学ぶ。そして、 sendmail デーモンを意のままに扱えるようにする。 最後に、日常的な作業をすべてのサーバで同時に実行するために、 2 つの優れたオープン ソースのユーティリティを取り上げる。 リモートからログインしてコンソールメッセージを見る リモートからサーバのコンソールメッセージを見たい Unix システムの管理者は、作業の 99 % をリモートから実行することができる。サーバに キーポードを接続したとしても ( [ Hack # 26 】を参照 ) 、実際にサーバの前に座らなければ実施で きない作業は非常に少ない。 その一方、リモート管理で実現できない機能の 1 つが、リモートサーバのコンソールを見 ることだ。ただし、全く見ることができないわけではない。最初に次の質問に答えてほしい。 「コンソールとは何なのか ? なぜ、コンソールを見たいのか ? 」 H A C K

DNS レコードとツールを理解 ー 223 HACK # 47 参照 ・ ethereal の Web サイト (http://www.ethereal.com/) ・ tcpdump の Web サイト (http://www.tcpdump.0てg/) n tcpdump pub/a/bsd/2001/04/04/FreeBSD Basics. html) 「 FreeBSD Basics 」コラムの記事「 Examining ICMP packets 」 (http ://鼎w.onlamp.com/ lamp.com/pub/a/bsd/2001/03/14/FreeBSD Basics. html) 「 FreeBSD Basics 」コラムの記事「 TCP protocol Layers ExpIained 」 (http : //www.on 意味がある ) 。こでは、 sympatico. ca ネットワークのネームサーバ ( ns ) を探ってみる。 gr 叩 er の略で、ドメイン情報を探るという意味。また、 dig という言葉自体にも探るという 別の手段として、 dig ユーティリティを使用する方法がある ( dig は domaininformation nameserver 204.101.251.2 nameserver 204.101.251.1 search domain.org % more /etc/resolv. conf らない人は、次のようにしてみるとよい。 マリとセカンダリの DNS サーバのアドレスを、どこで調べればよいのだろうか。調べ方を知 自宅のシステムの場合、 ISP の DHCP サーバから DNS 情報を受け取ることが多い。プライ ISP の DNS を調査 H A C K も、ダウンロードすることも、自分宛の電子メールを読むこともできなくなるのである。 と、 DNS が働かなければどこにも行くことができない。つまり、 web サーフィンをすること たとえ DNS の管理者でなくても、便利な DNS コマンドを知っておくべきだ。単純に言う サーバ以外の情報が世界中に漏れてしまうかもしれない。 メールサーバを見つけられなくなることがある。さらに悪い場合には、 web サーバとメール にテストしなければならない。 DNS サーバの設定を誤ると、世界中の誰も、 Web サーバと ネットワークサービスの中でも、 DNS は特に注意深く設定しなければならないし、定期的 DNS レコードの謎を解く DNS レコードとツールを理解

HAC K # 74 Web サーバのログを統合 Web サーバを準備 ー 367 ますは Web サーバのユーザ用のホームディレクトリを作成する。 こではユーザ名を w とする。 w 鼎のホームディレクトリを、 /nonexistent でなく /etc/master. passwd の設定と同じ 場所にしなければならない。必要なら、 vipw を使用してパスワードファイルを変更してほ % ssh-keygen -t dsa # su 次に Web サーバのユーザでログインし、 SSH の公開鍵と秘密鍵を作成する。 # chown W 鼎 : 蠡 ~ # mkdir Nwww しい。 % cp $srcdir/logproc/webserver. bin/* bin/ % mkdir -p bin 10g5 / { wo て k , save}/o logs/tmp 10g5 / wo ⅸ / 1 % cd Nwww ログ処理ツールで使用するディレクトリを作成し、そこにスクリプトをコピーする。 これらのスクリプトを調べ、表 7-1 に示した変数を自分の状況にあわせて変更する。 表 7-1 logproc の Web サーバ用スクリプトの変数と値 スクリプト batcher cleantmp ( OP1e て 変数 $loguser $mcast if $ 10gr00t $ 10gr00t $loghost $ 10gr00t $loghost 10g て 00t $loghost_loguser $ s ( p_p rog $ s s h_p rog Web サーバューザの名前 ログホストにアクセスできるインタフェースの名前 Web サーバユーザのホームディレクトリ Web サーバユーザのホームディレクトリ ログを収集するログホストの名前 Web サーバユーザのホームディレクトリ ssh の絶対パスとオプション scp プログラムの絶対パスとオプション ログホストでログを所有するユーザ ログホストでログを収集するディレクトリ 次に、 これらのプログラムが互いに依存関係を満たしていることを確認する。

メールクライアントなしで電子メールを送受信一 231 この出力を順に調べていこう。 telnet コマンドの最後に 25 を付けていることに注目してほ しい。ポート番号の指定を忘れると、きっとプロンプトが現れずに固まってしまうだろう。こ れは、 SMTP サービスに接続しようと試みる代わりに、 ISP のメールサーバからログインプ ロンプトを受け取ろうと試みているからだ。もし実際にログインプロンプトが表示されたと したら、別の ISP に乗り換えたほうがよい。その ISP は明らかにセキュリティをないがしろ にしているからだ。 次の出力は、 SMTP サービスへの接続に成功したことを示している。 TCP / IP の世界では秘 密が少ないことに注意してほしい。 SMTP サーバはバナーを表示し、そのバナーの中で、サー バ上で動いている SMTP アプリケーションのタイプ、そのバージョンとパッチレベル、そし て接続した日時を示す。バナーについては、後に詳しく説明する。 サーバに接続した後で、 2 つの SMTP コマンド MAIL FROM と RCPT TO を実行した。厳格な SMTP サーバは、最初に挨拶 (say hello) しないと、これらのコマンドを認識しないことがあ る。 SMTP サーバが、礼儀が欠けていると不満を言ったら、 HELO または EHLO を入力してみる とよい。こでは、応答が 2xx で始まり 0k で終わったので、 SMTP サーバがコマンドを受け 付けたことがわかる。 5xx で始まる応答はエラーを意味し、入力ミスや間違ったコマンドを使 用したことを示す。ほとんどの SMTP サーバは、期待されるコマンドの構文を表示して、コ マンドの入力を手助けする。 発信者と受信者の電子メールアドレスを指定した後で、 DATA コマンドを入力して CEnter] キーを押した。すると、 SMTP サーバはメッセージの入力を求めてきた。そこで、メッセー ジを入力し、メッセージの終了を示すために、ドット (. ) だけの行を入力した。サーバがメッ セージ番号を応答したので、 QUIT と入力してセッションを終了した。 SMTP コマンドを少し試してみると、面白いことがわかってくる。例えば MAIL FROM コマ ンドは、電子メールアドレスが有効かどうかを確認しないす。このことから考えてみると、 例えば santa@northpole.com や satan@hell.org など、思いっく限りのアドレスを使用して他人 のふりをすることができる。自分に来た電子メールを読むときには、このような特徴を忘れ ないでほしい。あるアドレスから送られてきた電子メールが、本当にその発信元から送られ てきたという保証はないのである。 さらに、 RCPTTO のアドレスを変更してみると、込み入った結果が生じることがある。例え ば、次のようなエラーメッセージが出るかもしれない。 550 relaying mail t0 nowhere.com is not allowed SMTP のリレー ( 中継 ) が起こるのは悪いことだと考えられているので、このエラーメッ す監修注 : 最近は MAILFROM コマンドで与えられたアドレスに対して、一定のチェックを行う メールサーバも増えている。しかし本質的に、サイトの外部から有効なメールアドレスを知る方 法はない。 HAC K # 48