小規模サイト管理者向け

セキュリティ対策マニュアル

はじめに

インターネットの普及と共に、セキュアな環境を求める声が多くなって

きました。しかし残念なことに、どのような脅威があり、 その脅威から守

るためにどのような方法があるのかといったことはあまり知られていま

せん。特に、小規模サイトにおいては、 専任の管理者を配置すること

ができない等の理由により、 セキュアなサイトを構築し維持することは

難しいという声もあります。しかし、大規模サイトであっても小規模サイト

であっても、 行わなければならないことの根底は違いがありません。ま

た、これまでの攻撃や侵入の例から、 その大半は既存の手法によって

行われることがほとんどです。このことから、サイトの規模に関わらず重

要なことは次の事柄となります。

1. 攻撃や侵入の現状を把握する 2. 適切な措置をとる 3. 常にサイトを監視する

本書では、小規模サイトを対象として、 脅威の例やサイトの構築方

法などをとりあげて、セキュアなサイト構築、 そして運用を行うためのマ

ニュアルとして作成しました。

本書の前提条件

本書では、小規模サイトを前提として記述しています。

規模の違いによって実現方法が異なる部分もあります。 しかし、サイトの規模によ

って設定方法や運用が異なるだけであって根底にあるセキュリティポリシーの大部分

は変わりません。たとえば、組織内からインターネットに対しては HTTP のみしか許可

せず、インターネットから組織内に対しては SMTP 以外は全て不許可とするといったも

のは、Firewall の製品を導入しているサイトの規模に影響されるものではありません。

大規模サイトであれば不許可とし、小規模サイトであれば許可することは基本的に無

いはずです。このことを大前提として記述しており、考え方などは大規模サイトにおい

ても共通するものであると考えています。

構成

本書の構成は、攻撃例の紹介、攻撃毎の防衛方法をまとめています。

攻撃例においては、必ずしも 新のものを記述しているとは限りません。 古典的

な攻撃を中心に取り上げています。

これは、複雑な 新の攻撃例より、 シンプルで理解しやすい古典的な攻撃例を紹介

した方が理解しやすいということから構成しています。

想定するネットワーク

本書において取り上げるネットワークは次の構成を想定しています。

文中の IP アドレス等は、下図と合わせて参照願います。

用途 ネットワークアドレス サブネットマスク

組織内ネットワーク部 192.168.0.0 255.255.255.0

インターネットサービス部 172.16.0.0 255.255.0.0

インターネットサービス部に 172.16.0.0/16 のローカルアドレスを使用しています。

実際には、この部分は各サイトに設定されたグローバルアドレスを使用される場合が

多いはずです。適宜各サイトに割り当てられたグローバルアドレスに置き換えてくださ

い。また、組織内ネットワーク部においては、異なるプライベートアドレスを使用してい

るサイトもあります。これも同様に置き換えてください。

OS

本書において取り上げる OS は Windows 2000, RedHat Linux 7.0, FreeBSD

4.2-RELEASE の 3 種類です。 また、使用するアプリケーションにおいては、 2001 年

3 月においてリリースされているバージョンを使用しています。

これらのバージョンに限らず、 基本的なセキュリティに対する考え方は共通してい

ます。 よって、以降のバージョンにおいても、 設定方法の違いは発生しても設定しな

ければならない項目は同じとして本書を作成しました。

なお、文中で"UNIX"と記述した部分は、 UNIX および UNIX 互換 OS の総称として

記述しています。

第 1 章 小規模サイトをとりまく脅威と現状

現在のインターネット上ではサイトの規模、 個人や法人に限らず様々な脅威に晒

されています。ここでは、実際にどのような攻撃を受けており、 その脅威はどのような

ものであるかを解説します。

1.1 なぜ守らなければならないのか

常時接続環境が増えつつある現在、 小規模サイトにおいてもセキュリティ対策が

望まれています。 これはなぜでしょうか？

「我々のところを攻撃しても何もメリットは無い」と言い切る方もいらっしゃいます。

しかし、単に相手を攻撃するだけではありません。 本来攻撃すべきサイトに対する踏

み台として利用される場合もあります。 また、思いもよらない方法によって誹謗中傷

を受けることもあります。過去には、ほんの軽い誹謗中傷に端を発し、気づかない間

に大きな話となり、 終的にはビジネスに影響を及ぼすといったこともありました。

SOHO 環境では、自宅で仕事を行うということが中心になりますが、 企業内では情

報システム部門がセキュリティを確保しているため、 自身ではセキュリティのことを気

にせずに仕事を行うことができました。 しかし、SOHO 環境のように自宅で仕事を進

める場合、 会社や取引先との間で機密事項が漏れてしまった場合、または見積書

が漏れてしまったがために仕事に支障をきたすということも少なくありません。

そして、小規模サイトの多くは、企業のように専任の管理者を置くことができないた

め、手薄なっているところも少なくありません。昨今、こういうサイトが直接攻撃を受け

る、または踏み台として他サイトへの攻撃に利用されるということが発生しています。

現在必要なことは「なぜ守らなければならないのか」という疑問ではなく 「守らなけ

ればならない」という意思が必要なのです。しかし、闇雲にセキュアな環境を目指すこ

とはできません。 その一つが利便性に問題が出てくるという点です。

たとえば、本当にセキュアな環境にするにはネットワークを物理的に切り離すことで

実現できます。これでは外のネットワークからアクセスされないと同時に自ネットワー

クから外にもアクセスできなくなります。

ネットワークのセキュリティ確保は、 セキュアな環境と利便性という相反するもの

のトレードオフをどこに設定するかであると言えます。

図 1.1-1 物理的に切り離すことによるセキュアな環境

1.1.1 安全はありえない

時々耳にする言葉として 「私たちのネットワークは Firewall を導入しているから安

心だ」 「実績のある業者がセットアップしているから大丈夫だ」 というものがありま

す。

これには大きな間違いがあります。 セキュリティ上、「安全である」「大丈夫である」

ということは、 構築した時点では言えるかもしれません。 しかし、時間の経過と共に

それはどんどん陳腐化してゆきます。ネットワークセキュリティを確保するために重要

なことは、 システムや業者の技術ではありません。 もろん、これらは初期導入時に

必要なものです。 導入時のまま放置していること、そして安心してしまうことが問題な

のです。

セキュリティを確保するための 3 つの要素があります。 これを怠ると費用や手間を

かけて設定したものが意味の無いものになってしまいます。 場合によっては、費用

や手間をかけずに構築したネットワークの方がセキュアな環境になっているときもあり

ます。

セキュアな環境を維持する 3要素 • 最新セキュリティ情報の入手 • 新たな問題に対する対処 • 日常の監視

セキュアな環境を維持するには、まず 新の情報を入手しなければなりません。

現在、どのような問題が発生しているのか。そして、その問題は自ネットワークにお

いて関係あるのか等です。もし、Firewall 製品を導入している場合は、その製品に関

係のある情報を得ることも可能です。もし、関係のある問題があれば、その対処方法

を考えます。そのサービスを停止すべきか、続行するのであればどのように対処すべ

きかといったものです。大抵は、ソフトウェアにパッチをあてる作業や、設定を追加す

るといった作業が伴います。場合によっては、停止し代替のサービスを提供するとい

ったこともあります。

情報の入手や対処方法を考えるにあたって必ず必要ななものが日常の監視です。

自サイトではネットワークを利用してどのようなサービスを提供しているのか、 何が

動いているのか、そして外部からどのようなパケットが届いているのかを監視し自サ

イトの状態を把握する必要があるのです。自サイトの状態を把握していなければ、

新の情報を入手したところで、何が関係あるのか見当もつかないといったことにもなり

かねません。

これらの事に必須となる条件があります。それは、セキュアな環境に対する意識で

す。 この意識が欠けていると、新しいセキュリティ情報の入手を行わなくなります。

新しいセキュリティ情報の入手を行わなくなると、 発生している問題が判らず対処が

遅れるということになります。 さらには、日常の監視を怠る結果に繋がってくるので

す。

サイトをセキュアな環境にするためには、ソフトウェアやハードウェアの機能ではな

く、管理する方達の意識と、その意識に基づいた 3 つの要素が必要となります。

1.1.2 主な攻撃の種類

常時接続環境において特に言えることですが、 気づかない間に攻撃を受けている

場合が多くあります。 また、パソコンの調子が悪いと勘違いしている場合もあります

が、 この状態においても攻撃を受けているかもしれないのです。

主な攻撃はいくつかの種類に大きく分類されます。ポートスキャンを攻撃としてみな

すかどうかにおいては意見の分かれるところですが、 本書では、攻撃の準備として

行うポートスキャンは攻撃の一つとみなします。

• ポートスキャン • DoS

• リモートアクセスのバックドア

図 1.1.2-1 攻撃の 3段階

図 1.1.2-2 泥棒の 3段階

• リモートコントロールのバックドア • トロイの木馬 • Web Page書き換え • スクリプト

多くの場合、攻撃を行う前に攻撃対象を絞る必要があります。 これは、主にポート

スキャン と呼ばれる行為により攻撃対象の絞込みを行います。 この攻撃対象は、

対象となるホストと、そのホストでは何処に攻撃をすることが有効か、どこから侵入で

きそうか等を探ります。もちろん、対象となるホストが確定している場合であっても、

ポートスキャンが行われます。よって、ポートスキャンは攻撃を受ける前兆として考え

る必要があり、 そこで見つけた弱点が攻撃を受けることとなります。

これは、空き巣などが泥棒に入るときの手順と同じと考えることができます。泥棒は、

目的の住居や事務所などで施錠されていない部分を探し、 または壊しやすい鍵の個

所を探します。

次に、実際に侵入し、貴重品などを盗むという手順です。留守にするときだけでなく、

使用していない窓やドアは施錠を行う。 これと同様のことがネットワーク上において

も言えるのです。

しかし、必ずポートスキャンが行われるとは限りません。たとえば、トロイの木馬を

仕掛け、管理者やユーザのパスワードを取得する場合、 弱点を突いて侵入やプログ

ラムを送り込むこともありますが、 ユーザが自らトロイの木馬を入れてしまう場合もあ

ります。

これは、Web Page に ActiveX コントロールなどを使用して、 そのページを参照した

Web クライアントに仕掛けるというものです。 この場合は、特に目標となるネットワー

クやホストが決まっているわけではなく、 不特定多数を相手にしていることになりま

すが、 気づかないうちに仕掛けられているということがあるのです。

1.1.3 弱点とは

では、その弱点とは何でしょうか？

よく言われるものに、脆弱性や危険性などがあります。 主なものを以下に列挙しま

す。

• セキュリティホールなどの脆弱性を突いた攻撃 • パスワードやデータ盗聴による漏洩の危険性と脅威 • パスワード解析による漏洩の危険性と脅威 • メールサーバの Third-Party Mail Relayによる迷惑行為 • スクリプトやプログラムの脆弱性を突いた攻撃

主に、セキュリティホールを狙い root や Administrator 権限を取得するケースや、

対象となるホストで何らかのプログラムを動作させるものがあります。また、これはス

クリプトやプログラムのバグを利用する場合もあります。 特にプログラムのバグによ

って他のプログラムを動作させたり、 動作を停止させてしまうものには"Buffer Over

Flow"と呼ばれる種類があります。

Buffer Over Flowに関しては、 管理者側で対処することが難しいため、本書では取り上げませ

ん。

1.1.4 なぜ攻撃されるのか

攻撃を受ける理由はいくつか存在します。

主なものを列挙します。

• 怨恨によるもの • ポートスキャンによってたまたま見つけたもの • 愉快犯によるもの

• 好奇心によるもの • 政治的理由によるもの • 利益を得るためのもの

多くの場合は、この例のどれかに該当します。たとえば、退職した元社員(元職員)

が嫌がらせの目的で侵入しデータ等を消去するといったケースや、単なる好奇心から

ゲーム感覚で攻撃するケースなど様々です。

自サイトが攻撃される覚えが無いからと言って安心はできません。 たまたま目にと

まったサイトだから攻撃したという例や、ドメインの一覧を入手し、それらを全て絨毯

爆撃方式で攻撃していくことも多くあります。

冒頭で述べたように「我々のところを攻撃しても何もメリットは無い」 と考えるのは

明らかに誤りなのです。

昨今、非常に多いケースがメールサーバの 3rd party relay を利用した spam メール

の配信です。 内容は通信販売やマルチ商法の勧誘など多岐にわたります。

多くの人は、このようなメールを受け取っても興味を持つどころか嫌な気分になりが

ちですが、インターネットの電子メールという特性を利用し、無料で多くの人に対して

強制的にメールを配送してしまいます。

この場合、たとえば10万人にメールを送信したと仮定し、99%の人が内容とこのメー

ルのために使用した通信費用のことで嫌悪感を持ち、残り 1%の人が興味を持ったとし

ます。 このとき、10 万人の 1%にあたる 1,000 人が興味を持ったということです。

spam メールを配信する側は、これだけでも十分な利益を得ることができます。 しか

も、メールの配信は無料であり、10 万人に対して送信するためのサーバは、全く異な

る組織のメールサーバを勝手に利用しているためコストがかかりません。さらに、郵

便によるダイレクトメールや電話によるセールスと異なり、10万人に対して送信するに

は、目の前にあるキーボードを叩くだけで済むのです。

1.1.5 実際にどのような攻撃があるのか

ここで、実際にどのような攻撃に晒されているかを見てみましょう。

これまで行われてきた主な攻撃例を実際に解説します。 なお、ここでは「どのよう

な攻撃があるのか」という点にのみ解説し、 その手法などは一部を除いて公開しま

せん。

攻撃の実例

ポートスキャン スクリプト

spam パスワード解析

IP Spoofing 盗聴

DoS リモートアクセス

バックドア リモートコントロール

トロイの木馬 Web Page改竄

1.1.6 何を守らなければならないのか

セキュアな環境を構築するうえで、重要なことは闇雲に恐れないということと、 セキ

ュリティを甘く見ないということです。この 2 つは矛盾しているようですが、両者共に重

要なのです。

たとえば、闇雲に恐れた結果、非常にセキュアなサイトになったと仮定します。 し

かし、こういったサイトの多くは利便性が下がる結果となります。なぜなら、 もセキュ

アなサイトはネットワークから物理的に切り離したサイトであるからです。これでは通

常の業務は行えません。そして、セキュリティというものを甘く考えてしまった場合、

結果的に世界中から攻撃を受け、 業務に支障をきたすこととなることも考えられま

す。

この攻撃を受けるホストは Web サーバやメールサーバだけではありません。 たと

えば、クライアントで動作しているプログラムを悪用したり、 踏み台として利用される

といったことが現実に発生しています。

では、この矛盾する 2 つをどのように考えるべきでしょうか。

セキュアな環境を構築するということは、何かを守るということです。 この何かによ

って大きく異なります。

サーバにあるデータ、CPU やネットワークなどの資源、顧客の情報、そしてサイトの信

用といったものが挙げられるでしょう。これらの何を守らなければならないのかという

ことを考えたうえで、恐れずかつ甘く見ないということが必要になってきます。

まず、闇雲に恐れても仕方がありません。 攻撃する側が、どのような攻撃を行い、

その攻撃を受けたときの影響は何かということを見極めて対策をとっていくことが必要

になります。そうしなければ、全く意味の無い部分に対して貴重な時間と費用を投入

することになります。

正確な数字を出すことは困難ですが、おおよそ現在のサイトに対する脅威のほと

んどは既存の手法によるものです。言い換えるなら、これまでにどのような手法で攻

撃が行われたかを把握することによって、ほとんどのの攻撃は回避可能です。回避

が難しいものは、唯一新しい手法で攻撃された場合になります。

つまり、日頃から情報を収集し、適切な対処を行っておくことが必要なのです。 この

作業を行わなければ、時間と共にセキュアな環境とは言えなくなるのです。

1.2 ポートスキャン

相手ホストにダメージを与える、若しくは侵入するといったとき、 事前の準備としポ

ートスキャンと呼ばれることを行う場合が多くあります。

ポートスキャンは、泥棒が家屋に侵入する、どこに鍵がかかっているか、 そして鍵

がかかっていないところを探す行為に近いと考えることができます。

ポートスキャンが違法行為かどうかは意見の分かれるところですが、 悪意を持っ

た場合もあります。ポートスキャンを受ける側としては、穴を見せないということが必

要です。 攻撃する側からは、ポートスキャンを行い、穴を発見するとそこから攻撃を

行います。 つまり、弱い部分を見せると確実に狙われるということです。攻撃を受け

ないためには、弱い部分を発見するポートスキャンを受けた段階で、 弱味を見せな

いということが大前提なのです。

ポートの状態を確認した後は、攻撃するために OS を絞り込む作業を行います。こ

れによって、より的確な攻撃を行うことができます。

ポートスキャンは攻撃のときばかり使用するわけではありません。 管理者が、どの

ポートが空いているのか等を確認するときにも使用します。これは、ポートスキャンに

限らず、スキャナ全般において言えることです。

まずは、不要なポートが空いていないかポートスキャンを行う必要があります。 も

し、ポートスキャンの結果が問題無いようであっても安心はできません。 安全性を確

認するものではなく、少しでも安全な環境に近づくためのものに過ぎないのです。

1.2.1 ポートスキャンの実際

では実際にポートスキャンはどのようにして行われるのでしょうか。

まず、ポートスキャンを行うには、相手を絞る必要があります。 この相手を絞るた

めのものはいくつかありますが、たとえば次のようなものです。

• 急激に人気の出たサイト • 新規構築されたサイト • 個人や SOHOなどで使用されやすい常時接続サイト • ダイレクトメールなどの一覧から割り出したサイト • ドメイン一覧の順

このように、ある程度対象を絞ります。次に対象となるサイトがどの IP アドレスを使

用しているかを調べます。これは、ドメイン情報から簡単に確認することができます。

スキャン対象となるサイトの IP アドレスの範囲が割り出せると、実際にどの IP アド

レスにホストが接続されているかを調べる作業に入ります。

画面 1.2.1-1 稼動ホストを調べる

このように、スキャン対象のサイトには192.168.0.1というIPアドレスが実際に使用さ

れていることがわかります。

それでは、この IP アドレス(192.168.0.1)に対してどのポートが開いているかをポート

スキャンによって確認してみます。

画面 1.2.1-2 ポートスキャンの実行

ここまでで対象となるホストはポート 21,22,23,25,111 が空いていることが分かりま

した。 このポートに対して攻撃を行うことになります。攻撃する側からは、 闇雲に攻

撃を仕掛けるのでは時間と労力の無駄になります。

たとえば、存在しないホストに対して攻撃するほど無駄なことはないでしょう。 同様

に、空いてもいないポートに対して攻撃を行っても大きな意味はありません。

ただし、ポートスキャンで空いていないポートにも攻撃を行うことは可能です。 空い

ていないポートが安全なのではなく、空いているより良いという程度に考えておくよう

にしてください。

なお、ポートスキャンで使用するツールは元々管理用として作成されたものです。

1.2.2 ポートスキャンの各種方法

ポートスキャンにはいくつかの方法があります。 どれも TCP/IP の特性を利用した

ものです。 これを表にまとめました。

表 1.2.2-1 ポートスキャンの主な方法

方法 TCP/UDP 概要

TCP スキャン

TCP 標的ポートに接続し、 3way ハンドシェークと呼ばれるSYN-SYN/ACK-ACKのシーケンスを実行します。 被攻撃サイトにおいてスキャン行為の検出は容易。

SYN スキャン

TCP

完全な TCP接続を行わないスキャン手法です。 ハーフオープンスキャンまたはステルススキャンと呼ばれています。 代わりに、SYNパケットを標的のポートに送信する。

• 標的ポートから SYN/ACK を受信した場合のポートはリスン状態

• 標的ポートから RST/ACK を受信した場合のポートは非リスン状態

FIN スキャン

TCP

標的に FINパケットを送信するスキャン手法です。 標的ホストは、RFC793に基づき、 クローズした全てのポートに RSTを送り返さなければなりません。 この手法は、UNIXの BSDソケットにしか通用しません。

クリスマ

スツリー スキャン

TCP

標的ポートに、FIN,URG,PUSHパケットを送信するスキャン手法です。 FINスキャン同様、標的ホストはクローズした全てのポートについてRSTを送り返さなければなりません。

NULL スキャン

TCP 全てのフラグを"0"にするスキャン手法。 FINスキャン同様、標的ホストはクローズした全てのポートについてRSTを送り返さなければなりません。

UDP スキャン

UDP

標的ポートに UDP パケットを送信。標的ポートが "ICMP port unreachable" というメッセージで応答した場合、ポートはクローズされていることを確認するスキャン手法です。 パケットフィルタリングを施したデバイスに対する UDP スキャンは、 比較的時間がかかります。 また、UDP の性質上、ネットワーク越しにスキャンを行う場合の信頼性は非常に低くなります。

1.2.3 スタックフィンガープリンティングとは？

スタックフィンガープリンティングとは、ホストの OS を特定するものです。

OS が特定されるとその攻撃方法の範囲が決まります。 以下で紹介する nmap は

元々管理用として作成されたものであり、自組織内部で利用するものです。 管理用

のツールによってポートがオープンされていなくても OS 特定が可能となります。

• FINプローブ • 偽フラグプローブ • ISN(Initial Sequece Number)サンプリング • フラグメント処理 • 非フラグメントビット処理 • TCP初期ウィンドウサイズ • ICMPエラーメッセージ抑制 • ICMPメッセージ引用 • ICMPエラーメッセージエコーインテグリティ • TOS • TCPオプション

1.2.4 Anonymous FTP によるポートスキャン

サーバ側でポートスキャンの状況をロギングしにくい方法があります。 この方法の

一つが Anonymous FTP を使用したポートスキャンです。

FTP は、コマンドとデータの通信では異なるポートを利用します。 これによって、ロ

ギング上では FTP の利用として見える訳なのです。

しかし、下記のように 500 番代のエラーを返す FTP サーバのソフトウェアを使用す

るか、 設定を加えることで FTP によるポートスキャンは回避することができます。

1. Anonymous FTPに telnet(ポート 21)で接続する。 2. ユーザ名 anonymousでログイン。

user anonymous 3. パスワードとしてメールアドレスを入力します。

pass mymail@attack.co.jp 4. PORTコマンドで IPアドレスとポート番号を送ります。

port IPアドレス,ポート 1,ポート 2 ここで、500 番台の数字が返された場合、 この Anonymous FTP サーバではポートスキャンを行うことができません。

5. もし PORTコマンドが利用可能であれば LISTコマンドでファイルリストを取得 list

6. PORTコマンドの結果を確認 指定されたポートが開いているならば 150 が返され、 ポートが開いていないならば 425が返されます。 425 Can't build data connection: Connection refused.

このようにあらゆる手法によってポートスキャンが行われています。

注意してログ等を確認しないと気づかないこともあります。 そして、ポートスキャンを

受け発見された弱点から攻撃や踏み台として利用されるのです。

1.3 IP Spoofing

IP Spoofing とは、IP アドレス偽装攻撃とも呼ばれ、基本的な手法の一つです。

これは、自 IP アドレスを相手の IP アドレス等に偽装し攻撃を仕掛けたり、 Firewall

を突破するという方法です。単独で利用する場合、相手のホストが IP アドレスで接続

先を制限している場合や、 相手のホストに侵入したとき、logなどに自IPアドレスが残

されると困る場合などに使用されました。

この手法が考え出されたときには、このような使用がなされていましたが、 現在で

は DoS 攻撃に使用するなど、 他の攻撃手法の中で応用されています。

図 1.3-1 IP Spoofingの一例

IP Spoofing は、信頼と認証の関係において隙を突くものです。

ホストやネットワーク同士を接続するにあたり、相手が信頼できる場合は認証を緩

め、 信頼できない場合は認証を高めるということが基本となります。

1.3.1 どのようにして偽装するのか

それでは、実際に IP Spoofing がどのようにして行われるのか、 その原理を説明し

ます。

(1) rコマンドの危険性

一般に、UNIX 等で実装されている r 系コマンドと呼ばれる rsh,rlogin,rcp といったコ

マンドは危険であり、 これらが使用するポートは塞ぐという方法が推奨されていま

す。

r 系コマンドが危険であるという理由は、相手の IP アドレスで信頼できると判断して

しまう点にあります。 前述の、「相手が信頼できる場合は認証を緩める」という部分に

該当するのです。

r 系コマンドでは、/etc/hosts.equiv や.rhosts が信頼しえるホストかどうかの判断に

使用されます。 これらのファイルに記述されたホストは信頼できるホストであると判断

し、 以降の認証が行われません。

たとえば、/etc/hosts.equiv に以下のようなデータが書かれていた場合を想定しま

す。

host1.sample.com host2.sample.com host3.sample.com yamada

この例では、host1 と host2 の全ユーザ、host3 のユーザである yamada さんに関し

ては、 r 系コマンドにおいてパスワードの認証は行われません。

ここで、IP Spoofing は IP アドレスを偽るものであるということを思い出ししてください。

IP アドレスを偽るということはホスト名を偽ることに繋がります。 許可されていないホ

ストであっても、IP アドレスを偽ることによって host1 や host2 に簡単に入れてしまうの

です。もちろん host3 においても yamada さんのユーザ名を使用している限りパスワー

ドの認証も無く自由に入れるのです。

このように、IP Spoofing は r 系コマンドに対しては重大な問題を引き起こすことにな

ります。

(2) IP Spoofingの原理

では、実際にどのように偽装するのでしょうか。

まず、攻撃側は r 系コマンドを使用する場合、 信頼されているホストを知る必要が

あります。 r 系コマンドを使用せず、他のホストになりすまし、 そこからの攻撃に見せ

かける場合はその IP アドレスを知るだけで済みます。

ここで使用するホストは 3 つあります。1 つは IP Spoofing を使用して侵入しようとす

るホスト。もう一つは IP Spoofing によって騙され侵入を許してしまう対象となるホスト。

そして、侵入を許してしまうホストが偽装に使用される(騙されるIPアドレスを実際に所

有する)ホストの 3 つです。

攻撃側は、まず攻撃する対象となるホスト

に対してダミーの接続を行います。 これによって初期シーケンス番号を対象となるホスト

が返すため、 攻撃側は初期シーケンス番号を知ることができます。 次に、偽装に使用されるホストが稼動してい

るかを調べます。 ただし、必ずしも攻撃側からは確認できるとは限りません。 もし稼動していた場合、これを止める必要があります。 なぜなら、攻撃する側が偽装しようとしている IPアドレスの本物のパケットが実際に流れると

攻撃は成立しません。 攻撃側は、たとえば DoS 攻撃等で偽装に使用されるホストを停止させることがあります。 偽装に使用するホストが停止すると、 そのホストの IP アドレスを偽装して静かに攻撃を行うことができるのです。 ここから実際に侵入を行い攻撃を始める手

順になるのです。 シーケンス番号を取得しているので、あとは IPアドレスを偽装するだけです。

図 1.3.1-1 IP Spoofingの原理

IP アドレスを偽装し新たに対象となるホストに対してコネクションを張ります。 しかし、このパケットに対する応答は攻撃側には届きません。 なぜなら、対象となるホストのIP アドレスが設定され、 シーケンス番号も正しく設定されているからです。 よって、応答のパケットは偽装に使用されたホストの方に行きます。応答のパケットが届かなくとも、

攻撃側は次に送信すべきパケットは判っています。 これで偽装が完了しました。 対象となるホストに侵入し、攻撃側のホストに対して信頼するよう設定する等を行い、 実際の攻撃を始めるわけです。しかも、これらの操作は、対象となるホストのログには、 偽装に使用されたホストが行った操作のように記録されているのです。 ログは全て正しい情報を記録しているとは限りません。 パケットの情報を正しくロギングしていることには間違いありませんが、 そのパケットが偽装されているかもしれないのです。 (3) シーケンス番号

ここで使った「シーケンス番号」とは何でしょうか。

これは、TCP/IP のパケットに一連の番号を割り振り、パケットの順序などを識別す

るために使用されます。 パケットを受け取ったホストでは、エラーチェックを行い、正

しく受け取った場合は送信元に対してどのシーケンス番号を受け取ったかの応答を

行います。

応答を行う際、シーケンス番号に 1 を加えた値を設定し確認応答番号として送信元

に返します。もし、IP Spoofing を行おうとするならば、いくつかの作業を伴うことになり

ます。

まず、ソースアドレスと呼ばれる送信元の IP アドレスを偽装する作業です。 そして、

シーケンス番号を間違いなく設定する作業が発生します。

ソースアドレスを書き換え偽装することは、そう難しいことではありません。 問題は

シーケンス番号を設定することにあります。 IP Spoofing が発見された当時、 OS によ

ってグローバルシーケンス番号と呼ばれるものを使用するものもありました。 これは、

一秒間に 128 増加し、接続ごとに 64 増加していました。 そして、新たに接続が行わ

れるときは、 このシーケンス番号でポート確立を行っていたのです。

もし、シーケンス番号の推測に成功すれば、セッションを確立することができます。

そして、攻撃する側のホストが信頼されることとなり、認証が緩くなるのです。 この後

に行うことは、たとえばhosts.equivや.rhostsを書き換えて次回の攻撃の準備を行うの

です。

なお、シーケンス番号を使用する方法は、現在では古典的な方法であり、 容易に

は行えません。 原理の一つとして考えてください。

1.3.2 類似の手法

IP Spoofing のように発信元を偽装する手法はいくつかあります。

主なものを以下に示します。

• ARP Spoofing • UDP Spoofing • DNS Spoofing • Mail Spoofing

Mail Spoofing は基本的な手法であり、悪意を持った場合だけでなく、 通常の運用

でも使用されます。

たとえば、組織の窓口にあたるメールアドレスに問い合わせのメールが着た場合、

返信を行う人のメールアドレスで返信を行うのではなく、 たとえば

support@ipa-sec.com といったメールアドレスで返信するものです。

これを悪意を持って行った場合、From:フィールドやEnvelopを攻撃対象のメールアド

レスに設定し送信するということになります。この場合、メールの本文はメールアドレ

ス本人の名誉を傷つけることや虚偽の情報を記述し多くの人に対して送信します。

これが Mail Spoofing です。

1.4 パスワード解析

いとも簡単にパスワードが知られてしまうことがあります。 これはなぜでしょうか。

よく言われることなのでご存知の方も多いでしょう。 ユーザ側におけるパスワード

は主に次のように習慣付けるよう推奨されています。

• 定期的に変更する • 類推されやすいものは避ける • 前回のログアウト時間を確認する • アカウント作成時に付与されたパスワードは使用しない

定期的に変更するということは、 侵入しようとする者がパスワード解析を行うとき

の猶予期間を短くします。これは、システムをどう守るかということ以前であり、 セキ

ュリティの基礎かつ有効な方法となります。

しかし、盗聴によるパスワード取得が行われることに対しては全く意味を持ちません。

ここで防げる攻撃は、パスワードを類推し入力するものやブルートフォースアタックに

対してであり、パスワードを解析できる時間を縮めることにより解析しにくくするという

ものです。 ブルートフォースアタックに関しては後述します。

また、管理者側においては次のようにサーバーの設定変更を推奨されています。

• シャドウパスワードの導入 • パスワード有効期限の設定 • ワンタイムパスワード • 通信経路の暗号化 • アカウント作成時に付与したパスワードを変更させる

新しいUNIXシステムであれば、ほとんどの場合がシャドウパスワードが設定されて

いるはずです。また、オプションで設定することも可能になっています。

また、ユーザに対して頻繁にパスワードを変更するよう促しても、 全員が守ってく

れるとは限りません。 そこで、パスワードの有効期限が設定することができます。 こ

れによって、30 日毎に強制的なパスワード変更を行わせることができるようになりま

す。たとえば、パスワードの有効期限を 30 日と設定しした場合、 パスワードの解析を

試みる側には 30 日間の猶予期間があるということになります。

これも危険であると判断した場合は、ワンタイムパスワードを設定させる方法もあり

ます。ワンタイムパスワードは、毎回新しいパスワードを発行する仕組みであるため、

パスワードの解析は大変な作業になります。

1.4.1 類推しやすいパスワード例

パスワードも頻繁に変更しておけば何でも良いというわけではありません。

現実に設定してはいけないパスワードの例を挙げます。

• ユーザ名と同一 • 姓名または姓名の片方(yamadaや taro) • ユーザ名に数字を加えたもの(yamada01) • 製品名や商標名(Windowsや UNIX) • 名詞(bookや pencil) • 地名(tokyo) • 組織の略語(ipa) • 規則のある数字や英字(777や abcde) • キーボードの配列(qwert)

ユーザ名と同一のパスワードを設定してはいけないことは良く知られていることで

す。 しかし、他の項目は何故でしょうか。

パスワード解析を行うには主に 3 つの方法があります。

1. 辞書攻撃 2. ブルートフォースアタック 3. 盗聴

(1) ブルートフォースアタック

Brute force password cracking とも言われます。 これはは単純な文字の組み合わ

せを総当たり戦で試みるものです。

解析の時間が非常にかかる方法ですが、時間さえあれば確実にパスワードを取得

することができます。パスワードを頻繁に変えるということは、ブルートフォースアタッ

クに対して非常に有効なのです。

もし固有名詞などが使用されているパスワードであれば、 それらのデータを集め

試したほうがブルートフォースアタックより短期間でパスワードを見つけることができま

す。これが、辞書攻撃と呼ばれるものです。

(2) 辞書攻撃

もし、パスワードの文字列に辞書にあるような単語や、人名、 製品や商標名といっ

たものを使っている場合、 辞書攻撃によってパスワードを解析される可能性が高くな

ります。

パスワード解析に使用される辞書は、英和辞典などに掲載されている単語だけで

なく、 人名、地名といったものや、よく使われるユーザ名などを入れておきます。 さら

に、この中に規則性を持たせた文字列も入れておきます。 たとえば"777" や"aaaa"

といったものです。これを順に試していくわけです。なお、辞書攻撃で発見されたパス

ワードは”Joe”と呼ばれます。

この辞書には、変換規則を考慮したデータもあります。

たとえば、"taro"のように"orat"の文字列を逆順にしたり、 "tAro"のように一部を

文字の大文字にすることや、"taro1"のように先頭や末尾に数字を付けるというものも

あります。ユーザ名や固有名詞を使用していても数字や大小文字を使用しているか

ら大丈夫ということはありません。

(3) 盗聴

パスワードを確実に得るためには盗聴という手段があります。

盗聴には 2 種類あります。

一つ目は、相手がシステムなどにログインするときを待って、 サーバとクライアント

の間でやりとりされる情報をキャプチャリングしパスワードを取得するのです。この方

法であれば、暗号化されたパスワードを解析する手間が省けます。

二つ目は、盗聴ということとは少し離れますが、後述のパスワードのメモを残すとい

うことに関連します。たとえば、職場などでパスワードを紙に書いてディスプレイに貼り

付けている場合、 このパスワードを得るには自由に出入りできる者であれぱ容易に

パスワードを取得することができるのです。

盗聴によるパスワード取得は、主にネットワークの同じセグメントに居る場合や、

パスワードを書いた紙に対して物理的に近いということがあります。しかし、同じネット

ワークのセグメントということは、たとえば ISP にダイヤルアップで接続した場合を考え

ると、LAN 上での話に留まらないのです。また、遠隔地のシステムにパスワードを盗

聴するプログラムを仕込み、 取得したパスワードをメールで通知する等といった手法

もあります。 これは、トロイの木馬と呼ばれるものの一種です。

1.4.2 パスワードの設定

これまでのように、ワンタイムパスワードや通信経路の暗号化を行わなければ安全

であるとは言えません。しかし、出来る限り安全に近づける努力が必要です。

パスワードには、英数字および記号を使用することができます。

これらを組み合わせて辞書攻撃を極力回避する必要があります。たとえば

"hUj#l-7Zk"といった全く意味の無いパスワードになるほど類推が難しくなるため辞書

攻撃を回避することができます。しかし、その反面、このようなパスワードを設定した

場合、ユーザが覚えることが難しくなり、紙にパスワードのメモを残すといったことに繋

がります。

パスワードのメモは残してはいけません。

たとえば、パスワードを書いた付箋紙をディスプレイに貼り付けておくといったこと

は、根本的な部分に問題があるため行うべきではありません。設定するパスワードは、

覚えやすく、類推されにくいものでなければなりません。

パスワードの文字列だけでなく、その長さも問題になります。

言うまでも無く、パスワードはシステムが許容する範囲で長ければ長い程良いので

す。 その反面、あまりに長いパスワードはユーザが覚えきれないという問題もありま

す。 ユーザが覚えきれないほど長いパスワードは、結果として紙にメモを残すという

ことに繋がります。

1.4.3 パスワードファイル

実際に設定されたパスワードを UNIX システムを例にとって見てみます。

以下の行は UNIX のパスワードファイルの例です。1 ユーザあたり 1 行が設定され、

それぞれユーザ名や暗号化されたパスワードが ":" で区切られ記録されています。

表 1.4.3-1 では、その中の一行を示し、それぞれのフィールドを解説します。

表 1.4.3-1 パスワードファイルの内容

yamada:E5lYr5uCcib194viiRgRq2xu:2000:500::::YAMADA Jiro:/home/yamada:/bin/csh

ユーザ名 yamada

パスワード E5lYr5uCcib194viiRgRq2xu

UID(ユーザ ID) 2000

GID(グループ ID) 500

ログインクラス

パスワード変更期限

ユーザアカウントの有効期限

GECOS(名前等) YAMADA Jiro

ホームディレクトリ /home/yamada

ログインシェル /bin/csh

ユーザ名の長さは UNIX システムによって異なります。 慣習として、8 文字以下の

英数小文字で付与します。

数字のみのユーザ名も作成可能ですが、chown コマンドやアプリケーションで問題

を起こしかねないためあまり使用されません。

問題は次のパスワードフィールドです。このパスワードフィールドの文字列は、本来

のパスワードを MD5 や DES で暗号化したものであり、不可逆なものです。 よって、こ

の文字列からパスワードを生成することは事実上不可能とされています。

1.4.4 パスワード解析

ここまでパスワードについて解析しましたが、暗号化され不可逆なパスワードをど

のように解析するのでしょうか？

暗号化されたパスワードの文字列に可逆性を持たせることが事実上不可能なこと

ですが、同じパスワードから暗号化されたパスワードを作成することは可能です。

これには crypt 関数を使用します。 crypt 関数を使用する若干のコードを記述する

と指定した文字列が暗号化されます。 暗号化された文字列は、crypt 関数に対して

同じ引数で引き渡され得られた結果と同じはずです。

パスワードを解析することは、暗号化された文字列を復号するわけではなく、 解析

する元の文字列を暗号化し、その結果を照合するのです。よって、復号できなくとも問

題はないのです。

画面 1.4.4-1 パスワード解析

1.4.5 シャドウパスワード

従来の UNIX システムでは、暗号化されたパスワードが記述された passwd ファイル

は、そのシステムのユーザであれば誰でも見ることのできるものでした。

しかし、これまで解説してきたように、その内容からパスワードを解析することがで

きるため、通常のユーザには見えないように暗号化されたパスワードのみ別に管理さ

れるようになりました。これがシャドウパスワードです。

シャドウパスワードを用いなければ、そのシステムのユーザだけでなく、 セキュリテ

ィホールによって、 外部のユーザからも passwd ファイルが取得できるようになった場

合、 危険度が高まります。

よって、別の管理方法をとり、 /etc/passwd には暗号化されたパスワードは記述し

ないようにしています。

しかし、これにも問題があり、内外部のユーザを問わず、 OS の種類とバージョンが

判れば、 パスワードが記述されたファイル名を類推することができるのです。

もし、仮に root 権限で動作するアプリケーションがあり、 このアプリケーションのセ

キュリティホールを利用し、 シャドウパスワードのファイルを取得するといったことも

可能なのです。

これらの攻撃から守るためには、 ログイン毎にパスワードのフレーズが変わるワ

ンタイムパスワード等の導入が必要となってきます。

1.5 盗聴

盗聴は映画や現実の世界でワイヤレスマイクを主体として行われるものや、 電話

の盗聴などを連想します。 ネットワーク上でも、これとよく似たものがあります。 スニ

ッフィングやタッピングと呼ばれます。

この行為そのものは、直接何かの攻撃を行うというものではなく、 ポートスキャン

に近いものです。 しかし、ネットワーク上を平文で流れるパスワードやメールの中身

などは、 暗号化されていない限り全て盗聴可能なのです。

特に、現在使用されている IPv4 と呼ばれる仕様ではパケットの暗号化は含まれて

いません。IPv6 ではパケットの暗号化や認証の仕組みが組み込まれていますが、

我々が現在使用しているものは、ほとんどが IPv4 の仕様に基づくものです。

1.5.1 盗聴

盗聴を行うためのソフトウェアの入手は簡単です。OS に添付されている場合もあり

ます。そもそも、ネットワーク管理を目的としたものですが、悪用することによってネッ

トワーク上のデータを盗聴することができます。

たとえば、Windows 2000 のネットワークモニタや、UNIX システムで広く使用されて

いる tcpdump 等が代表的な例です。

これらを使用すると、管理のためにパケットを見ていても、 どこからどこに対して

telnet し、 ログインなどのやりとりまでも見えてしまいます。 もちろん、これが見えな

ければ障害などの原因究明ができないため、 実行には管理者の権限が必要になっ

ているのです。

画面 1.5.1-1 Windows 2000のネットワークモニタでログインデータをキャプチャリング

盗聴することによって得られる情報は、ネットワーク上を流れる全てのデータとなり

ます。

その中で攻撃する側にとってメリットがあるものは限られているでしょう。

• ユーザ名とパスワード • メールの内容 • クレジットカードの情報 • 住所や電話番号等の個人情報

telnet でシステムにログインする際、ユーザ名やパスワードを入力します。 このと

きのデータは、ネットワーク上を平文で流れます。

もちろん、作業を行い su コマンドを使用したときのパスワードも全て平文で流れま

す。 つまり telnet を使用した場合、全ての操作は見られていると考えて良いでしょう。

また、メールシステムとして SMTP/POP を使用している場合、POP のユーザ名や

パスワードはもちろん、取り込んだメールや SMTP で送信しているメールも全て盗聴

可能です。

たとえば、関係者以外には漏らせないような機密事項を SMTP で送信するというこ

とは、 SMTP を使用している時点で機密ではなくなるのです。

1.5.2 盗聴の手法

盗聴を行うには、あらゆるホストに何らかのモジュールを仕込む必要はありません。

特に、シェアードハブを使用しているネットワークであれば、 盗聴を行うためのパソコ

ンが 1 台あれば十分です。そのパソコンを近くにあるハブの空いているポートに刺す

だけで盗聴が可能なのです。

しかし、スイッチング処理を行っているネットワークでは急に難しくなります。 そこで

行われる手法は、サーバに盗聴のモジュールを仕込む手法です。 これによって、サ

ーバに対してデータのやりとりが発生するものに関してを盗聴することができます。

ここまでの内容で重要なことに気づかれるでしょう。 盗聴を行うには、その LAN に

対して実際に入り込む必要があります。

対象となる LAN の者が盗聴するには、何らかの方法でリモートのホストにデータを

送る必要があります。

クライアントやサーバに侵入し、盗聴のモジュールを仕込み、 そのデータをリモー

トで送信するという手法です。 この場合、 大の障壁は侵入しなければならないとい

う点です。 このために、相手に対して盗聴用のモジュールを実行するように偽装した

メールを送ることや、実際に侵入するという方法が使われます。

しかし、これだけでも障壁のとなる場合があります。もし相手のネットワークに

Firewall が存在しており、たとえば外部とは DNS,SMTP,HTTP のみしかアクセスを許可

していないネットワークの場合は少々やっかいです。 この場合には、自動的にデータ

をメールに添付し送信させるという方法がとられることもあります。

このように、盗聴は も確実に、しかも 短で情報を入手する手法なのです。

1.5.3 盗聴を防ぐには

盗聴を防ぐには、いくつかの方法があります。

これまでに説明した内容から察することができるでしょう。大きくわけて 3 つの方法

から考えて行くことが必要です。

• インフラ • アプリケーション • 監視

インフラ面においては、スイッチングハブを導入し、ポートの管理も行うということが

必要です。このことに関しては、通信機器のセキュリティで解説します。

次に、アプリケーション面においては、たとえば平文の使用を禁止し、暗号化が行

われるようにするということです。telnet から ssh へ、POP から APOP へ、 そして重要

なメールは PGP で暗号化するといった方法が必要でしょう。

後に、監視を行うということは、何かを防ぐことに繋がるわけではありません。 も

し盗聴されるような事実があれば、少しでも早く対処する必要があります。 何かが起

こったとき、大惨事になる前に対処できるよう日頃の監視が重要になります。

監視するものはログや通信先などだけではありません。 サーバで動作するプロセ

スや、ネットワークインターフェースに異常がないかを監視する必要があるのです。

たとえば、ifconfig コマンドでネットワークインターフェースを調べると次のように表示

されます。

% ifconfig de0 de0: flags=8843<UP,BROADCAST,RUNNING,PROMISC,MULTICAST> mtu 1500 inet 172.16.0.1 netmask 0xffffff00 broadcast 172.16.0.0 inet6 fe80::242:3ff:fda2:d14%de0 prefixlen 64 scopeid 0x1 ether 00:44:08:44:0d:14 media: autoselect (10baseT/UTP) status: active supported media: autoselect 100baseTX <full-duplex> 100baseTX 10baseT/UTP <full-duplex> 10baseT/UTP このときに注目すべき点は、"PROMISC"の部分です。 インストール直後など、多くの場合は"SIMPLEX"になっています。 この部分が、"PROMISC"になっていると、ネットワークインターフェースがプロミスキャスモードになっているので何故そうなったかという

ことを調べる必要があります。

1.6 DoS 攻撃

DoS とは"Denial Of Service"のことで提供するサービスの妨害や停止させるものを

指します。サービスを妨害する攻撃は以下の 2 種類に分けることができます。

• 過負荷をかけるもの • 例外処理ができないもの

1.6.1 DoS 攻撃の種類

DoS 攻撃は、特定の手法を指すものではありません。 言葉の通りサービスの妨害

や停止を行う攻撃全般を指す総称です。

それでは、どのような攻撃があるのでしょうか。

表 1.6.1-1 DoSの種類

種類 概要

mail bomb 巨大なメールや大量のメールを送りつけメールサーバのディスク

や CPU資源、 ネットワークの帯域を潰す

finger fingreコマンドで引数の状態によって相手を停止させる。

SYN flood プロトコルスタックを使用した攻撃の原型。 接続要求(SYN)の処理における仕様を突いたものです。 防御としては SYN cookiesというものがあります。

Ping of Death TCP/IP プロトコルスタックの実装のバグに対する攻撃。

ping flood pingコマンドで引数の状態によって相手を停止させる。

OOB ポート 139に対し Out of Bandデータを送り相手を停止させる。

Land/Latierra SYNパケットを送信し相手側を無限ループに陥らせる。

TearDrop/Bonk/Boink フラグメントパケット処理の実装によって相手を停止させる。

Octopus 相手に対し多くのコネクションをターゲットサーバに張り運用が

できないようにするもの。

SSPING/Jolt ICMPパケットの仕様を利用したもの。

UDP Storm echoサービスの問題点を利用したもの。

DoS 攻撃の多くは OS やアプリケーションのバグによるものです。よって、OS やアプ

リケーションに対してパッチの適用やバージョンアップなどによって、ほとんどの攻撃

は回避できるようになります。しかし、回避することが難しい攻撃や、新しい手法の登

場によって、 管理者は常に現在どのような攻撃が行われているのかという状態を把

握しておく必要があります。

画面 1.6.1-1 DoS

1.6.2 DDoS

DoS 攻撃は単体では行われなくなってきました。 DoS に代わって行われ、強力な

威力を持っている手法が DDoS です。これは、"Distributed Denial Of Service"の略で、

DoS 攻撃を行うホストがネットワーク上に分散しているものです。そして、DDoS は防

御を難しい手法の一つです。

DoS 攻撃の場合は、攻撃側と相手側の 1 対 1 で行われます。 しかし、DDoS は攻

撃側が複数存在し、1 台のサーバを攻撃します。たとえば、1,000 台が 1 台のサーバを

攻撃するのです。 DDoS の防御が難しい点は、この 1,000 台がどこにあるのか見当

がつかない点なのです。 そして、真の攻撃者を特定することは非常に難しいこととな

ります。

DDoS は、踏み台となるホストが必要となります。 そのため、まずインターネット上

にあるサーバに侵入し、DDoS のモジュールを埋め込みます。

画面 1.6.3-1 DDoSの攻撃方法(1) 準備段階

特に、インターネット上でサービスを提供するサーバは、時刻の同期が行われてい

ることが多いため、DDoS のモジュールに対し、何日の何時何分にどのホストを攻撃

するのか設定を行っておきます。 これによって設定した日時に指定されたホストを一

斉に攻撃することができます。

画面 1.6.3-2 DDoSの攻撃方法(2) 攻撃段階

DDoS の攻撃を受けた側は、1,000 台、10,000 台といった多くのホストから一斉に攻

撃を受けるため、サービスやネットワークが停止することとなります。やっかいなこと

はこれだけではありません。 DDoS 攻撃の原因と攻撃したホストを特定しようとしても、

攻撃側が自ら行っているわけではなく、第三者のホストが行っているため、 特定が非

常に難しくなります。 さらに、踏み台となったホストの管理者も DDoS のモジュールが

埋め込まれ踏み台にされていることを気づかない場合もあることから攻撃側を特定し

づらくなっています。

1.7 リモートアクセス

多くのサイトでは、社員や職員に対しリモートアクセスの接続を提供しています。

たとえば、出先から普段自分が使用しているサーバの資源を利用するためには、

外部から単純に接続するだけではセキュリティ上許可していない場合がほとんどで

す。

このとき、社員や職員に対してのみ利用できる回線を用意し、 モデムや TA など通

信機器を接続しリモートアクセスサービスを提供するのです。これによって、Firewall

のセキュリティレベルを落とさずに社員や職員に対してLAN上の資源を職場に居る時

と同じように利用できるようにすることができます。

しかし、ここに大きな落とし穴があります。 ここでは、限られたユーザに対してリモ

ートアクセスサービスを提供する場合の問題点を解説します。

1.7.1 ウォーダイヤリング

ウォーダイヤリングと呼ばれる手法があります。

これは、予め予測している範囲の電話番号を使用し順番に電話をかけます。 音声

が聞こえれば通常の電話ですが、場合によってはモデムや FAX が反応することがあ

ります。モデムと FAX の違いはその通信方法を調べることによって判別することがで

きます。

ここまで解説すると何が問題であるか予想できるかもしれません。

表(Firewall)のセキュリティを落とさず、 意図しない裏口(リモートアクセス)を作成し

てしまうのです。 住宅で言えば玄関に厳重に幾つ施錠しておいても勝手口が無施錠

である状態です。

リモートアクセスの電話番号は、 通常そのサイトの電話番号に近い加入者番号を使

用しています。 状況によっては加入者番号が異なることもありますが、電話回線を敷

設する際、 利便性を考え音声通話の代表電話番号の次の番号を FAX の番号とする

ことがあります。 同時にリモートアクセス用の回線を敷設した場合などはこの付近の

番号を使用していることが多いのです。

図 1.7.1-1 Firewallで表を閉じても裏口が無防備であれば意味がない

攻撃する側は、どのように調べるのでしょうか。

ここで使用するものが、ウォーダイヤリングを行うソフトウェアです。 ダイヤリングを

自動で行うことにより、 寝ている間でも発信しモデムが接続されている電話番号を探

します。対象となるサイトの代表電話番号やいくつかの直通電話番号を調べ、 その

近くの範囲をウォーダイヤリングによってしらみつぶしに探すのです。

画面 1.7.1-1 ウォーダイヤリング

このことから、リモートアクセスの電話番号は、 代表番号等公開している電話番号

の近くに設定しない注意が必要です。

また、フリーダイヤルで社員や職員にリモートアクセス環境を提供している組織もあ

ります。 これはウォーダイヤリングにおいて電話代を浮かせることにも繋がります。

1.7.2 コールバック

ウォーダイヤリングによって運悪く見つけられてしまった場合や、 フリーダイヤルを

用いず正規のユーザには電話代を負担させたくない場合、 これらのためにはどうす

れば良いのでしょうか。

一つの解決策として、リモートアクセスの設定をコールバックにする方法があります。

コールバックかつ予め登録してある電話番号のみにしかコールバックしないという設

定であれば、万一リモートアクセスの電話回線を発見されてもなかなか侵入すること

ができません。

リモートアクセスの回線は、 必ずコールバックの設定と運用を行うようにしてくださ

い。

もし、コールバックを行うと交換台を経由してしまう等の理由でコールバックが使用

出来ない場合は、たとえば CTI などで使用されているハードウェアを導入する方法も

考えられます。CTI のアダプタやソフトウェアには、特定の番号以外を着信拒否とする

設定が可能なものがあります。これらを使用し、事前に登録しておいた電話番号にの

み着信を許可するという方法をとることができます。

1.8 リモートコントロール

遠隔地からサーバの操作を行うリモートコントロールのソフトウェアがあります。

主に Windows で使用される場合が多いでしょう。 なぜなら、UNIX システムであれ

ば、X Window System をインストールしないまたは停止させコマンドラインからほぼ全

ての操作を行うことができます。 しかし、Windows では、コマンドラインで操作できるも

のは OS の持つ機能だけに留まる場合がほとんどです。

言い換えるならば、Windows ではサーバのコンソールを操作することによって、ほと

んど全てのことが行えるということになります。つまり、リモートコントロールのソフトウ

ェアを悪用すると、攻撃の手法として利用可能となるのです。

画面 1.8-1 リモートコントロール

1.8.1 リモートコントロールのソフトウェア

リモートコントロールのソフトウェアからは、 一般に市販されている製品を連想しま

す。 このセッションを乗っ取るという方法が第一に考えられます。

もちろん、この方法もリモートコントロールによる攻撃手法の一つです。

それでは、リモートコントロールのソフトウェアをインストールしないという対策だけ

を考えてしまいがちです。しかし、リモートコントロールのソフトウェアにはバックドアや

トロイの木馬に含まれるものもあります。つまり、単純に操作が行えるということだけ

でなく、 気づかない間にリモートコントロールのソフトウェアをインストールしてしまっ

ている場合があるのです。

これらのソフトウェアは、 Windows のタスクマネージャなどではプロセスが表示され

ない場合があり、 場合によってはプロセス名を変更する等が行われるため、 プロセ

ス名による判別は困難です。リモートコントロールのソフトウェアがインストールされる

と、 主に次のような操作を行うことができます。

• システム情報の表示 • キーボード操作の記録 • フォルダ共有 • プロセスの制御 • レジストリの表示と編集 • ファイルやディレクトリの操作 • ファイルの送受信 • サーバのシャットダウンや再起動

この他にもリモートコントロールのためのソフトウェアによって様々な機能が実装さ

れています。さらには、リモートコントロールを行うときに通信経路を暗号化しネットワ

ークを監視しても判らないようにするものもあります。 おそらく、ほとんど全ての操作

が行えるであろうソフトウェアも存在します。

1.8.2 リモートコントロールを行わせないために

これらの多くは、サーバモジュールとクライアントモジュールに分かれています。 こ

れらは、対象となるサーバに対して常駐させる必要がありますが、 どのように行うの

でしょうか。

これは、「バックドアやトロイの木馬に含まれる」とした点から考えると判りやすいで

しょう。メールの添付や Web からのダウンロードなどによって、対象となるサーバに送

り込みます。もちろん、直接侵入する方法もあります。

攻撃側は、あるゆる手段を使用して対象となるサーバにモジュールを潜り込ませ、

リモートコントロールを行うように仕掛けるのです。

リモートコントロールのモジュールを探すのは非常に難しい作業になります。

市販のウィルス検査プログラムには、これらのモジュールをウィルスの一つとして

考え、既知のモジュールに関しては警告を出します。

リモートコントロールのモジュールを入れられないようにするためには、 ウィルス検

査プログラムを導入する等が必要です。

1.9 バックドア

バックドアとは、root や Administrator 等の管理権限を奪ったサーバに対して、 再

度侵入や攻撃を仕掛けるときに行いやすくするためのものです。侵入や攻撃を行う側

の立場からは、手間をかけてアカウント情報を入手し侵入したサーバに対して同じか

またはこれまで以上の手間をかけたくはないはずです。 一度侵入した後は、次回か

らも侵入しやすいようにバックドアを仕掛けるのです。

言い換えるならば、一度でも侵入や攻撃を受けた場合は、バックドアを仕掛けられ

ている可能性が高いため、OS の再インストールやユーザアカウントの初期化、アプリ

ケーションの再インストールなどが必要になってきます。

1.9.1 バックドアの例

バックドアには多くの種類があります。

簡単なものには.rhosts ファイルを利用したものがあります。これは IP Spoofing の

項で解説したように、r 系コマンドで使用されるファイルです。そして、r 系コマンドは、

相手の IP アドレスが認証されると以降の認証が行われないというインターネット上

においては致命的な問題を持っています。つまり、この.rhosts ファイルもバックドア

の一つとなる可能性があるのです。

攻撃側は、パスワード解析などを使用して管理者のパスワードを取得し侵入しま

す。ここまでは、パスワード解析と侵入という組み合わせですが、この後も侵入を繰

り返す場合、その行為を楽にしたいため.rhosts に記述するわけです。これだけでな

く、更にバックドアのプログラムを送り込んで特定のポート経由で侵入するようなこ

ともあります。 特に、"."で始まるファイル名は、UNIX システムにおいては隠ファイ

ルとして扱われるため、バックドアのプログラム自体を"."で始まるファイル名に変更

しておく場合が多いようです。これを/usr/bin/等に配置するのです。置かれたバッ

クドアのプログラムは setuid ビットを立てておくと root 権限で動作するようになるた

め、次回から rlogin を行い、そのプログラムを実行するだけで root 権限を取得でき

てしまうことになります。

このようにバックドアは、これまで解説してきた手法の組み合わせにすぎません。

つまり、これまで解説してきた手法を防げなければ、バックドアを仕込まれる可能性

があるということです。

1.10 トロイの木馬

トロイの木馬は、色々な動作を行います。 共通していることは、通常のプログラム

を装う悪意を持ったプログラムであるということです。

たとえば、パスワード検査のプログラムにトロイの木馬を仕込んだ場合を考えてみ

ます。

UNIX システムの管理者が定期的にユーザのパスワードを検査し解析されやすい

パスワードを使用しているユーザが居ないかをチェックします。

ここまでは良性のプログラムですが、このプログラムが解析したパスワードに通知

する機能を持っていたと考えるとどうでしょうか？また、バックドアやリモートコントロー

ルの項にも関係があります。

トロイの木馬は、バックドアやリモートコントロールモジュールとして機能するものも

あります。 たとえば、UNIX の su コマンドと置き換え、たとえば/tmp/.backdoor ファイ

ルに対して情報を書き込むものもあります。

図 1.10-1 トロイの木馬で使用される手法の一つ

やっかいなことは、su コマンドと置き換えられたものは、su コマンドとして動作する

ため、発見が遅れてしまうということにあります。

この他にも、コマンドと置き換えられたトロイの木馬の多くは正しいコマンドとして動

作します。

また、セキュリティ検査のために動作させたプログラムも正しい結果を出力します。

ユーザのパスワードの中で類推されやすいものはないか検査し管理者に報告します。

しかし、その裏ではユーザ情報をはじめとする各種情報が格納され、攻撃者に提供さ

れているのです。

特に、ネットワークを使用したトロイの木馬はリアルタイム、 または一定時刻に攻

撃者の元へデータが届けられサイトは脅威に晒されます。 使用される代表的なポー

トは次の通りです。

もし、このポートが頻繁に使用されるようであれば、システム上に問題はないか、そ

の日時に動かしたプログラムは何か等を検査する必要があります。

表 1.10-1 トロイの木馬でよく使用されるポート

ポート番号 IANAで指定されている本来のサ

ービス トロイの木馬

21 FTP(データ) WinCrash, Back Construction

23 telnet TTS

25 SMTP Ajan, Email Password Sender Happy99

31 msg-auth Agent31, Masters Paradise

41 graphics Deep Throat

59 DMSetup

80 HTTP Eecuter

99 metagram Hidden Port

113 ident Kiazimas

119 NNTP Happy99

121 ERPC BO jammerkillah

456 macon-udp Hackers Paradise

531 conference Rasmin

555 dsf Phase Zero, Stealth Spy

666 mdps, doom Back Construction, Attack FTP

911 xact-backup Dark Shadow

999 garcon, applix Deep Throat

1001 Silencer, WebEx

1010 Doly

1011 Doly

1012 Doly

1015 Doly

1024 NetSpy

1033 NetSpy

1042 Bla

1047 neod1 CateCrasher

1090 ff-fms Xtreme

1170 Streaming Audio Torojan, Psyber Stream Server

1234 search-agent Ultors

1243 serialgateway BackDoor-G, SubSeven

1245 isbconference2 VooDoo Doll

1269 watilapp Maverick's Matrix

1492 stone-design-1 BackOrifice FTP, FTP99

1509 robcad-lm Psyber Streaming Server

1600 issd Shvka Burka

1807 fhsp SpySender

1981 p2pq ShockRave

1999 tcp-id-port Trojan Scout

2000 callbook Trojan Scout

2001 dc Trojan Cow

2002 globe Trojan Scout

2003 Trojan Scout

2004 mailbox Trojan Scout

2005 berknet Trojan Scout

2023 xinuexpansion3 Pass Ripper

2115 KDM Bugs

2140 IAS-REG Deep Throat

2155 Illusion Mailer

2283 lnvstatus HVL Rat5

2565 MosaixCC Striker

2583 Wincrash

2801 igcp Phineas Phucke

2989 UDP ZARKOV RAT

3129 Master Paradise

3150 nm-asses-admin Deep Throat

3459 integral Eclips2000

3801 UDP Eclips

4321 rwhois BoBo

4567 tram FileNail

4950 ICQ Trojan

5000 commplex-main Bubbel, Blazer

5001 commplex-link BackDoor Server

5011 telelpathattack OOTLT

5031 NetMetro

5321 Filehotcker

5400 Blade Runner, Back Construction

5401 excerpts Blade Runner, Back Construction

5402 mftp Blade Runner, Back Construction

5512 Illusion Mailer

5550 Xtcp

5555 personal-agent ServeMe

5556 udpplus BO Facil

5557 BO Facil

5569 RoboHack

5714 prosharevideo Wincrash3

5742 ida-discover2 Wincrash

6400 info-aps The Thing

6669 ircu Vampire

6670 vocaltec-gold Deep Throat

6671 Deep Throat

6767 bmc-perf-agent NT Remote Control

6776 SubSeven, BackDoor-G

6883 DeltaSource

6912 Shit Heep

6939 Indoctrination

6969 acmsoda GateCrasher

6970 GateCrasher

7000 afs3-fileserver Remote Grab

7300 swx NetMonitor

7301 swx NetMonitor

7306 swx NetMonitor

7306 swx NetMonitor

7307 swx NetMonitor

7308 swx NetMonitor

7789 ICQ Killer

8080 http-alt RingZero

9400 InCommand

9872 Portal Of Doom

9873 Portal Of Doom

9874 Portal Of Doom

9875 Portal Of Doom

9876 sd Cyber Attacker

9878 TransScout

9989 iNi-Killer

10067 UDP

Portal Of Doom

10101 BrainSpy

10167 UDP

Portal Of Doom

11000 irisa Senna Spy Trojan

11223 Progenic Trojan

12076 Gjamer

12223 Hack99 KeyLogger

12345 NetBus

12346 NetBus

12631 WhackJob

13000 SennaSpy

16969 Priority

17300 Kuang2

20000 dnp Millenium2

20001 Millenium2

20034 NetBus2

20203 Loged

20331 Bla

21554 GirlFriend

22222 Schwindler

23476 Donald Dick

23477 Donald Dick

23456 Whack Job, Evil FTP

26274 (UDP)

Delta Source

29891 The Unexplained

29891 (UDP)

The Unexplained

30029 AOL Trojan

30101 NetSphere

30102 NetSphere

30100 NetSphere

30303 Socket23

30999 Kuang2

31336 BO Whack

31337 (UDP)

BackOrifice

31338 (UDP)

BackOrifice

31339 NetSpy

31666 Whackmole

31789 (UDP)

Hack a tack

31791 (UDP)

Hack a tack

32771 Solaris rcpbind vulnerability

33333 Prosiak

33911 Trojan Spirit

34324 TN

34324 Tiny Telnet Server

40412 The Spy

40421 Master Paradise

40423 Master Paradise

47262 (UDP)

Delta Source

50766 Fore

53001 Remote Shutdown

54321 (UDP)

Back Orifice 2000

ここまでは主に UNIX システムにおける手法でした。 Windows では、固有の実装を

利用したトロイの木馬があります。

たとえば、ActiveX コントロールを使用したものです。

これは、ActiveX コントロールをダウンロードさせ、特定のポートを通じて相手のホ

ストを操作するといったことや、リモートコントロールのモジュールを送り込むという手

法です。

ActiveXのモジュールを相手にダウンロードさせる

相手のホストに入り操作を行う

画面 1.10-1 Windowsにおけるトロイの木馬例

トロイの木馬は、ウィルスとしてもにも使用されています。

W32/Ska(Happy99) がその一つと言えるでしょう。 ウィルスの情報はウィルス対策

室のページを参照願います。

また、リモートコントロールのモジュールとして機能する場合もあります。

リモートコントロールの機能以外にも、システムの情報を取得することや、 コンソー

ルで使用されたキーボード操作をロギングするということも行われます。

リモートコントロール機能のに関してはリモートコントロールのページを参照してくだ

さい。

画面 1.10-2 リモートコントロールも兼ねたトロイの木馬

1.11 WebPage 改竄

Web Page の改竄は、本来提供していたページが第三者による改竄や、 全く別の

ページと入れ替わることを指します。

改竄の手法は大きく分けて 3 つあります。

• 直接の侵入による改竄 • DNSのエントリを書換ることによる改竄 • whoisエントリを書換ることによる改竄

1.11.1 直接の侵入による改竄

直接侵入する場合、必要なものはページを書換ることのできるアカウントです。

このアカウントは、ページの更新が可能なアカウントや root や Administrator といっ

た管理者のアカウントです。

書換ることのできるアカウントで特に注意しなければならないものは、 ISP から

Web の領域を借りている場合です。

通常の運用では、テストを行ったページを更新するために FTP を使用しデータを

PUT します。このときに、ユーザ名やパスワードを盗聴を受けてしまうことや、パスワ

ードを解析されることによって攻撃側にアカウント情報が渡ってしまいます。

特に、ユーザ名が判っており、類推しやすいパスワードを設定している場合は、辞

書攻撃によってアカウント情報を知られてしまうことや、パスワードの更新間隔が長い

ためにブルートフォースアタックによって知られてしまうことがあります。

画面 1.11.1-1 Webサイトのセキュリティ確認ツールの一つ

アカウント情報が知られてしまうと、 攻撃側にとってはアカウント情報が変更される

までは何度でも対象となるページを書換ることができます。

書換たページの内容は、主に成人向けの内容や、政治的な内容、 特定の企業や

個人を誹謗中傷する内容が中心となるため、 書換られたサイトにとって信用を失うも

のばかりとなります。

図 1.11.1-1 直接侵入し改竄する方法

直接侵入され改竄されることを防ぐには、他項に記述している脅威を守ることから

始めなければならないのです。

1.11.2 DNS のエントリの書換

DNS のエントリを書換る手法もあります。

本物のページには触らず、DNS のエントリを変更する方法です。 これによって、全

く異なる攻撃者が用意した Web サーバを指し示すように書き換えることによって改竄

されたかのように見えるようにするものです。

DNS では www.ipa-sec.com の IP アドレスが 192.168.0.1 であった場合、 この IP ア

ドレスを172.16.0.1に書き換えてしまうことによって別のサーバを参照することになりま

す。この 172.16.0.1 に用意しておいた改竄されたページを置くことによって、 本来サー

ビスを提供している筈の 192.168.0.1 を攻撃者が管理するサーバに置き換えることが

できるのです。

図 1.11.2-1 DNSにより改竄に見せかける方法

このような攻撃を受ける場合は、主に Web サーバのセキュリティを高めているもの

の、 DNS サーバのセキュリティ確保を行っていないという環境に多く発生しているよ

うです。

このような攻撃を防ぐには、DNS のセキュリティホールを塞ぐことや、ゾーン転送を

禁止する設定を行うことが必要です。

また、DNS は、メールシステムや Web 環境と並んで多くのセキュリティホールが報

告されているため、日頃から情報収集を行うことと、システムの状態を把握することが

重要です。

1.11.3 whois エントリの書換

難しいはずだが、意外に多発しているものが whois エントリの書換によるものです。

攻撃対象のドメインを管理している組織に対し、 対象となるドメインの管理者を装

い DNS 書換の申請を行います。

また、このドメインを管理している組織は、 他企業と提携し登録や管理の業務を行

っている場合もあり、 直接管理組織そのものに対して管理者を装わずに、 提携先

の中で も簡単に偽装できるところに対して管理者を装うのです。

この場合、簡単な認証が行われますが、 たとえばメールの From:アドレスのみで認

証する場合は非常に危険です。また、これは自サイトの努力で防ぐことのできるもの

ではありません。 できるかぎりセキュアな環境でドメイン情報を処理される方式に変

更するか、 管理組織自体を変更する必要があります。

1.12 スクリプト

Web サイトにおいて、現在ではコンポーネントペースのページなどが主流になりつ

つありますが、それでも CGI(Common Gateway Interface)や SSI(Server Side Includes)

を使用したページも多く存在します。

これは、単純な処理かつ負荷の低い(極端に利用度が上がらない)ページなどで利

用されています。また、Windows では IIS 上で稼動する ASP(Active Server Pages)が中

心となっています。

1.12.1 スクリプトの危険性

Web におけるスクリプトは、CGI や SSI を利用するときに危険性が発生します。

CGI スクリプトを作成した際、特に悪意を持って作成していなくとも、 単純なミスに

より致命的な問題が発生する場合があります。まず、次の簡単なコードを見てくださ

い。

system('grep $arg /data/data-txt');

これは問題を判りやすくするために簡単なものにしています。

FORM を使用したページから引き渡された CGI スクリプトがコマンドを実行し、 その

結果を返すというものです。このコードの問題は、次の引数を渡された場合にありま

す。

; cat /etc/passwd ;

これは、$arg に対して; cat /etc/passwd ;が引き渡されることになります。 つまり、

CGI スクリプトでは次の行が実行されることになります。

system('grep ; cat /etc/passwd ; /data/data-txt');

もちろん、grep コマンドや/data/data.txt の部分は";"で区切られているためエラー

になりますが、cat /etc/passwd の部分は動作します。

httpd はデフォルトでは nobody などのユーザ権限で動かす場合が多いようです。し

かし、httpd は ftpd の Anonymous FTP のように chroot()を行いません。 これが意味

するものは、ユーザが読めるファイルはCGI経由で読めるということです。 このため、

例のようにパスワードファイルやユーザのファイルが Web 経由で閲覧できるのです。

上の例のように、悪意を持って書いたものではないスクリプトであっても思わぬとこ

ろでセキュリティホールとなる可能性があるのです。

同じような危険性が SSI にもあります。 exec は特に危険なため必要でなければは

禁止しておく必要があります。 近の Apache httpd 等はデフォルトで禁止となってい

ます。

<!--#exec cmd="コマンド"-->

1.12.2 メタキャラクタ

UNIX シェルにはメタキャラクタと呼ばれるものがあります。

コマンドのパイプを行う"|"やリダイレクトを行う">"などです。

CGI スクリプトにおいて、 低限行わなければならないことは、これらメタキャラクタ

を排除するということです。必ず排除すべきメタキャラクタは次の 4 つです。

;

|

&

\

1.12.3 権限

CGI スクリプトを動作させるとき、 大の問題は権限の付与です。

たとえば、何らかの処理を行うときロック機構を使用しますが、 このときに作成す

るロックファイル名を、たとえば会員番号のような FORM の特定のフィールドに入力さ

れたデータを使用している場合、本来入力するデータではなく/etc/passwd のような

特定のファイル名を入力した場合を考えてください。

当然、処理は失敗しますが、処理終了時にロックファイルを削除します。 しかし、こ

のロックファイル名が/etc/passwd であればこのファイルを削除することになるので

す。

この問題は、httpd が chroot()を行わないということに加えてスクリプトを実行させる

権限を悪用したものです。

Windows と IIS において使用される ASP でも CGI 同様の問題が発生する可能性が

あります。

たとえば、Site Server 3.0 をインストールする際、 デフォルトのインストールでは

showcode.asp，viecode.asp，codebrws.asp に対して適切なアクセス権が設定されず

にインストールされます。

これらのスクリプトを利用することによって、 システム上のファイルにアクセス出来

てしまいます。

これは非常に危険なことである言えます。なぜなら、ファイルとその内容を見ることが

できるだけでなく、 ディレクトリの移動も可能になれぱ、 さらに多くの情報を収集する

ことができるからです。

1.13 spam

spam という言葉がよく使われます。

spam とは、本人が望まないダイレクトメールを大量に送りつけることを指します。

spam の語源は食品の名前で Hormel Foods Corporation 社が「スパム (SPAM)」 を

商標として登録しています。

ネットワーク上における spam とは、 一方的に送り付けられてくる受信者の希望し

ない内容の不要なメール、 または NetNews で無差別にクロスポスト、 マルチポスト

されているジャンク記事といったものが挙げられます。 なお 近では電子メールでの

spam は Unsolicited Bulk Email (UBE), Unsolicited Commercial Email (UCE)などと表記

することが多くなってきました。

spam メールには、以下のような種類があります。

• インターネットビジネスなどの商売の勧誘メール • 通信販売などのダイレクトメール • マルチ商法やネズミ講まがいのメール • アダルトサイトの宣伝

1.13.1 spam による問題

これらの spam メールは、大量に送信されるため、いろいろな問題が発生します。

電子メールによる spam にはダイレクトメール(DM) 業者と同様に多くのメールアド

レスを集める必要があります。 一般的にはNetNewsの投稿記事、Webの各種ページ、

メーリングリストなどからメールアドレスを収集します。 ネットワークにおける DM は郵

便とは異なり、 通信回線と PC 通信環境があれば誰でも非常に低いコストで行えるた

め、 日を追うごとに増えつつあります。

もちろん、受信者が配信を希望する場合は除外されますが、 郵便や FAX 同様希

望しないにもかかわらず配送されてくるものを今回は取り上げます。 では、郵便によ

る DM と違い spam と呼ばれるネットワーク上の DM はどういう問題があるのでしょう

か。

(1) メールの受信

受信時に問題となるものは、たとえば、読むために無駄な時間を費やしたり、 メー

ルを取り込むための時間や接続料金が無駄になるといったものがあります。

これらは年齢や職業といった分類が行われていることが少ないため、 受信者にと

って意味の無いメールとなる場合がほとんどです。 また、アダルトサイトの宣伝とい

ったものに関しては、 不快感といったものも加わります。

(2) サーバに対する問題

spam により配送するメールの数は数万、数十万通にも及ぶため、 回線やサーバ

の資源を大きく食い潰します。 これにより、そのサーバやネットワークにおけるユー

ザには、 サーバやネットワークが重くなるように感じるるようになります。 場合によっ

ては、帯域が飽和する場合や、 メールサーバのスプール容量不足からくるシステム

ダウンなどを招くこともありえるのです。

さらに、ISP のユーザが spam を打った場合、 ISP 外から ISP に対して苦情の連絡

があり、 対応するためには多くの時間が費やされます。これも、spam の発信元がヘ

ッダなどを偽造し、 ISP のユーザを偽った場合には事態はさらに複雑になります。 し

かし、このような悪質な行為は spam においては非常に多く存在します。 また、ヘッダ

の From:を偽るだけでなく、envelope の MAIL FROM:が自ドメインのものを騙られたり

する場合もあり、 このときは中継を行わなくとも大量のエラーメールが届くこととなり

ます。 そして、今回とりあげる Third-Party Mail Relay により、 別の組織から発信さ

れた spam を中継してしまうと、 自組織から発信された spam でないにもかかわらずこ

れらの問題が発生してしまうのです。

(3) Third-Party Mail Relay問題

サーバに対する問題で挙げたように、 spam を打つ場合はサーバに対して大きな

問題を抱えることとなります。 このような問題を spam を打つ組織自身が抱えれば問

題の程度も少なくなりますが、 現在の spam は、主に他組織のメールサーバを踏み

台にして発信されています。

これが Third-Party Mail Relay 問題です。

spam を打つ側にとって踏み台を使用する手法がなぜ有効なのでしょうか。

一通のメールの To:や envelope の RCPT To: に多くのメールアドレスを列挙するこ

とができるため、 spam を打つ側とメールサーバの間では送信するメールは一通のみ

であり、 後はメールサーバが To:や RCPT To:に記述したメールアドレスにメールを配

送するためです。 そして、このときに使用するサーバやネットワークの資源は、 自組

織でなく踏み台にする他組織が全て受け持つこととなるため、 自組織の受けるダメ

ージは非常に少なくなるのです。

では、踏み台になった場合の問題を挙げてみましょう。

• サーバやネットワークの資源を食い潰される。 • MTAが多くのコネクションを張るため、 設定されているコネクションの上限数に達すると spam以外の仕事のメール等が受け付けられなくなる。

• 踏み台にされた場合、組織外からサーバの管理能力を問われる。 • 以降、その組織からのメールは一切受けないといったことが発生し、 業務上不具合が発生する。

CERT* Summary CS-97.06 の 4. Relaying of Spam Email through Victim Sites でも

踏台対策をとることを勧告しています。

現在では、spam 対策は必ず行っておくべきものであり、 中継を許可している設定

になっていると、 たとえ spam の被害に遭わなくとも対策がとられていないこと自体が

問題だと言えるでしょう。

1.13.2 Third-Party Mail Relay を行わせないために

現在、メールサーバに必要とされる spam 対策は以下の 2 点です。

• spamの踏み台とならない。 • spamを受け取らない。

このために、メールサーバに対していくつかの設定を行う必要があります。

第 2 章 OS の設定方法

サイトの構築を行うためには、特殊機器を除き必ず何らかの OS を使用するはずで

す。 ここでは、主要な OS をとりあげ、具体的な設定方法を解説します。

とりあげる OS は、FreeBSD, RedHat Linux, Windows 2000 の 3 種類です。

ここで解説する内容は、セキュリティ面に対してのものであり、 OS 自体に対する解説は行っていません。 RedHat Linux 7.0に関しては、インストール時にデフォルトであるワークステーションでインストールされる場合が多いようです。 サーバでインストールすることを推奨しますが、ここではワークステーションでインスト

ールを始めたときのセキュリティ対策について説明します。 サーバーやカスタムでセットアップした場合に対しても有効な内容であるため、 インストール形態によって読み替えてください。

2.1 FreeBSD 4.2-RELEASE

• 2.1.1 インストール時の設定 • 2.1.2 セキュリティパッチの適用 • 2.1.3 アカウントのセキュリティ設定 • 2.1.4 パスワードのセキュリティ設定 • 2.1.5 リモートからのアクセスの制限 • 2.1.6 リソースへのアクセス制限 • 2.1.7 ログの確認

2.2 RedHat Linux 7.0

• 2.2.1 インストール時の設定 • 2.2.2 セキュリティパッチの適用 • 2.2.3 アカウントのセキュリティ設定 • 2.2.4 パスワードのセキュリティ設定 • 2.2.5 リモートからのアクセスの制限 • 2.2.6 ローカルリソースへのアクセス制限 • 2.2.7 ログの確認

2.3 Windows 2000

• 2.3.1 インストール • 2.3.2 セキュリティパッチの適応 • 2.3.3 アカウントのセキュリティ設定 • 2.3.4 パスワードのセキュリティ設定 • 2.3.5 リモートからのアクセス制限 • 2.3.6 リソースへのアクセス制限 • 2.3.7 ログの確認

2.1 FreeBSD 4.2-RELEASE

ここでは、FreeBSD 4.2 のインストールにおける注意点を解説します。

FreeBSD のインストールにおいては、いくつかの段階があります。

• 2.1.1 インストール時の設定 • 2.1.2 セキュリティパッチの適用 • 2.1.3 アカウントのセキュリティ設定 • 2.1.4 パスワードのセキュリティ設定 • 2.1.5 リモートからのアクセスの制限 • 2.1.6 リソースへのアクセス制限 • 2.1.7 ログの確認

2.1.1 インストール時の設定

ここで取り上げる FreeBSD のインストールは Custom でインストールする場合としま

す。 Standard や Express であっても、 /stand/sysinstall を起動しで再設定することが

可能です。

(1) Distributionsの選択

Custom のメニューでは、Partition, Label, Distributions, Media, Commit の項目が並

んでいますが、これを順に実行することになります。 インストール方法の詳細は該当

する文書を参照願います。

Partition および Label メニューでパーティショニングやスライス、 マウントポイント等

を選択した後は、インストールする内容の選択になります。

これは、Distributions の設定で行います。

ここで選択できるものは次の 8 種類です。通常は、用途に合わせて選択しインスト

ールを行う部分です。

ここで注意しなければならない点は、X が必要であるかどうかです。

インターネットのサーバとしてサービスを提供する場合、 多くの場合は不要なはず

です。 また、X のセッションからキーストロークを盗聴されるという危険性もあります。

これらを考えると意味のあるインストールでない限りは入れるべきではありません。

通常は、User または Minimal を選択します。 選択した後、たとえばカーネルソースな

どが必要であれば、 Custom から追加選択するのみに留めます。

Distributions選択メニュー

Developer Full sources, binaries and doc but no games

X-Developer Same as above + X Window System

Kern-Developer Full binaries and doc, kernel sources only

X-Kern-Developer Same as above + X Window System

User Average user - binaries and doc only

X-User Same as above + X Window System

Minimal The smallest configuration possible

Custom Specify your own distribution set

(2) Configure設定

インストールが終了すると Configure のメニューに変わります。

ここで設定する項目は、Root Password, Networking, Security, Startup です。

Configurationメニュー

Distributions Install additional distribution sets

Packages Install pre-packaged software for FreeBSD

Root Password Set the system manager's password

Fdisk The disk Slice (PC-style partition) Editor

Label The disk Label editor

User Management Add user and group information

Console Customize system console behavior

Time Zone Set which time zone you're in

Media Change the installation media type

Mouse Configure your mouse

Networking Configure additional network services

Security Select default system security profile

Startup Configure system startup options

Options View/Set various installation options

XFree86 Configure XFree86 Server

Desktop Configure XFree86 Desktop

Root Password設定

root のパスワードを訊かれるため、適切なパスワードを設定してください。

インストール作業を終了させ再起動後から使用します。

Networking選択

サービスを提供するにあたり、必要なサービスを選択します。

ここで選択するサービスは、サーバの形態にもよって異なりますが、 たとえば、

Anonymous FTP サーバとしても機能させる場合は Anon FTP をチェックします。 ただ

し、インストール後に 新バージョンに入れ替えなければならないため、 結果的には

無意味な選択となります。

デフォルトで portmap が選択されていることがあります。 portmap を使用しない場

合は非選択状態に変更してください。また、インターネットを利用してサービスを提供

するサーバにおいては、 NFS 関連を選択しないようにしてください。

Network Services選択メニュー

Interfaces Configure additional network interfaces

AMD This machine wants to run the auto-mounter service

AMD Flags Set flags to AMD service (if enabled)

Anon FTP This machine wishes to allow anonymous FTP.

Gateway This machine will route packets between interfaces

inetd This machine wants to run the inet daemon

NFS client This machine will be an NFS client

NFS server This machine will be an NFS server

Ntpdate Select a clock-synchronization server

PCNFSD Run authentication server for clients with PC-NFS.

portmap This machine wants to run the portmapper daemon

Routed Select routing daemon (default: routed)

Rwhod This machine wants to run the rwho daemon

Sendmail This machine wants to run the sendmail daemon

Sshd This machine wants to run the ssh daemon

TCP Extensions Allow RFC1323 and RFC1644 TCP extensions?

Security選択

次にセキュリティ状態の選択です。

デフォルトでは Medium です。必要に応じて High または Extreme に設定します。 こ

れによって、自動的にセキュリティ設定が行われます。

たとえば、inetd を起動せず、ssh のみで運用する設定が行われたり、カーネルのセ

キュアレベルが上げられるということが行われます。

Highの場合 Extremeの場合

kern_securelevel="1" kern_securelevel_enable="YES"sendmail_enable="YES" sshd_enable="YES" portmap_enable="NO" nfs_server_enable="NO" inetd_enable="NO"

kern_securelevel="2" kern_securelevel_enable="YES" sendmail_enable="NO" sshd_enable="NO" portmap_enable="NO" nfs_server_enable="NO" inetd_enable="NO"

初は Medium でインストールを行い、 その後に High そして Extreme へ移行する

と良いでしょう。

もし、LAN 内のサーバであれば Low を選択することも可能ですが、 インターネット

を利用したサービスを提供するサーバにおいては、 必ず High または Extreme を選択

してください。 これによって以降の作業が大幅に簡略化されます。

Security選択メニュー

Low Fairly wide-open (little) security.

Medium Moderate security settings [DEFAULT].

High Fairly safe security settings.

Extreme Very restrictive security settings.

Startup選択

後にシステム起動時に稼動させるサービス等を選択します。

startup dirs と named に関する 2 つを選択します。

/usr/local/etc/rc.d などにシェルスクリプトを配置し何らかのサービスを起動させる

ことがなければ startup も選択する必要はありません。

また、named を稼動させない(他に DNS サーバが存在する)場合は、選択する必要

はありません。 使用しないサービスを稼動させることは、資源の無駄遣いとなるだけ

でなく、 バージョンアップなどのメンテナンスを怠ってしまったがためにセキュリティホ

ールを突かれるといったトラブルを避けるためにも必要です。

特に、インターネットを利用したサービスを提供するサーバにおいて NIS 関連の項目

は非選択としてください。

Startup選択メニュー

APM Auto-power management services (typically laptops)

pccard Enable PCCARD (AKA PCMCIA) services (also laptops)

pccard mem Set PCCARD memory address (if enabled)

pccard ifconfig List of PCCARD ethernet devices to configure

startup dirs Set the list of dirs to look for startup scripts

named Run a local name server on this host

named flags Set default flags to named (if enabled)

nis client This host wishes to be an NIS client.

nis domainname Set NIS domainname (if enabled)

nis server This host wishes to be an NIS server.

accounting This host wishes to run process accounting.

lpd This host has a printer and wants to run lpd.

SVR4 This host wants to be able to run SVR4 binaries.

SCO This host wants to be able to run IBCS2 binaries.

quotas This host wishes to check quotas on startup.

(3) /etc/rc.conf

各種設定が終わると再起動しシステムが本格稼動を始めます。

これまで設定した内容は、/etc/rc.conf に反映されているはずです。 システム起動

時には、/etc/defaults/rc.conf が読み込まれますが、 /etc/rc.con に記述されている

内容と異なる場合は/etc/rc.conf が優先されます。ここまでで設定した内容は、たとえ

ば以下のようになっています。

IP アドレスやネットワークインターフェースなど赤で示した部分はシステムによって

異なりますので注意してください。

rc.confの例

network_interfaces="ep0 lo0" ifconfig_ep0="inet 192.168.0.2 netmask 255.255.255.0" defaultrouter="192.168.0.254" hostname="bsd.ipa-sec.com" sendmail_enable="YES" sshd_enable="YES" inetd_enable="YES" kern_securelevel="1" kern_securelevel_enable="YES" portmap_enable="NO" nfs_server_enable="NO" named_enable="YES" named_flags="-b /etc/namedb/named.conf"

もし、portmap を稼動させなければならない場合、 portmap_enable の部分を YES に

書き換えるか、 または/etc/defaults/rc.conf が YES になっている場合、

/etc/rc.conf の該当行を削除することによって稼動するようになります。

逆に/etc/defaults/rc.conf が NO になっている項目で /etc/rc.conf に記述していな

いものは、 /etc/defaults/rc.conf から該当行をコピーし/etc/rc.conf に追加します。

2.1.2 セキュリティパッチの適用

インストールしたシステムには、bind や sendmail なども含まれています。 ところが、

インストール時の各ソフトウェアのバージョンが必ずしも 新とは限りません。そこで、

まず初めにセキュリティパッチが施されたものに入れ替える必要があります。

FreeBSD 4.2-RELEASE におけるセキュリティパッチの適用には、 以下の 3 通りの

方法があります。

• packagesを使用したバイナリパッケージの適用 • portsやオリジナルソースから作成する方法 • システムのソースから作成する方法

セキュリティパッチは、FreeBSD-current と呼ばれる開発の 新ブランチに反映さ

れることになっています。 よって、ソースツリーを current に同期させ、 システムを作

成することによって 新の状態にすることができます。FreeBSD のセキュリティ情報は

以下の URL を参照してください。

http://www.jp.freebsd.org/www.FreeBSD.org/ja/security/

も手軽な方法が packages を使用した方法ですが、 これにはいくつかの問題が

あります。

まず、バイナリ配布であるため更新が遅いということです。

次に、必ずしも更新されるとは限らないこともあります。 これは、次のリリースに取

り込まれることで解決されますが、システムをそのまましておくと当然のことながらい

つまでもバージョンは変わりません。

FreeBSD で多く利用されている方法が ports と呼ばれるソフトウェアのパッチを集め

たものを使用する方法です。これは、更新も早く行われています。しかし、オリジナル

ソースのリリースを受けてパッチを作成するため、どうしてもタイムラグが発生します。

これが気になる場合は、オリジナルソースから作成することもできます。 ports の使

い方は、入門書などに必ず書かれている項目なので、ここでは割愛し、オリジナルソ

ースを使用した方法を紹介します。

また、利用の手軽さから、packages を使用した方法も紹介します。

(1) packagesを使用したバイナリパッケージの適用

パッケージによるインストールは、 pkg_add コマンドを使用します。 pkg_add コマンド

は、root 権限で実行する必要がありますので、 su 等で root ログインを行って下さい。

また、インストールしたパッケージの削除は pkg_delete、 パッケージの情報を参照

するには pkg_info コマンドを使用します。

現在のバージョン確認

新しいバージョンのパッケージをインストールするとき、 現在のバージョンを知る必

要があります。

たとえば、今回例に取り上げる BIND は、次のように調べることができます。

% /usr/bin/nslookup -type=txt -class=chaos version.bind ns.ipa-sec.com Server: pengo.tune.org Address: 172.16.0.1 Aliases: 0.0.16.172.in-addr.arpa VERSION.BIND text = "8.2.3-T6B"

この他にも、バージョン番号を表示するコマンドラインのオプションを持つものや、

strings コマンドで調べなければならならいものがあります。

これはソフトウェアによって異なるため、 それぞれのドキュメントを参照してくださ

い。

インストール済みのパッケージの確認

パッケージの情報は/var/db/pkg に格納されています。

これらの情報を見ることによって OS のインストール後に追加でインストールされた

パッケージのバージョンが判ります。 また、多くの場合それぞれのディレクトリ名の数

字がバージョンを表すため、 この数字から判断することができます。

ただし、ここでインストールされているものは、OS のインストール後に追加でインス

トールされたものであって、OS そのものに含まれているものではありません。

# ls -FA /var/db/pkg/ cvsup-bin-16.0/ ja-lynx-2.8.2.rel1/ ja-tcsh-6.08.05/ ja-elvis-1.8.4/ ja-man-1.1h/ png-1.0.5/ ja-grep-2.0/ ja-man-doc-3.4/ unzip-5.40/ ja-groff-0.99/ ja-nkf-1.62/ wide-dhcp-1.4.0p5/ ja-jvim-3.0.1.3j/ ja-qkc-1.0/ zip-2.2/ ja-less-332/ ja-sed-3.02/

このパッケージの情報を参照するには、pkg_info コマンドに対してパッケージ名を渡

します。

たとえば、漢字コードの変換を行う nkf は次のようになります。

# pkg_info ja-nkf-1.62 Information for ja-nkf-1.62: Comment: Network Kanji code conversion Filter Description: Nkf is a yet another kanji code converter among networks, hosts and terminals. It converts input kanji code to designated kanji code such as 7-bit JIS, MS-kanji (shifted-JIS) or EUC. One of the most unique facicility of nkf is the guess of the input kanji code. It currently recognizes 7-bit JIS, MS-kanji (shifted-JIS) and EUC. So users needn't the input kanji code specification. - Masafumi パッケージを使ったインストール

では、実際にパッケージをインストールしてみます。

今回は、bind-8.2.3 を使用します。

まず、パッケージを取得する必要がありますが、これは主要な FTP サイトの中でネ

ットワーク的に も近いところから取得します。http://www.jp.freebsd.org/mirror.html

もし、社内にミラーしているサーバがあれば、そこから取得します。

FTP サイトから bind-8.2.3.tgz を取得し、その内容を確認してみます。

今度はファイルを直接参照するため、末尾の.tgz を忘れずに付加してください。

# pkg_info bind-8.2.3.tgz Information for bind-8.2.3.tgz: Comment: The Berkeley Internet Name Daemon, an implementation of DNS

Description: The Berkeley Internet Name Daemon, an implementation of DNS. BIND 8 Features -> DNS Dynamic Updates (RFC 2136) -> DNS Change Notification (RFC 1996) -> Completely new configuration syntax -> Flexible, categorized logging system -> IP-address-based access control for queries, zone transfers, and updates that may be specified on a zone-by-zone basis -> More efficient zone transfers -> Improved performance for servers with thousands of zones -> The server no longer forks for outbound zone transfers -> Many bug fixes WWW: http://www.isc.org/products/BIND/

では、これを pkg_add コマンドで追加します。

bind は、他のパッケージの依存関係が無いため、特にエラーも出ずにインストール

が終わるはずです。

# pkg_add bind-8.2.3.tgz #

これで bind-8.2.3 は作成できました。

設定ファイルを記述し稼動させてください。

(2) オリジナルソースから作成する

冒頭で述べたように、オリジナルソースから作成する方法があります。

この場合は、リリースされた直後にインストールすることができます。

現在のバージョン確認

新しいバージョンのパッケージをインストールするとき、 現在のバージョンを知る必

要があります。

たとえば、今回例に取り上げる BIND は、次のように調べることができます。

% /usr/bin/nslookup -type=txt -class=chaos version.bind ns.ipa-sec.com Server: ns.ipa-sec.com Address: 172.16.0.1 Aliases: 0.0.16.172.in-addr.arpa VERSION.BIND text = "8.2.3-T6B"

この他にも、バージョン番号を表示するコマンドラインのオプションを持つものや、

strings コマンドで調べなければならならいものがあります。

これはソフトウェアによって異なるため、 それぞれのドキュメントを参照してくださ

い。

インストール

インストール方法は、ソースを取得してくる必要があります。 これは、大手の FTP

サイトでは大抵置かれているのでネットワーク的に近いところから取得してください。

オリジナルは ISC のサイトとなります。http://www.isc.org/

% gzip -d < bind-8.2.3.tar.gz | tar xvf - % cd bind-8.2.3/src % make # make install

2.1.3 アカウント設定

(1) 不要なユーザーアカウントの削除

インストール直後の FreeBSD では、各種サービス用のユーザーアカウントがいくつ

か用意されています。 これらアカウントのうち、小規模サイト運営のために必要なア

カウントはごく少数ですので、不要なユーザーアカウントは削除します。

インストール直後のパスワードファイル例

root::0:0::0:0:Charlie &:/root:/bin/csh toor:*:0:0::0:0:Bourne-again Superuser:/root: daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin

デフォルトで用意されるユーザーアカウントのうち、 小規模サイト運営において不

要なユーザーアカウントは以下の通りです。

表 2.1.3-1 不要なアカウント

ユーザー名 役割

games ゲームプログラムの実行

news newsサーバーの実行

uucp uucp(UNIX to UNIX Copy)の実行

xtem X-10の実行

これらのユーザーアカウントが、どのファイルを所有しているかを確認します。

# find / ¥( -user [ユーザー名] ¥) -exec ls -lad {} ¥;

これによってユーザーアカウントが必要ないことを確認した後、ユーザーアカウントの削

除を行います。

# rmuser 例えば、ユーザーgamesの削除は、以下の通りです。 # rmuser Enter login name for user to remove: games Matching password entry: games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin Is this the entry you wish to remove? y /usr/sbin/rmuser: Informational: Home dir /usr/games is not owned by games (uid 0) , so it won't be removed Updating password file, updating databases, done. Updating group file: (removing group games -- personal group is empty) done. Removing files belonging to games from /tmp: done. Removing files belonging to games from /var/tmp: done. Removing files belonging to games from /var/tmp/vi.recover: done. 上記の要領で、不要なユーザーアカウントを全て削除して下さい。

(2) 不要なグループアカウントの削除

ユーザーアカウントと同じく、グループアカウントもインストール時に数多く用意され

ていますが、 やはり必要なアカウントはごく少数ですので、 不要なグループアカウン

トを削除します。

前述の不要なユーザを削除したことによって関連のグループは削除されています

が、それでもまだ不要なグループが残っています。

インストール直後のグループファイル例

wheel:*:0:root daemon:*:1:daemon kmem:*:2:root sys:*:3:root tty:*:4:root operator:*:5:root mail:*:6: bin:*:7: man:*:9: staff:*:20:root guest:*:31:root bind:*:53: dialer:*:68: network:*:69: nogroup:*:65533: nobody:*:65534:

デフォルトで用意されるグループアカウントのうち、 小規模サイト運営において不

要なグループアカウントは以下の通りです。

表 2.1.3-2 不要なグループ

グループ名 役割

dialer PPP関連プログラムの実行

guest newsサーバーの実行

これらのグループアカウントが、どのファイルを所有しているかを確認します。

# find / ¥( -group [グループ名] ¥) -exec ls -lad {} ¥;

グループアカウントが必要ないことを確認した後、グループアカウントの削除を行います。 (3) 新規ユーザーアカウントの追加

サーバーの管理を行うとき、root で作業しなければならない場合が多いですが、常

に root で作業を行っていると、 誤ってトロイの木馬やウイルス等を実行してしまった

ときの被害は、システム全域に及んでしまうため、 非常に危険です。そのため、通常

の操作時は、権限のあまり高くないユーザーアカウントで作業し、 必要なときだけ su

等で root ログインして、管理作業を行うようにします。

普段、作業を行うユーザーアカウントは、通常のユーザーと同じで構いません。

# adduser 例えば、ユーザ suzukiの追加は、以下の通りです。 # adduser Use option ̀ `-silent'' if you don't want to see all warnings and questions. Check /etc/shells Check /etc/master.passwd Check /etc/group Enter your default shell: bash csh date no sh tcsh zsh [tcsh]: Your default shell is: tcsh -> /usr/local/bin/tcsh Enter your default HOME partition: [/home]: Copy dotfiles from: /usr/share/skel no [/usr/share/skel]: Send message from file: /etc/adduser.message no [/etc/adduser.message]: Use passwords (y/n) [y]: Ok, let's go. Don't worry about mistakes. I will give you the chance later to correct any inpu t. Enter username [a-z0-9_-]: suzuki Enter full name []: SUZUKI Ryouji Enter shell bash csh date no sh tcsh zsh [tcsh]: Enter home directory (full path) [/home/suzuki]: Uid [1002]: Enter login class: default []: Login group suzuki [suzuki]:

Login group is ``suzuki''. Invite suzuki into other groups: guest no [no]: Enter password []: Enter password again []: Name: suzuki Password: **** Fullname: SUZUKI Ryouji Uid: 1002 Gid: 1002 (suzuki) Class: Groups: suzuki HOME: /home/suzuki Shell: /usr/local/bin/tcsh OK? (y/n) [y]: Added user ``suzuki'' Send message to ``suzuki'' and: no root second_mail_address [no]: SUZUKI Ryouji, your account ``suzuki'' was created. Have fun! See also chpass(1), finger(1), passwd(1) Add anything to default message (y/n) [n]: Send message (y/n) [y]: Copy files from /usr/share/skel to /home/suzuki Add another user? (y/n) [y]: n Goodbye! また、追加したユーザーアカウントのパスワードを変更することも忘れず行って下さい。 パスワードの変更は、推測困難なパスワードの設定を参考にして下さい。

2.1.4 パスワードの設定

(1) パスワードの長さ

パスワードは、ある程度の長さを持っていないと、 辞書攻撃などの単純なパスワ

ード解析により見破られてしまいます。そこで、パスワード文字列の 低限の長さを

設定して、 あまりにも短すぎるパスワードが設定されないようにします。

FreeBSD 4.2.2-RELEASE では、 小パスワード長が 6 文字に設定されています。

これでは短いので 8 文字に広げてみましょう。

なお、他システムと連携する場合でパスワード情報の交換を行う状況において、

相手側システムによっては 8 文字を超えたパスワードは 8 文字までしか認識せず、9

文字以上の部分は無視されます。運用を考えると 小パスワード長は8文字までにし

ておいたほうが無難でしょう。

低パスワード長を変更するには/etc/login.conf を変更します。 default エントリに

次の一行を挿入します。

:minpasswordlen=8:¥ (2) パスワードの有効期限

いくら長いパスワードを設定したとしても、膨大な時間をかければ、 やはり単純な

パスワード解析により見破られてしまいます。 そこで、周期的にパスワードを変更し

なければならないように設定します。

たとえば、FreeBSD 4.2-RELEASEのパスワードの有効期限のデフォルト設定は無しになっています。 これを 90日に変更する場合は、 /etc/login.confの defaultエントリに以下の一行を追加してください。

:passwordperiod=90d:¥ :expireperiod

(3) MD5から DESへの変更

現在のバージョンではパスワードファイルに MD5 だけでなく DES も使用できるよう

になっています。特に、4.1.1-RELEASE からは crypto に含まれているため簡単に DES

が利用できるようになりました。DES を使用するには、まず、/etc/login.conf の

default に次の一行を加えます。

:passwd_format=des:¥

この後、cap_mkdb /etc/login.conf を実行することによって DES が使用できるように

なります。

(4) 類推困難なパスワードの設定

ここまでに行ったパスワードのセキュリティ設定で、 だいぶパスワードのセキュリテ

ィレベルは上がりました。 しかし、パスワードそのものが簡単に推測できるようなもの

であれば、 ここまでのセキュリティ設定は、全て水の泡です。 そこで、類推困難なパ

スワードとはどのようなパスワードなのかを理解しなければなりません。

類推しやすいパスワードの例には、以下のようなものがあります。

• ユーザー名そのもの • 会社名 • 社員番号 • 誕生日 • 辞書に載っているような英単語 • 好きなアーティスト等、ユーザーの趣味に関係するもの • 数字や英字のみ(123456、abcdef等) • キーボードの配列(qwerty等)

これらは、パスワードとしての利用は望ましくありません。 以下の要素が全て盛り

込まれたパスワードが望ましいでしょう。

• 推測しやすいパスワードで挙げたものは一切使わない • 無作為で意味を持たない文字列であること • 記号(!、#等)、数字、英字を適当に織り交ぜる

例えば、以下のようなパスワードは推測困難なパスワードの例です。 (ただし、ここ

で挙げたものは、 このドキュメントと共に公開されたことになりますので、 利用しない

で下さい)

• b8!sPi$21tQ • G6pB#iyf7%4E • 5yX(wNn&o

2.1.5 リモートからのアクセスの制限

通常、リモートからのアクセス制限を行う前に、inetd から起動されるものや/etc/rc

から起動されるデーモンの中で不要なものを起動しないように設定します。

しかし、インストールの項で解説したように、 適切なセキュリティモードを選択し、サ

ービスの選択を行っておくことで、 その手間を大きく省くことができます。

たとえば、デフォルトで設定される/etc/inetd.conf は以下のようになっています。

インストール直後の inetd.conf

ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l telnet stream tcp nowait root /usr/libexec/telnetd telnetd comsat dgram udp wait tty:tty /usr/libexec/comsat comsat ntalk dgram udp wait tty:tty /usr/libexec/ntalkd ntalkd

この中で comstat や ntalk を削除することによって、 ftp と telnet のみに絞ることが

できます。

ftpもサーバとして稼動させなければ削除して構いません。 新版のソフトウェアを

取得する時などの ftp コマンドは関係なく動作します。

これらを行った上で、リモートからのアクセス制御を設定します。

telnetd以外をコメント(または削除)し使えないようにする

#ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l telnet stream tcp nowait root /usr/libexec/telnetd telnetd #comsat dgram udp wait tty:tty /usr/libexec/comsat comsat #ntalk dgram udp wait tty:tty /usr/libexec/ntalkd ntalkd

(1) tcp_wrapperによるアクセス制御

セキュリティ確保のためのソフトウェアに tcp_wrapper があります。

tcp_wrapper は、元々inetd から起動されるものに対して有効でしたが、 現在では

/etc/rc 等から起動されるデーモンに対しても、ライブラリを 1 つリンクさせるだけで有

効になっています。

FreeBSD では、インストール時のアプリケーションは既に tcp_wrapper による制御が

可能になっています。

tcp_wrapper によって、特定のホストやネットワーク以外からの接続をサービスごと

に許可や不許可の設定が行えます。

そして、この制御を行う部分が、/etc/hosts.allow です。 インストール直後の

hosts.allow は次のように設定されています。

インストール直後の hosts.allow

# $FreeBSD: src/etc/inetd.conf,v 1.44.2.3 2000/10/04 07:58:51 kris Exp $ # # # hosts.allow access control file for "tcp wrapped" applications. # $FreeBSD: src/etc/hosts.allow,v 1.8.2.3 2000/07/20 15:17:44 ume Exp $ #

# NOTE: The hosts.deny file is deprecated. # Place both 'allow' and 'deny' rules in the hosts.allow file. # See hosts_options(5) for the format of this file. # hosts_access(5) no longer fully applies. # _____ _ _ # | ____| __ __ __ _ _ __ ___ _ __ | | ___ | | # | _| ¥ ¥/ / / _` | | '_ ` _ ¥ | '_ ¥ | | / _ ¥ | | # | |___ > < | (_| | | | | | | | | |_) | | | | __/ |_| # |_____| /_/¥_¥ ¥__,_| |_| |_| |_| | .__/ |_| ¥___| (_) # |_| # !!! This is an example! You will need to modify it for your specific # !!! requirements! ALL : [fe80::]/10 : deny ALL : [3ffe:fffe:2:1:2:3:4:3fe1] : deny ALL : [3ffe:fffe:2:1::]/64 : allow # Sendmail can help protect you against spammers and relay-rapers sendmail : localhost : allow sendmail : .nice.guy.example.com : allow sendmail : .evil.cracker.example.com : deny sendmail : ALL : allow # Exim is an alternative to sendmail, available in the ports tree exim : localhost : allow exim : .nice.guy.example.com : allow exim : .evil.cracker.example.com : deny

exim : ALL : allow # Portmapper is used for all RPC services; protect your NFS! # (IP addresses rather than hostnames *MUST* be used here) portmap : 192.0.2.32/255.255.255.224 : allow portmap : 192.0.2.96/255.255.255.224 : allow portmap : ALL : deny # Provide a small amount of protection for ftpd ftpd : localhost : allow ftpd : .nice.guy.example.com : allow ftpd : .evil.cracker.example.com : deny ftpd : ALL : allow # You need to be clever with finger; do _not_ backfinger!! You can easily # start a "finger war". fingerd : ALL ¥ : spawn (echo Finger. | ¥ /usr/bin/mail -s "tcpd¥: %u@%h[%a] fingered me!" root) & ¥ : deny # The rest of the daemons are protected. ALL : ALL ¥ : severity auth.info ¥ : twist /bin/echo "You are not welcome to use %d from %h."

過去の tcp_wrapper は、/etc/hosts.allow に許可するホストとサービス、

/etc/hosts.deny に不許可のサービスとホストという記述方法でした。

現在では、hosts.allow に一本化され、 許可および不許可共にこのファイルで設定

するようになりました。

それでは実際にアクセス制限の設定を行ってみましょう。

tcp_wrapper の構文は従来と同じです。

サービス名:ホスト:allow(許可) または deny(不許可) たとえば、telnetを 192.168.0.0/24の範囲以外を禁止する場合は次のように記述します。

telnetd:192.168.0.0/255.255.255.0:allow

これで、192.168.0.0/24 の以外からの telnet 要求は拒否されます。 もし、

192.168.0.0/24 だけでなく、ipa-sec.com のネットワークアドレスを指定するには次のよ

うに記述します。

telnetd : 192.168.0.0/255.255.255.0 : allow telnetd : 172.16.0.0/255.255.0.0 : allow

もし、これら 2 つのネットワークに加えて、10.1.1.1/8 という特定のホストを加えたいの

であれば、同様に記述します。

また、この時は、一行に一定義だけではなく、カンマで区切ることもできます。

telnetd : 192.168.0.0/255.255.255.0 : allow telnetd : 172.16.0.0/255.255.0.0,10.1.1.1/255.0.0.0 : allow

もし、アクセス不許可の設定になっているホストやサービスに対して接続されてきた場

合、tcp_wrapper は/var/log/messages にその事実を記述します。

よって、管理者は/var/log/messages の監視を行う必要があります。

(2) アクセス不許可の通知

管理者は/var/log/messages の監視を行う場合、 24 時間見張っているわけにもい

きません。 また、一日一回などの参照では何か重大な事実が発生したときに対処が

遅れることが考えられます。

/etc/hosts.allow のデフォルトで設定されているものの中に次のような定義がある

ことにお気づきでしょう。

初の定義は、アクセス不許可の設定に引っかかった相手に対して finger を送り、

その結果をメールで root 宛に送信している部分です。

次の定義は、アクセス不許可の設定に引っかかった相手に対して何らかのメッセー

ジを送るときに使用します。これによって、許可されていないホストから telnet を行うと

"You are not welcome to use ドメイン名 from ホスト名." というメッセージを表示して

切断します。

tcp_wrapperによって接続を許可されずに切断されるときの処理

fingerd : ALL ¥ : spawn (echo Finger. | ¥ /usr/bin/mail -s "tcpd¥: %u@%h[%a] fingered me!" root) & ¥ : deny # The rest of the daemons are protected. ALL : ALL ¥ : severity auth.info ¥ : twist /bin/echo "You are not welcome to use %d from %h."

それでは、これをカスタマイズして更に詳しい情報を管理者に送信するようにして

みましょう。

詳細は tcpd の man page に記述されていますが、%d や%h 以外にも使用可能な変

数があります。

許可されていないホストからの接続が行われた際、相手の IP アドレスやホスト名、

接続しようとしたプロセスなどを列挙し管理者宛に送信します。

ここでは、root 宛に送信していますが、たとえば管理を他のドメインの管理者に依

頼しているケースは"ユーザ名@ドメイン名"という通常のメールアドレスも記述できま

すし、管理者と管理者の携帯端末というように複数指定したい場合は","で区切りま

す。

hosts.denyまたは hosts.allowの ALL:ALL部を置き換える

ALL : ALL ¥ : severity auth.info : spawn (/usr/bin/finger -l @%h | ¥ /usr/bin/printf " ¥ client address ¥: %a ¥n ¥ client hostname ¥: %n ¥n ¥ client username ¥: %u ¥n ¥ client info ¥: %c ¥n ¥ server address ¥: %A ¥n ¥ server hostname ¥: %N ¥n ¥ server process ¥: %d ¥n ¥ server info ¥: %s" | ¥ /usr/bin/mail -s "tcpd¥: %u@%h[%a] tried to use %d (denied)" root) & ¥ : twist /bin/echo "You are not welcome to use %d from %h."

なお、FreeBSD 4.2-RELEASE においては、同様の内容が/etc/hosts.deny に記述

されているため追加は不要です。

このようにして、管理者は効率よく作業を進めることができます。

この他にも色々な応用例がありますが、 設定の工夫やスクリプトの実行によって

実現できることが多くあります。運用や環境に合わせて少しずつ試してみてください。

2.1.6 ローカルリソースへのアクセス制限

通常、上記で説明したセキュリティ設定により、 リモートからのアクセスが制限され

れば、 ローカルリソースのセキュリティを気にする必要はほとんどなくなるはずです。

しかし、外部に公開しているサービス対して攻撃を仕掛けられた場合、 そしてその

サービスにセキュリティホールが存在した場合、 リモートからの侵入を許可してしまう

場合も考えられます。

リモートから root 権限で侵入された場合は、 システムは完全に攻略されている可

能性が高いと考えられます。

取りうる対応策としては、システムの再インストールぐらいしかありませんが、 権限

の低いユーザーによる侵入であれば、 ローカルリソースへのアクセス制限を施すこ

とにより、 システム全域の攻略を未然に防衛することは可能です。

(1)不要な SUIDビットの除去

root が所有者である SUID ビットがセットされた実行ファイルやディレクトリは、 プロ

グラムのバグや設定ミスを利用したアタック、 あるいはシンボリックリンクを利用した

アタックにより、 真っ先に攻撃対象として狙われます。

そのため、必要がない限りは、 ファイルおよびディレクトリから SUID ビットは除去

すべきです。

SUID ビットがセットされているファイルを検索するには、 以下のコマンドを実行しま

す。

# find / ¥( -perm -4000 ¥) -exec ls -lad {} ¥; -r-sr-xr-x 4 root wheel 20532 Aug 18 2001 /usr/bin/at -r-sr-xr-x 4 root wheel 20532 Aug 18 2001 /usr/bin/atq -r-sr-xr-x 4 root wheel 20532 Aug 18 2001 /usr/bin/atrm -r-sr-xr-x 4 root wheel 20532 Aug 18 2001 /usr/bin/batch -r-sr-xr-x 3 root wheel 19024 Aug 18 2001 /usr/bin/chfn -r-sr-xr-x 3 root wheel 19024 Aug 18 2001 /usr/bin/chpass -r-sr-xr-x 3 root wheel 19024 Aug 18 2001 /usr/bin/chsh -r-sr-xr-x 1 root wheel 23036 Aug 18 2001 /usr/bin/crontab -r-sr-xr-x 1 root wheel 7792 Aug 18 2001 /usr/bin/lock -r-sr-xr-x 1 root wheel 24120 Aug 18 2001 /usr/bin/login -r-sr-xr-x 2 root wheel 14808 Aug 18 2001 /usr/bin/passwd -r-sr-xr-x 1 root wheel 11220 Aug 18 2001 /usr/bin/rlogin -r-sr-xr-x 1 root wheel 4644 Aug 18 2001 /usr/bin/skeyinfo -r-sr-xr-x 1 root wheel 10980 Aug 18 2001 /usr/bin/skeyinit -r-sr-xr-x 1 root wheel 12464 Aug 18 2001 /usr/bin/su -r-sr-xr-- 1 uucp dialer 44064 Aug 18 2001 /usr/bin/tip ... (省略)

ここで検索されたファイルやディレクトリで所有者が root に設定されているものが

あれば、 root 権限を乗っ取られる危険性があり、セキュリティ面において望ましくあり

ません。 できる限り、SUID ビットを除去して下さい。

逆に、SUID ビットを除去すると、悪影響が発生するファイルには、 以下のようなフ

ァイルがあります。

表 2.1.6-1 SUIDビットを除去してはいけないファイル例

ファイル名 役割

/usr/bin/passwd パスワードの変更

/usr/bin/su 別ユーザでの実行

その他にも、SUID ビットが必須のファイルが存在します。 SUID ビットを除去する場

合は、注意して下さい。

(2) 設定ファイルのアクセス権

以下に挙げる設定ファイルおよびディレクトリは、 root 以外のユーザーに読み取り

可能となっていますが、 root のみ読み書きできるように設定した方が安全です。

表 2.1.6-2 アクセス権を変更した方が良いファイル例

/etc/rc.conf システム起動に関する設定ファイル

/etc/fstab 起動時にマウントするボリュームの設定ファイル

/usr/local/etc/rc.d/ システム起動時に実行されるスクリプトの設定ファイルが入ったディ

レクトリ

root 以外のユーザーが読み取れないようにするには、 以下のようにアクセス権を

変更して下さい。

# chmod 600 /etc/fstab # chmod -R 700 /usr/local/etc/rc.d/

2.1.7 ログの確認

日頃からログの確認を行うことは非常に重要です。 しかし、ログを過信することは

禁物です。

この 2 つは相反することのようですが、実は密接な関係があります。

DoS などの攻撃においてはログの確認を行うことが必要になります。 しかし、もし

侵入された場合はどうでしょうか。

侵入する側の立場で考えてみると答えは明瞭です。 もし管理者権限を取得し侵入

に成功した場合、 侵入者が 後に行うことはログの削除です。侵入先に対して侵入

したことを知られるまでの時間をできるかぎり延ばしたい場合、 その足跡を消してお

くことを行うでしょう。

しかし、ログの存在はセキュリティにおいて重要なものになります。

ログを見るときに確認しておくべきことがいくつかあります。 それは正しいログであ

ることです。たとえば、一日一度や一週間に一度など定期的にログを保存し次のログ

を新規で作成する運用を行うサイトは少なくありません。 もし、この運用を行っている

場合、数日間を通してログの大きさに極端な変化はありません。 たとえば、これまで

一日に 1MB のログファイルが抽出されていたのにもかかわらず、 今日になって

100KB になったなどです。

確認すべきログはいくつかあります。主なものは以下の通りです。

システム全体 /var/log/messages

ユーザのログイン情報 /var/log/wtmp

メールの配送状態 /var/log/maillog

httpd(Apache)の利用状態 /usr/local/apache/logs (設定されたパス)

ftpd(wu-ftpd)の利用状態 /var/log/xferlog (設定されたパス)

2.2 RedHat Linux 7.0

RedHat Linux は、RedHat 社が提供する代表的な Linux ディストリビューションです。

ディストリビューションとしては、Slackware が全盛であった 1994 年に登場して以来、

革新的なインストール環境の改善やユーザービリティの向上を果たしています。

しかしその反面、ユーザーが使いやすくなればなるほど、 本来は持ってしかるべき

知識を持たないユーザーがシステムを構築したり、 ネットワークを構築するというよう

な状況を生み出します。

特に、近年の Linux ブームも手伝ってか、 構築されたネットワークの中核がデフォ

ルト状態の Linux であるというケースも、 数多く見受けられますが、セキュリティ面で

見れば、非常に危険な状態です。 デフォルト状態の Linux は、脆弱なセキュリティし

か持ち合わせていないことを認識して下さい。

ここでは、 新の RedHat Linux である、 RedHat Linux 7.0 のセキュリティを向上さ

せるための方法について解説します。

なお、本文は RedHat Linux 7.0 について説明をしていますが、 Vine Linux や Turbo

Linux 等の RedHat Linux ベースのディストリビューションや、 Slackware 等その他のデ

ィストリビューションに対しても、 有益な情報も含んでおります。

• 2.2.1 インストール時の設定 • 2.2.2 セキュリティパッチの適用 • 2.2.3 アカウントのセキュリティ設定 • 2.2.4 パスワードのセキュリティ設定 • 2.2.5 リモートからのアクセス制限 • 2.2.6 ローカルリソースへのアクセス制限 • 2.2.7 ログの確認

2.2.1 インストール時の設定

RedHat Linux 7.0 は、以下のインストール種別があります。

• ワークステーション • サーバー • カスタム • アップグレード

通常、インターネットに接続するマシンに RedHat Linux 7.0 をインストールする場合、

サーバーもしくはカスタムを利用するのが望ましいのですが、 デフォルトのインストー

ル種別がワークステーションであるため、 この種別にてインストールを行っているケ

ースが多いのではないかと思います。

よって、以降の説明は、ワークステーションでインストールを始めたときのセキュリ

ティ対策について説明します。また、内容の大半は、サーバーやカスタム、 あるいは

過去のバージョンからのアップグレードに対しても有効ですので、 そういったインスト

ール種別に対するセキュリティ対策としても参考にして下さい。

インストール中に設定すべき項目は、以下の 3 つです。

• rootのパスワードの設定 • シャドウパスワードの有効化 • MD5パスワードの有効化

まず、root のパスワードとしてどのようなパスワードを使ったら良いのでしょうか。

これは、推測困難なパスワードの設定を参考にして下さい。

なお、ここで設定したパスワードを忘れると、rootログインができなくなり、 再度イン

ストールをやり直すことになりますので、注意して下さい。

2.2.2 セキュリティパッチの適用

RedHat Linux 7.0 におけるセキュリティパッチの適用には、 以下の 2 通りの方法が

あります。

• RPM形式のコンパイル済みバイナリパッケージの適用 • ソースアーカイブパッケージの適用

「RPM 形式のコンパイル済みバイナリパッケージ」とは、 RPM(RedHat Package

Manager)と呼ばれる、 RedHat Linux 系 Linux のためのソフトウェアパッケージ管理シ

ステムとして作成されたパッケージです。 RPM を用いたセキュリティパッチの適用に

は、以下のメリットがあります。

• プログラムのインストールやアンインストールが簡単にできます。 • インストールされているプログラムのインストール状況や バージョンチェック等が簡単に確認できます。

• RPMパッケージは、 コンパイル済みのバイナリプログラムがパッケージ化されているため、 プログラムのコンパイルなしでインストールができます。

逆に以下のデメリットがあります。

• RPM パッケージは、ソースコードのリリースよりも若干遅れてリリースされるた

め、 最新のセキュリティが確保できない可能性があります。 • 人気のないプログラムは、 RPMパッケージとしてリリースされない場合があります。

• コンパイル時のライブラリとインストール先システムにあるライブラリのバージョ

ンにより、 正しくインストールされない場合や、正常に動作しない場合があります。

よって、 新のセキュリティを確保し、正常に動作させるためには、 ソースコードを

圧縮してパッケージ化した、 「ソースアーカイブパッケージ」を適用する方が安全では

あります。 ですが、 近は RPM パッケージによるセキュリティパッチのリリースも積

極的に行われているため、これら 2 通りの方法について解説します。

(1) RPM形式のコンパイル済みバイナリパッケージの適用

RPM パッケージによるインストールやパッケージの中身の確認は、 rpm コマンドを

使用します。 rpmコマンドは、root権限で実行する必要がありますので、 su等でroot

ログインを行って下さい。

インストール済みの RPMパッケージの確認

まず、RPM パッケージがシステムにインストール済みか否かを確認します。 以下

のコマンドで、システムにインストールされている RPM パッケージ全てをリストアップし

ます。

# rpm -qa glibc-2.1.93-2

mktemp-1.5-5 anacron-2.3-9 ... (省略) ... xscreensaver-3.25-4 yp-tools-2.4-4 openssh-server-2.1.1p4-1

パッケージ名がわかっている場合は、パッケージ名を指定して確認します。

# rpm -qi [パッケージ名] 例えば、bind が RPM パッケージでインストールされているか否かは、以下のコマンド

で確認します。 # rpm -qi bind Name : bind Relocations: (not relocateable) Version : 8.2.2_P5 Vendor: Red Hat, Inc. Release : 25 Build Date: 2000 年 08 月 06日 02 時 21 分 34 秒 Install date: 2001 年 02 月 06 日 22 時 12 分 50 秒 Build Host: porky.devel.redhat.com Group : システム環境/デーモン Source RPM: bind-8.2.2_P5-25.src.rpm Size : 5285346 License: distributable Packager : Red Hat, Inc. URL : http://www.isc.org/bind.html Summary : DNS (Domain Name System) サーバ Description : BIND (Berkeley Internet Name Domain) は DNS (Domain Name System) プロトコ ルを実装したものです。BIND には、ホスト名を IP アドレスに解決する DNS サーバ(named) と、リゾルバライブラリ (DNS とのやり取りのために アプリケーションが使用するルーチン) が含まれます。DNS サーバは、リソースや

オブジェクトをクライアントが名前で指定することを可能にすると同時に、 その情報をネットワーク上の他のマシンと共有できるようにします。named DNS サーバは、ワークステーション上でキャッシングネームサーバとしても 利用できますが、通常はネットワーク全体で 1 台のマシン上で動作させるだけで 十分です。なお、BIND をシンプルなキャッシングネームサーバとして動作させる ための設定ファイルは、caching-nameserver パッケージに含まれています。

インストールされていない場合は、以下のように表示されます。

# rpm -qi bind パッケージ bind はインストールされていません RPMパッケージを使ったインストール

もし、RPM パッケージ自体がインストールされていない場合は、 RedHat Linux 7.0

のインストール CD からインストールして下さい。

# rpm -Uvh [パッケージファイル名]

bindをインストール CDからインストールする場合は、 インストール CDをマウントした後、 以下のコマンドを実行して下さい。 # rpm -Uvh /mnt/cdrom/RedHat/RPMS/bind-8.2.2_P5-25.i386.rpm bind ################################################## セキュリティパッチの入手

インストールされている RPM パッケージにセキュリティホールがある場合は、 セキ

ュリティパッチの RPM パッケージを入手します。 RPM パッケージによる 新のセキュ

リティパッチは、 RedHat 社の「Red Hat Linux Errata」からダウンロードします。

Red Hat Linux Errata http://www.redhat.com/support/errata/rh7-errata-security.html

ダウンロードした RPM パッケージにどのようなファイルが含まれているかを確認し

ます。

# rpm -qlp [パッケージ名].rpm 例えば、'bind-8.2.3-0.5.x.i386.rpm'というパッケージに入っているファイルの確認は、以下の通りです。 # rpm -qlp bind-8_2_3-0_5_x_i386.rpm /etc/logrotate.d/named /etc/rc.d/init.d/named /usr/doc/bind-8.2.3 (省略) /usr/sbin/named-xfer /usr/sbin/ndc /var/named セキュリティパッチの適用

一通り内容を確認したら、設定ファイル等のバックアップを取って下さい。 その後、

セキュリティパッチを適用します。

# rpm -Fvh [パッケージ名].rpm 例えば、'bind-8.2.3-0.5.x.i386.rpm'というセキュリティパッチの適用は、 以下の通りです。 # rpm -Fvh bind-8.2.3-0.5.x.i386.rpm bind ##################################################

次に、セキュリティパッチが適用され、 バージョンが上がったことを確認して下さ

い。

# rpm -qi bind

Name : bind Relocations: (not relocateable) Version : 8.2.3 Vendor: Red Hat, Inc. Release : 0.5.x Build Date: 2001 年 01 月 27日 19 時 53 分 57 秒 Install date: 2001 年 03 月 02 日 16 時 18 分 31 秒 Build Host: porky.devel.redhat.com Group : システム環境/デーモン Source RPM: bind-8.2.3-0.5.x.src.rpm Size : 6084577 License: distributable Packager : Red Hat, Inc. URL : http://www.isc.org/bind.html Summary : DNS (Domain Name System) サーバ Description : BIND (Berkeley Internet Name Domain) は DNS (Domain Name System) プロトコ ルを実装したものです。BIND には、ホスト名を IP アドレスに解決する DNS サーバ(named) と、リゾルバライブラリ (DNS とのやり取りのために アプリケーションが使用するルーチン) が含まれます。DNS サーバは、リソースや オブジェクトをクライアントが名前で指定することを可能にすると同時に、 その情報をネットワーク上の他のマシンと共有できるようにします。named DNS サーバは、ワークステーション上でキャッシングネームサーバとしても 利用できますが、通常はネットワーク全体で 1 台のマシン上で動作させるだけで 十分です。なお、BIND をシンプルなキャッシングネームサーバとして動作させる ための設定ファイルは、caching-nameserver パッケージに含まれています。

なお、RPM の詳細については、以下のサイトを参照して下さい。

JF - RPMによるパッケージ管理(RedHat Linux/Vine Linux) http://www.linux.or.jp/JF/contrib/LILO-doc/rpm.html

(2) ソースアーカイブパッケージの適用

ソースアーカイブパッケージによるセキュリティパッチの適用は、 インストールする

パッケージやパッチの形態によって、様々です。 既にインストールされているファイル

に patch コマンドでパッチをあてる場合もあります。 パッチの適用をスクリプトで実行

する場合もあります。 パッチが存在しない場合は、既にインストールされているパッ

ケージをバックアップした後、 新規にインストールしなおし、バックアップから設定ファ

イルだけを元に戻す場合もあります。 ですので、具体的な適用方法は、パッケージ

のダウンロード元のホームページや、 パッケージに付属されているマニュアルを参照

して行って下さい。

ソースアーカイブパッケージを使ったインストールについての説明については、以

下のサイトを参照して下さい。

JF - Building and Installing Software Packages for Linux http://www.linux.or.jp/JF/JFdocs/Software-Building-HOWTO.html

2.2.3 アカウントのセキュリティ設定

(1) 不要なユーザアカウントの削除

インストール直後の RedHat Linux 7.0 は、 各種サービス用のユーザアカウントが

数多く用意されています。 ですが、これらアカウントのうち、 サーバー運営のために

必要なアカウントはごく少数ですので、 不要なユーザアカウントは削除します。

インストール直後のパスワードファイル例

root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin: daemon:x:2:2:daemon:/sbin: adm:x:3:4:adm:/var/adm: lp-:x:4:7:lp:/var/spool/lpd: sync-:x:5:0:sync:/sbin:/bin/sync shutdown-:x:6:0:shutdown:/sbin:/sbin/shutdown halt-:x:7:0:halt:/sbin:/sbin/halt mail:x:8:12:mail:/var/spool/mail: news-:x:9:13:news:/var/spool/news: uucp-:x:10:14:uucp:/var/spool/uucp:

operator:x:11:0:operator:/root: games-:x:12:100:games:/usr/games: gopher-:x:13:30:gopher:/usr/lib/gopher-data: ftp:x:14:50:FTP User:/home/ftp: nobody:x:99:99:Nobody:/: xfs-:x:100:101:X Font Server:/etc/X11/fs:/bin/false postgres-:x:101:233:PostgreSQL Server:/var/lib/pgsql:/bin/bash smbguest-:x:500:501:SMB Guest Account:/dev/null:/dev/null wnn-:x:127:502:Wnn System Account:/home/wnn:/bin/bash

デフォルトで用意されるユーザアカウントのうち、 不要だと思われるユーザアカウ

ントは以下の通りです。

表 2.2.3-1 不要なユーザ

ユーザ

名 役割 削除をしてはいけないケース

lp 印刷関連プログラム(lpq、lpr等)の実行

サーバーにプリンタを接続する場合やサーバー

から印刷をする場合

news newsサービスの実行 サーバーを newsサーバーとして利用する場合

uucp UUCP(UNIX to UNIX Copy)の実行

メール転送に UUCPを利用する場合

games ゲームプログラムの実行 なし

gopher gopherサービスの実行 サーバーを gopherサーバーとして利用する場合

wnn wnn かな漢字変換サービスの実行

サーバーを wnn かな漢字変換サーバーとして利用する場合

これらのユーザアカウントが、どのファイルを所有しているかを確認します。

# find / ¥( -user [ユーザ名] ¥) -exec ls -lad {} ¥; 例えば、ユーザ"lp"が所有しているファイルの確認は、 以下の通りです。

# find / ¥( -user lp ¥) -exec ls -lad {} ¥; -rwxr-xr-x 1 lp lp 429984 8 月 15 04:23 /usr/bin/lpq -rwxr-xr-x 1 lp lp 439872 8 月 15 04:23 /usr/bin/lpr -rwxr-xr-x 1 lp lp 426720 8 月 15 04:23 /usr/bin/lprm -rwxr-xr-x 1 lp lp 433792 8 月 15 04:23 /usr/bin/lpstat -rwxr-xr-x 1 lp lp 431584 8 月 15 04:23 /usr/sbin/lpc

ユーザアカウントが必要ないことを確認した後、 ユーザアカウントの削除を行いま

す。

# userdel [ユーザ名] 例えば、ユーザ"lp"の削除は、以下の通りです。

# userdel lp

上記の要領で、不要なユーザアカウントを全て削除して下さい。

(2) 不要なグループアカウントの削除

ユーザアカウントと同じく、 グループアカウントもインストール時に数多く用意され

ていますが、 やはり必要なアカウントはごく少数ですので、 不要なグループアカウン

トを削除します。

インストール直後のグループファイル例

root:x:0:root bin:x:1:root,bin,daemon daemon:x:2:root,bin,daemon

sys:x:3:root,bin,adm adm:x:4:root,adm,daemon tty:x:5: disk:x:6:root lp:x:7:daemon,lp mem:x:8: kmem:x:9: wheel:x:10:root mail:x:12:mail news:x:13:news uucp:x:14:uucp man:x:15: games:x:20: gopher:x:30: dip:x:40: ftp:x:50: nobody:x:99: users:x:100: utmp:x:22: xfs:x:101: floppy:x:19: console:x:102: pppusers:x:230: popusers:x:231: slipusers:x:232: postgres:x:233: public:x:500: smbguest:x:501: slocate:x:21: wnn:x:502:

デフォルトで用意されるグループアカウントのうち、 サーバー運用において不要な

グループアカウントは以下の通りです。

表 2.2.3-2 不要なグループ

グループ 役割 削除をしてはいけないケース

名

Lp 印刷関連プログラム(lpq、lpr等)の実行

サーバーにプリンタを接続する場合やサーバー

から印刷をする場合

news newsサービスの実行 サーバーを newsサーバーとして利用する場合

uucp UUCP(UNIX to UNIX Copy)の実行

メール転送に UUCPを利用する場合

games ゲームプログラムの実行 なし

gopher gopherサービスの実行 サーバーを gopher サーバーとして利用する場合

wnn wnn かな漢字変換サービスの実行

サーバーをwnnかな漢字変換サーバーとして利用する場合

これらのグループアカウントが、どのファイルを所有しているかを確認します。

# find / ¥( -group [グループ名] ¥) -exec ls -lad {} ¥;

例えば、グループ"lp"が所有しているファイルの確認は、以下の通りです。

# find / ¥( -group lp ¥) -exec ls -lad {} ¥; -rwxr-xr-x 1 lp lp 429984 8 月 15 04:23 /usr/bin/lpq -rwxr-xr-x 1 lp lp 439872 8 月 15 04:23 /usr/bin/lpr -rwxr-xr-x 1 lp lp 426720 8 月 15 04:23 /usr/bin/lprm -rwxr-xr-x 1 lp lp 433792 8 月 15 04:23 /usr/bin/lpstat -rwxr-xr-x 1 lp lp 431584 8 月 15 04:23 /usr/sbin/lpc

グループアカウントが必要ないことを確認した後、 グループアカウントの削除を行い

ます。

# groupdel [グループ名]

例えば、グループ"lp"の削除は、以下の通りです。

# groupdel lp

上記の要領で、不要なグループアカウントを全て削除して下さい。

(3) 新規ユーザアカウントの追加

サーバーの管理を行うとき、root で作業しなければならない場合が多いですが、

常に root で作業を行っていると、 誤ってトロイの木馬やウイルス等を実行してしまっ

たときの被害は、 システム全域に及んでしまうため、 非常に危険です。そのため、

通常の操作時は、 権限のあまり高くないユーザアカウントで作業し、 必要なときだ

け su 等で root ログインして、 管理作業を行うようにします。

普段、作業を行うユーザアカウントは、通常のユーザと同じで構いません。 デフォ

ルトで用意されている users グループに所属するユーザアカウントを作成して下さい。

# useradd -g users [ユーザ名]

例えば、usersグループに所属するユーザ workuserの追加は、以下の通りです。

# useradd -g users workuser

また、追加したユーザアカウントのパスワードを変更することも忘れず行って下さい。

パスワードの変更は、推測困難なパスワードの設定を参考にして下さい。

2.2.4 パスワードの設定

(1) パスワードの長さ

パスワードは、ある程度の長さを持っていないと、 辞書攻撃などの単純なパスワ

ード解析により見破られてしまいます。そこで、パスワード文字列の 低限の長さを

設定して、 あまりにも短すぎるパスワードが設定されないようにします。

RedHat Linux 7.0 のパスワードの長さのデフォルト設定は、5 文字です。 これはや

や短いので、ある程度の長さ(ここでは 8 文字とします)に変更します。

パスワードの長さは、/etc/login.defs の PASS_MIN_LEN で以下のように設定されて

います。

PASS_MIN_LEN 5 これを以下のように変更して下さい。

PASS_MIN_LEN 8 また 8 文字以上に設定すれば、よりセキュリティレベルは上がりますが、忘れてしまったり、 メモを残さなければ覚えられないといった問題も出てきますので、 覚えられる範囲で適当な長さを設定して下さい。 (2) パスワードの有効期限

いくら長いパスワードを設定したとしても、膨大な時間をかければ、 やはり単純な

パスワード解析により見破られてしまいます。 そこで、周期的にパスワードを変更し

なければならないように設定します。

たとえば、RedHat Linux 7.0のパスワードの有効期限のデフォルト設定は、99999日です。 これはあまりにも長すぎる期間なので、ある程度の周期(ここでは 30日とします)を有効期限として設定します。 パスワードの有効期限は、/etc/login.defs の PASS_MIN_LEN で以下のように設定され

ています。

PASS_MAX_DAYS 99999 これを以下のように変更して下さい。

PASS_MAX_DAYS 30

また必要があれば、有効期限切れが近づいたことを警告する日数も同時に変更しておい

て下さい。 デフォルト設定は有効期限切れの 7 日前ですが、有効期限が 30 日の場合はこれで構いません。

(3) パスワードの隔離

パスワードファイルからパスワードを抜き出して別のファイルに隔離することで、 パ

スワード自体が盗まれる危険性を低くできます。 RedHat Linux 7.0では、シャドウパス

ワードにより、これが実現されます。 なお、インストール中にシャドウパスワードの有

効化を行っている場合、 パスワードの隔離は完了していますので、ここでの説明は

読み飛ばして下さい。

シャドウパスワードの設定には、authconfig を使用します。

(4) パスワードの暗号化

パスワードを暗号化することにより、パスワードクラックが困難になり、時間稼ぎと

なります。 RedHat Linux や FreeBSD では、PAM(Pluggable Authentication Modules)

のよる、 MD5 暗号化パスワードにより、これが実現されます。 なお、インストール中

に MD5 パスワードの有効化を行っている場合、 パスワードの暗号化は完了していま

すので、ここでの説明は読み飛ばして下さい。

(5) 類推困難なパスワードの設定

ここまでに行ったパスワードのセキュリティ設定で、 だいぶパスワードのセキュリテ

ィレベルは上がりました。 しかし、パスワードそのものが簡単に推測できるようなもの

であれば、 ここまでのセキュリティ設定は、全て水の泡です。 そこで、類推困難なパ

スワードとはどのようなパスワードなのかを理解しなければなりません。

類推しやすいパスワードの例には、以下のようなものがあります。

• ユーザー名そのもの • 会社名 • 社員番号 • 誕生日 • 辞書に載っているような英単語 • 好きなアーティスト等、ユーザーの趣味に関係するもの • 数字や英字のみ(123456、abcdef等) • キーボードの配列(qwerty等)

これらは、パスワードとしての利用は望ましくありません。 以下の要素が全て盛り

込まれたパスワードが望ましいでしょう。

• 推測しやすいパスワードで挙げたものは一切使わない • 無作為で意味を持たない文字列であること • 記号(!、#等)、数字、英字を適当に織り交ぜる

例えば、以下のようなパスワードは推測困難なパスワードの例です。 (ただし、ここ

で挙げたものは、 このドキュメントと共に公開されたことになりますので、 利用しない

で下さい)

• b8!sPi$21tQ • G6pB#iyf7%4E • 5yX(wNn&o

また、どうしても推測困難なパスワードが思い付かない場合は、 mkpasswdというツールにより、推測困難なパスワードを生成し、 passwdで設定するという選択肢もあります。

# mkpasswd qTfm14xcK

mkpasswdは、推測困難なパスワードを簡単に生成できるため便利ですが、 mkpasswd

で作成したパスワードは覚えづらい上、 生成されたパスワード自体に問題があるかも知れませんので、 極力自力でパスワードを作成することをお勧めします。

2.2.5 リモートからのアクセス制限

インストール直後の RedHat Linux 7.0 は、様々なサービスが利用可能となっていま

す。 それらサービスの中には、 メールサーバーのような外部からのアクセスが必要

なサービスもありますが、 かな漢字変換サーバーのような外部からのアクセスが必

要ないサービスもあります。 また、外部からのアクセスがセキュリティ上好ましくない

サービスも含まれています。 外部からアクセスされるサービスを必要 低限なサー

ビスだけに絞るためには、 サービスの停止や無効化、 もしくはサービスにアクセス

するためのポートのアクセス制限を行う必要があります。

なお、ここに挙げたものは OS としての機能を中心としています。

この他にも ipchains を使用できます。 詳細は、ipchains を参照してください。

(1) xinetdによるサービスへのアクセス制御

RedHat Linux 7.0 に標準搭載のスーパーサーバーは、 RedHat Linux 6.x まで標準

搭載であった inetd から、 DoS 対策や設定のきめ細かさをより重視した xinetd へと変

更されました。 ここでは、xinetd をスーパーサーバーとして利用する場合の設定につ

いて説明します。 なお、inetd と TCP Wrapper をスーパーサーバーとして利用する場

合は、 後述の inetd と TCP Wrapper によるサービスへのアクセス制御を参照して下さ

い。

xinetdのインストール

xinetdがインストールされていない場合は、以下の手順でxinetdをインストールして

下さい。 なお、RedHat Linux 7.0 をワークステーションでインストールした場合、

xinetd はインストールされません。

xinetd は、RedHat Linux 7.0 のインストール CD に RPM パッケージで入っています。

インストール CD をマウントした後、以下のコマンドでインストールを実行して下さい。

# rpm -Uvh /mnt/cdrom/RedHat/RPMS/xinetd-2.1.8.9pre9-6.i386.rpm xinetd ################################################## 設定ファイルのアクセス権変更

xinetd の設定は、/etc/xinetd.conf と、 /etc/xinetd.d/以下に置かれる各サービス

毎のアクセス制御ファイルによって行われます。 xinetd のインストール直後は、設定

ファイルが root 以外のユーザーに読み取り可能となっていますので、 root 以外のユ

ーザーが読み取れないようにアクセス権を変更します。

# chmod 600 /etc/xinetd.conf # chmod -R 600 /etc/xinetd.d/ xinetd.confの設定

/etc/xinetd.conf には、各サービスに共通の設定をします。

defaults { instances = 60 log_type = SYSLOG authpriv

log_on_success = HOST PID log_on_failure = HOST RECORD } includedir /etc/xinetd.d 基本的には、/etc/xinetd.confの設定はデフォルトのままで構いませんが、 DoS対策とし

て、サービスプロセスへのアクセスタイムアウト秒数である instance をより小さな値に設定することもできます。 この値を変更すると、xinetdから起動される全てのサービスプロセスのアクセスタイムアウト秒数が変更されます。 ただし、あまり小さな値に設定すると、 提供すべきサービスもネットワークの負荷などが原因で正常に接続できなくなる可能性が

出てきますので、 ネットワークの負荷と DoSの境界をどこに設定するか等を考えてから変更して下さい。 各サービス毎のアクセス制御ファイルの設定

/etc/xinetd.d/以下に置かれる各サービス毎のアクセス制御ファイルは、

/etc/services に登録されているサービス(ftp や telnet 等)1 つに対して、 1 つのアク

セス制御ファイルが対応するように設定します。

RedHat Linux 7.0 のインストール CD に RPM パッケージで入っているサービスアプ

リケーションは、 該当するサービス用のアクセス制御ファイルも一緒にインストールし

ます。 例えば、telent サーバー(telnet-server-0.17-7.i386.rpm)をインストールした場

合、 以下のアクセス制御ファイル(/etc/xinetd.d/telnet)もインストールされます。

service telnet { flags = REUSE socket_type = stream wait = no user = root server = /usr/sbin/in.telnetd log_on_failure += USERID } これも、基本的には、デフォルト設定のままで構いません。

なお、不要なサービス用のアクセス制御ファイルを/etc/xinetd.d/以下に置くと、

不要なサービスのアクセスを許可することになりますので、 必要なサービスアプリケ

ーションだけをインストールするように注意して下さい。

インストール済みの不要なサービスアプリケーションは、アンインストールするか、

アクセス制御ファイルを無効化して下さい。 該当するサービス用のアクセス制御ファ

イルのファイル名の先頭に"."を付けてリネームすることで無効化します。

# mv /etc/xinetd.d/[アクセス制御ファイル名] /etc/xinetd.d/.[アクセス制御ファイル名] 例えば、telnetサーバーの無効化は、以下の通りです。 # mv /etc/xinetd.d/telnet /etc/xinetd.d/.telnet 設定の有効化

ここまでの設定を有効にするため、xinetd を起動します。

# /etc/rc.d/init.d/xinetd start Starting xinetd: [ OK ]

すでに起動している場合は、再起動します。

# /etc/rc.d/init.d/xinetd restart Stopping xinetd: [ OK ] Starting xinetd: [ OK ] 稼動しているサービスの確認

稼動しているサービスの確認は、以下のコマンドで行います。

# netstat -a Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 *:ssh *:* LISTEN

raw 0 0 *:icmp *:* 7 raw 0 0 *:tcp *:* 7 Active UNIX domain sockets (servers and established) Proto RefCnt Flags Type State I-Node Path unix 0 [ ] STREAM CONNECTED 204 @0000001c unix 0 [ ACC ] STREAM LISTENING 852 /tmp/.font-unix/fs7100 unix 2 [ ] DGRAM 424 /dev/log unix 0 [ ] DGRAM 2985 unix 0 [ ] DGRAM 439

稼動してはならないサービスが見つかった場合は、 アクセス制御ファイルを無効

化して、xinetd を再起動してから、再度確認をして下さい。 また、稼動しなければなら

ないサービスが見つからない場合も、 アクセス制御ファイルを有効化した後に xinetd

を再起動し、 再度確認を行ってください。

(2) inetdと TCP Wrapperによるサービスへのアクセス制御

RedHat Linux 7.0 から xinetd が標準のスーパーサーバーとなりましたが、 今のとこ

ろ、inetd を利用しているケースが多いようです。

しかし、inetd だけではアクセス制御ができないため、 セキュリティ面では不安が残

ります。

これを補うために TCP Wrapper を併用することで、アクセス制御が可能となります。

ここでは、inetd と TCP Wrpaaer をスーパーサーバとして利用する場合の設定につい

て説明します。

inetdのインストール

inetd は、RedHat Linux 7.0 から標準搭載でなくなったため、 該当する RPM パッケ

ージもインストール CD には存在しません。 よって、RedHat 社のダウンロードページ

から、inetd の入った RPM パッケージである"netkit-base 0.10-34"をダウンロードしま

す。

netkit-base-0.10-34 package information http://www.redhat.com/swr/i386/netkit-base-0.10-34.i386.html

ただし、この RPMパッケージには、pingプログラムも含まれており、 システムにインストール済みの ping プログラムと衝突してしまうため、 普通にインストールはできません。 pingプログラムをバックアップした後、強制インストールで pingを上書きし、 pingプログラムをバックアップから戻す等の工夫をして下さい。

"netkit-base 0.10-34"の強制インストールは、 以下のコマンドで実行します。 # rpm -Uvh --force netkit-base-0_10-34_i386.rpm 設定ファイルのアクセス権変更

inetd の設定は、/etc/inetd.conf によって行われます。 inetd のインストール直後は、

設定ファイルが root 以外のユーザーに読み取り可能となっていますので、 root 以外

のユーザーが読み取れないようにアクセス権を変更します。

# chmod 600 /etc/inetd.conf inetd.confの設定

/etc/inetd.conf は、/etc/services に登録されているサービス(ftp や telnet 等)1 つ

に対して、 1 行のアクセス制御文が対応するように設定します。 "#"が先頭に付いて

いる行のサービスは、無効化されているサービスを表わします。

#echo stream tcp nowait root internal #echo dgram udp wait root internal #discard stream tcp nowait root internal #discard dgram udp wait root internal #daytime stream tcp nowait root internal #daytime dgram udp wait root internal #chargen stream tcp nowait root internal #chargen dgram udp wait root internal #time stream tcp nowait root internal #time dgram udp wait root internal # # These are standard services. # ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd #

# Shell, login, exec, comsat and talk are BSD protocols. # shell stream tcp nowait root /usr/sbin/tcpd in.rshd login stream tcp nowait root /usr/sbin/tcpd in.rlogind ... (省略) ... finger stream tcp nowait nobody /usr/sbin/tcpd in.fingerd #cfinger stream tcp nowait root /usr/sbin/tcpd in.cfingerd #systat stream tcp nowait guest /usr/sbin/tcpd /bin/ps -auwwx #netstat stream tcp nowait guest /usr/sbin/tcpd /bin/netstat -f inet # # Authentication # auth stream tcp nowait nobody /usr/sbin/in.identd in.identd -l -e -o # # End of inetd.conf

不要なサービスであるにも関わらず、 有効になっている("#'"が付いていない) 場

合は、 "#"を行の先頭に追加するか行を削除し、サービスを無効にして下さい。

設定の有効化

ここまでの設定を有効にするため、inetd を起動します。

# /etc/rc.d/init.d/inet start

すでに起動している場合は、再起動します。

# /etc/rc.d/init.d/inet restart 稼動しているサービスの確認

稼動しているサービスの確認は、xinetd と同じです。

tcp_wrapperによるアクセス制御

セキュリティ確保のためのソフトウェアに tcp_wrapper があります。

tcp_wrapper は、元々inetd から起動されるものに対して有効でしたが、 現在では

/etc/rc 等から起動されるデーモンに対しても、ライブラリを 1 つリンクさせるだけで有

効になっています。FreeBSD では、インストール時のアプリケーションは既に

tcp_wrapper による制御が可能になっています。

tcp_wrapper によって、特定のホストやネットワーク以外からの接続をサービスごと

に許可や不許可の設定が行えます。そして、この制御を行う部分が、

/etc/hosts.allow です。 インストール直後の hosts.allow は何も設定されていません。

それでは実際にアクセス制限の設定を行ってみましょう。tcp_wrapper の構文は従

来と同じです。

サービス名:ホスト:allow(許可) または deny(不許可) たとえば、telnetを 192.168.0.0/24の範囲以外を禁止する場合は次のように記述します。

in.telnetd:192.168.0.0/255.255.255.0:allow

これで、192.168.0.0/24 の以外からの telnet 要求は拒否されます。 もし、

192.168.0.0/24 だけでなく、ipa-sec.com のネットワークアドレスを指定するには次のよ

うに記述します。

in.telnetd : 192.168.0.0/255.255.255.0 : allow in.telnetd : 172.16.0.0/255.255.0.0 : allow

もし、これら 2 つのネットワークに加えて、10.1.1.1/8 という特定のホストを加えたいの

であれば、同様に記述します。

また、この時は、一行に一定義だけではなく、カンマで区切ることもできます。

in.telnetd : 192.168.0.0/255.255.255.0 : allow in.telnetd : 172.16.0.0/255.255.0.0,10.1.1.1/255.0.0.0 : allow

もし、アクセス不許可の設定になっているホストやサービスに対して接続されてきた場

合、tcp_wrapper は/var/log/messages にその事実を記述します。

よって、管理者は/var/log/messages の監視を行う必要があります。

アクセス不許可の通知

管理者は/var/log/messages の監視を行う場合、 24 時間見張っているわけにもい

きません。 また、一日一回などの参照では何か重大な事実が発生したときに対処が

遅れることが考えられます。

/etc/hosts.allow のデフォルトで設定されているものの中に次のような定義がある

ことにお気づきでしょう。

初の定義は、アクセス不許可の設定に引っかかった相手に対して finger を送り、

その結果をメールで root 宛に送信している部分です。

次の定義は、アクセス不許可の設定に引っかかった相手に対して何らかのメッセー

ジを送るときに使用します。

これによって、許可されていないホストから telnet を行うと "You are not welcome

to use ドメイン名 from ホスト名." というメッセージを表示して切断します。

tcp_wrapperによって接続を許可されずに切断されるときの処理

fingerd : ALL ¥ : spawn (echo Finger. | ¥ /usr/bin/mail -s "tcpd¥: %u@%h[%a] fingered me!" root) & ¥ : deny # The rest of the daemons are protected. ALL : ALL ¥ : severity auth.info ¥ : twist /bin/echo "You are not welcome to use %d from %h."

それでは、これをカスタマイズして更に詳しい情報を管理者に送信するようにして

みましょう。

詳細は tcpd の man page に記述されていますが、%d や%h 以外にも使用可能な変

数があります。

許可されていないホストからの接続が行われた際、相手の IP アドレスやホスト名、接

続しようとしたプロセスなどを列挙し管理者宛に送信します。

ここでは、root 宛に送信していますが、たとえば管理を他のドメインの管理者に依

頼しているケースは"ユーザ名@ドメイン名"という通常のメールアドレスも記述できま

すし、管理者と管理者の携帯端末というように複数指定したい場合は","で区切りま

す。

hosts.denyまたは hosts.allowの ALL:ALL部を置き換える

ALL : ALL ¥ : severity auth.info : spawn (/usr/bin/finger -l @%h | ¥ /usr/bin/printf " ¥ client address ¥: %a ¥n ¥ client hostname ¥: %n ¥n ¥ client username ¥: %u ¥n ¥ client info ¥: %c ¥n ¥ server address ¥: %A ¥n ¥ server hostname ¥: %N ¥n ¥ server process ¥: %d ¥n ¥ server info ¥: %s" | ¥ /usr/bin/mail -s "tcpd¥: %u@%h[%a] tried to use %d (denied)" root) & ¥ : twist /bin/echo "You are not welcome to use %d from %h."

inetdを利用する上での注意点

TCP Wrapper との併用により、inetd のセキュリティ面が大分改善されますが、 DoS

に対する脆弱制は依然残ったままです。 DoS への対策としては、xinetd への移行も

考えてみて下さい。

(3) システム起動時に起動するサービスの制限

RedHat Linux 7.0 は、システム起動の際、 /etc/rc.d/以下の"rc[数字].d"というディ

レクトリ内にあるサービス制御スクリプトを実行します。 "rc[数字].d"の数字は、ラン

レベルと呼ばれる、 動作状態のレベルを表わします。

各ランレベルと対応する動作状態、内容は以下の通りです。

表 2.2.5-1 ランレベル

ラン レベ

ル 動作状態 内容

0 システム停止モード システムを停止するときのモード

1 シングルユーザー モード

システムに 1人(root)しかログインできないモード

2 マルチユーザー モード

ネットワークをサポートしない複数ユーザーがログインなモ

ード

3 フルマルチユーザー モード

ネットワークをサポートした複数ユーザーがログインなモー

ド

4 未使用 将来のために予約(使用しない)

5 X Widow GUI モード

X Window Systemを用いてログインを行うモード

6 リブートモード 再起動時のモード

システム起動時にコンソールを起動する場合は、ランレベル 3 のため、

/etc/rc.d/rc3.d/以下が実行されることになります。

システム起動時に X Window を起動する場合は、ランレベル 5 のため、

/etc/rc.d/rc5.d/以下が実行されることになります。

各ランレベル毎のディレクトリ以下にあるサービス制御スクリプトはシンボリックリン

クであり、 実体は/etc/rc.d/init.d/ 以下のサービス制御スクリプトに起動もしくは停

止の指定付きでリンクしています。 シンボリックリンクファイルの先頭に"S"が付いて

いる場合は、起動を行います。

先頭に"K"が付いている場合は、停止を行います。 また、"S"や"K"の後の数字は、

処理順番を表わします。

数字の若い順に起動もしくは停止が実行されます。

ランレベルの変更は、/sbin/telinit で行います。

たとえば、ランレベル 5 に変更する場合は次のように実行します。

# /sbin/telinit 5 システム起動時のサービスの無効化

/etc/rc.d/init.d/以下にある、サービス制御スクリプトの実体を無効化すると、 各ラ

ンレベル毎のディレクトリ以下にあるシンボリックリンクも無効になり、 システム起動

時に実行されなくなります。

これを利用して、システム起動時のサービスの無効化を行います。

無効にしたいサービス制御スクリプトのファイル名の先頭に "."を付けてリネームし

て下さい。

# mv /etc/rc.d/init.d/[サービス制御スクリプト名] /etc/rc.d/init.d/.[サービス制御スクリプト名] 例えば、FreeWnnを無効にする場合は、以下のコマンドを実行します。 # mv /etc/rc.d/init.d/FreeWnn /etc/rc.d/init.d/.FreeWnn 設定の有効化

ここまでの設定を有効にするため、システムを再起動します。 以下のコマンドを実

行すると、システムの再起動に入ります。 作業中のファイル等を保存してから、シス

テムの再起動を実行して下さい。

# reboot 稼動しているサービスの確認

稼動しているサービスの確認は、以下のコマンドで行います。

# ps -aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.1 1292 116 ? S Feb21 0:05 init [3] root 2 0.0 0.0 0 0 ? SW Feb21 0:00 [kflushd] root 3 0.0 0.0 0 0 ? SW Feb21 0:00 [kupdate] root 4 0.0 0.0 0 0 ? SW Feb21 0:00 [kpiod]

root 5 0.0 0.0 0 0 ? SW Feb21 0:00 [kswapd] root 6 0.0 0.0 0 0 ? SW< Feb21 0:00 [mdrecoveryd] root 59 0.0 0.0 0 0 ? SW Feb21 0:00 [khubd] root 400 0.0 0.3 1352 208 ? S Feb21 0:01 syslogd -m 0 root 410 0.0 0.2 1608 172 ? S Feb21 0:00 klogd root 516 0.0 0.0 1264 0 tty3 SW Feb21 0:00 [mingetty] root 517 0.0 0.0 1264 0 tty4 SW Feb21 0:00 [mingetty] root 518 0.0 0.0 1264 0 tty5 SW Feb21 0:00 [mingetty] root 519 0.0 0.0 1264 0 tty6 SW Feb21 0:00 [mingetty] root 637 0.0 0.0 1264 0 tty2 SW Feb23 0:00 [mingetty] xfs 933 0.0 5.2 7664 3336 ? S Feb23 1:11 xfs -droppriv -da root 2914 0.0 1.7 2232 1092 tty1 S 19:41 0:00 login -- root root 2915 0.0 2.0 2324 1332 tty1 S 19:41 0:00 -bash root 3007 0.0 1.7 2428 1136 ? S 19:52 0:00 /usr/sbin/sshd root 3012 0.0 2.7 3116 1744 ? S 19:52 0:00 /usr/sbin/sshd rima 3013 0.0 1.9 2252 1256 pts/0 S 19:52 0:00 -bash root 3039 0.0 1.5 2568 1016 pts/0 S 19:53 0:00 su root 3040 0.0 2.1 2772 1392 pts/0 S 19:53 0:00 bash root 3061 0.0 1.3 2708 848 pts/0 R 20:00 0:00 ps -aux

稼動してはならないサービスが見つかった場合は、 システム起動時のサービスを

無効化して、システムを再起動してから、 再度確認をして下さい。

また、稼動しなければならないサービスが見つからない場合は、 システム起動時

のサービスを有効化して、システムを再起動してから、 再度確認をして下さい。

2.2.6 ローカルリソースへのアクセス制限

通常、上記で説明したセキュリティ設定により、 リモートからのアクセスが制限され

れば、 ローカルリソースのセキュリティを気にする必要はほとんどなくなるはずです。

しかし、外部に公開しているサービス対して攻撃を仕掛けられた場合、 そしてその

サービスにセキュリティホールが存在した場合、 リモートからの侵入を許可してしまう

場合も考えられます。リモートからroot権限で侵入された場合は、 システムは完全に

攻略されている可能性が高いと考えられます。

取りうる対応策としては、システムの再インストールぐらいしかありませんが、 権限

の低いユーザーによる侵入であれば、 ローカルリソースへのアクセス制限を施すこ

とにより、 システム全域の攻略を未然に防衛することは可能です。

(1) 不要な SUIDビットの除去

root が所有者である SUID ビットがセットされた実行ファイルやディレクトリは、 プロ

グラムのバグや設定ミスを利用したアタック、 あるいはシンボリックリンクを利用した

アタックにより、 真っ先に攻撃対象として狙われます。そのため、必要がない限りは、

ファイルおよびディレクトリから SUID ビットは除去すべきです。

SUID ビットがセットされているファイルを検索するには、 以下のコマンドを実行しま

す。

# find / ¥( -perm -4000 ¥) -exec ls -lad {} ¥; -rwsr-xr-x 1 root root 36284 Feb 16 2001 /usr/bin/chage -rwsr-xr-x 1 root root 38304 Feb 16 2001 /usr/bin/gpasswd -rwsr-xr-x 1 root root 593008 Jun 27 2001 /usr/bin/gpg -rws--x--x 1 root root 14328 Feb 21 2001 /usr/bin/chfn -rws--x--x 1 root root 13912 Feb 21 2001 /usr/bin/chsh -rws--x--x 1 root root 5688 Feb 21 2001 /usr/bin/newgrp -rwsr-xr-x 1 root root 37316 Jan 24 2002 /usr/bin/at -rwsr-x--- 1 root floppy 17916 Feb 19 2001 /usr/bin/fdmount -rwsr-xr-x 1 root root 239120 Jul 1 21:14 /usr/bin/ssh -r-s--x--x 1 root root 12848 Feb 16 2001 /usr/bin/passwd -rwsr-xr-x 1 root root 15492 Feb 19 2001 /usr/bin/rcp

-rwsr-xr-x 1 root root 11076 Feb 19 2001 /usr/bin/rlogin -rwsr-xr-x 1 root root 8288 Feb 19 2001 /usr/bin/rsh -rwsr-xr-x 1 root root 236236 Feb 16 2001 /usr/bin/screen -rwsr-xr-x 1 root root 21908 Feb 16 2001 /usr/bin/crontab ... (省略)

ここで検索されたファイルやディレクトリで所有者が root に設定されているものが

あれば、 root 権限を乗っ取られる危険性があり、セキュリティ面において望ましくあり

ません。 できる限り、SUID ビットを除去して下さい。

逆に、SUID ビットを除去すると、悪影響が発生するファイルには、 以下のようなファイ

ルがあります。

表 2.2.6-1 SUIDビットを除去してはいけないファイル例

ファイル名 役割

/usr/bin/passwd パスワードの変更

/bin/su 別ユーザでの実行

その他にも、SUID ビットが必須のファイルが存在します。 SUID ビットを除去する場

合は、注意して下さい。

(2) 設定ファイルのアクセス権

以下に挙げる設定ファイルおよびディレクトリは、 root 以外のユーザーに読み取り

可能となっていますが、 root のみ読み書きできるように設定した方が安全です。

表 2.2.6-2 アクセス権を変更した方が良いファイル例

ファイル名 役割

/etc/lilo.conf LILOの設定ファイル

/etc/inittab システム起動に関する設定ファイル

/etc/fstab 起動時にマウントするボリュームの設定ファイル

/etc/rc.d/ システム起動時に実行されるスクリプトの設定ファイルが入ったディレクト

リ

root 以外のユーザーが読み取れないようにするには、 以下のようにアクセス権を

変更して下さい。

# chmod 600 /etc/lilo.conf # chmod 600 /etc/inittab # chmod 600 /etc/fstab # chmod -R 700 /etc/rc.d/

2.2.7 ログの確認

日頃からログの確認を行うことは非常に重要です。 しかし、ログを過信することは

禁物です。

この 2 つは相反することのようですが、実は密接な関係があります。

DoS などの攻撃においてはログの確認を行うことが必要になります。 しかし、もし

侵入された場合はどうでしょうか。侵入する側の立場で考えてみると答えは明瞭です。

もし管理者権限を取得し侵入に成功した場合、 侵入者が 後に行うことはログの削

除です。

侵入先に対して侵入したことを知られるまでの時間をできるかぎり延ばしたい場合、

その足跡を消しておくことを行うでしょう。

しかし、ログの存在はセキュリティにおいて重要なものになります。

ログを見るときに確認しておくべきことがいくつかあります。 それは正しいログであ

ることです。

たとえば、一日一度や一週間に一度など定期的にログを保存し次のログを新規で

作成する運用を行うサイトは少なくありません。 もし、この運用を行っている場合、数

日間を通してログの大きさに極端な変化はありません。 たとえば、これまで一日に

1MB のログファイルが抽出されていたのにもかかわらず、 今日になって 100KB にな

ったなどです。

確認すべきログはいくつかあります。主なものは以下の通りです。

システム全体 /var/log/messages

ユーザのログイン情報 /var/log/wtmp

メールの配送状態 /var/log/maillog

httpd(Apache)の利用状態 /usr/local/apache/logs (設定されたパス)

ftpd(wu-ftpd)の利用状態 /var/log/xferlog (設定されたパス)

2.3 Windows 2000

Microsoft Windows2000 シリーズは、その機能の多さゆえに多くのセキュリティホー

ルを抱えています。しかも、新しく追加された機能だけではなく、いままで一般的に使

用されてきたものに、問題点が潜んでいることも少なくありません。

既に述べてきたとおり、セキュリティホールをゼロにすることは、極めて難しいのが

現状です。しかし、これに対する事前の対策と、新しく問題が発見されたときの迅速な

対応により、その影響を 小限に抑えることが可能になります。

本章では、Windows2000 シリーズに潜むセキュリティ問題に視点をおきながら、 6

つのポイントを紹介いたします。

• 2.3.1 インストール • 2.3.2 セキュリティパッチの適応 • 2.3.3 アカウントのセキュリティ設定 • 2.3.4 パスワードのセキュリティ設定 • 2.3.5 リモートからのアクセス制限 • 2.3.6 リソースへのアクセス制限 • 2.3.7 ログの確認

2.3.1 Windows2000 のインストール

安全なシステムを構築するにあたり、 不要なソフトウェアはインストールしないこと

が望まれます。

セキュリティとは関係ない思われていたものが、 しばらくしてから問題点が浮上表

面化してくると、 結果的にセキュリティホールになってしまいます。 しかし、Windows

をカスタム設定でインストールするには抵抗があるかもしれません。

(1) インストールにおいて

セキュリティ性を高めるために、以下の注意点を必ず実行するようにしてください。

• 不要なソフトウェアは、インストールしないようにしてください。 セキュリティとは関係ない思われていたものが、 しばらくしてから問題点が浮上表面化してくると、 結果的にセキュリティホールになってしまいます。

• ハードディスクは、全て NTFSでフォーマットをするようにします。 NTFSでは、ファイル単位でのアクセス権のしていや、暗号化を行う機能があり、 セキュリティ面を考えると FAT16/FAT32は大変危険です。

• 既存のドライブで、フォーマットができない場合は、 必ず NTFS へコンバートします。 コンバート方法は、リソースへのアクセス制限 で説明しています。

• インストール中で指定する「Administrator」のパスワードは、 類推困難なものを指定してください。 セキュリティ面で効果的なパスワードの指定は、 パスワードの設定 を参照してください。 なお、ここで設定したパスワードを忘れると、 再度Windows 2000 をインストールすることになる場合があります。

(2) Active Directoryの使用

メールの送受信などの管理に、Exchange Server の使用を考えている場合、 サー

バに Active Directory をセットアップする必要があります。

さらに、Active Directory をセットアップするには、 サーバにドメインコントローラを

インストールする必要があります。

サーバをドメインコントローラとすると、ユーザ情報や、 セキュリティポリシーなどの

設定方法が変わります。

下表に、主な変更点を記述します。

項目 インストール前 Active Directory インストール後

ユーザ管理 管理ツールの

[コンピュータの管理]

管理ツールの [Active Directory ユーザとコンピュータ]

ローカル セキュリティ ポリシーの管理

管理ツールの

[ローカル セキュリティ ポリシー]

管理ツールの[ドメインコントローラ セキュリティ ポリシー]

なお、Active Directory をインストールした後で、セキュリティポリシーは、 「ドメイ

ンコントローラ セキュリティ ポリシー」と 「ドメイン セキュリティポリシー」の２つを設

定するようになります。

従来の、「ローカル セキュリティ ポリシー」に該当するのは、 上記表のとおり、

「ドメインコントローラ セキュリティ ポリシー」になります。

2.3.2 セキュリティパッチの適用

(1) セキュリティパッチ

セキュリティパッチとは、リリースされた OS パッケージ製品などで発見された、 セ

キュリティ上の脆弱性に対する、修正モジュールのことをいいます。

ソフトウェアは、通常複数のモジュールから構成されており、 見つかった問題部分

のモジュールに、修正したものを適応することで、 問題解決を行います。

セキュリティパッチには、非定期的にリリースされている Service Pack と、 HotFix

の２種類があります。

Service Pack は、HotFix をまとめたものであり、 多くの問題解決を行うことができ

ます。2001 年 3 月現在では、SP1(Service Pack 1) がリリースされています。

入手方法は、下記のアップデート情報ページからダウンロードするか、 同ページか

ら CD-ROM を注文します。

マイクロソフト Windows2000 アップデート情報

http://www.asia.microsoft.com/japan/windows2000/downloads/

Service Pack に対し、Hot Fixと呼ばれるセキュリティパッチは、 新しく発見されたセキュリティホールに対応するため、頻繁にリリースされます。 セキュリティパッチの暫定版ともいうことができ、発見された脆弱性に対して、 迅速に対応することができます。 よって、私たちは新しいセキュリティホール発見の情報とその対応方法に、 常に耳を傾ける必要があります。

Windows2000の場合、多くの最新情報と、Hot Fixを含めたセキュリティ対策が、 マイク ロ ソ フ ト 社 の ホ ー ム ペ ー ジ か ら 取 得 で き ま す 。

http://www.asia.microsoft.com/japan/technet/security/current.asp

これらをふまえ、セキュリティパッチの適応手順を解説します。

(2) SP1(Service Pack 1)のインストール

まず、起動しているアプリケーションがあれば、すべて終了させておきます。

次に、Windows2000 SP1 のインストーラを使用してインストールを行いますが、

Microsoft 社のホームページからダウンロードしてきた場合は、 そのファイルを実行し

ます。

インストーラが起動されると、 初に表示される上記画面では、 使用許諾契約をよ

く読み、 「同意します」にチェックをつけて「インストール」ボタンを押下します。

その後インストールが始まります。インストールが終わると、 システムを再起動す

る必要があります。

再起動した直後は、管理者権限のあるユーザでログオンします。

つぎに、スタートメニューから[設定] [コントロールパネル] と選択し、 [システム]の

アイコンをダブルクリックします。 そして、表示された「システムのプロパティ」におい

て、 システムの項目に「Service Pack 1」と記述されていることを確認します。

(3) Hot Fix のインストール

セキュリティパッチのインストールは、パッチによって異なる場合があります。 しか

し、ほとんどの場合は、 ダウンロードしてきたファイルを実行するだけでインストール

されます。

ここでは、一般的な手順を説明いたします。

1. 必要なセキュリティパッチを、Microsoft社からダウンロードします。 < このとき、ダウンロードするセキュリティパッチのインストール方法をメモしておきます。

2. 起動されているアプリケーションをすべて終了し、 ダウンロードしたセキュリティパッチを実行します。 ほとんどの場合、Windows2000 のセキュリティパッチは、 ダウンロードしてきたファイルをを直接ダブルクリックすることで、 インストールが実行されます。

3. インストールが終わると、再起動の確認のメッセージが表示されますので、 指示どおり、再起動を行います。

4. 再起動後、一度 Adnimistrator でログオンしてください。 再起動後に、パッチインストールの続きが自動的に行われることがあるためです。

以上で、セキュリティパッチのインストールは完了です。

繰り返しになりますが、セキュリティパッチのインストールは、 パッチによって異な

る場合がありますので、 必ずインストール方法に目を通すようにしてください。

また、マイクロソフト セキュリティ情報にて発表された応策は、 言い換えれば悪意

のあるユーザの情報源にもなります。

よって、サーバを管理する立場においても、常に新しい情報に耳を傾け、 適切か

つ迅速な対策が必要になります。

2.3.3 アカウントのセキュリティ設定

(1) Guest アカウントの無効化

「Guest」アカウントは、デフォルトで無効化されています。念のため下記の手順で確

認してください。

1. 「管理ツール」の「Active Directory ユーザとコンピュータ」を開きます。 2. 「Users」から「Guest」をダブルクリックします。 なお、この時点で下図のように、 「Guest」のアイコンに×マークがついている場合は、 既に無効化されていますので、画面を閉じて作業を終了してください。

3. 「Guest」をダブルクリックすると、 下図のような「Guestのプロパティ」画面が

表示されます。この画面にて、 [アカウント]タグをクリックし、[アカウント オプション]から、 「アカウントは無効」に項目にチェックをつけます。

(2) アカウント名の変更

Windows2000 をインストールするときに、 デフォルトとして「Administrator」や

「Guest」というユーザ名のアカウントなどが、 自動的に登録されています。

攻撃者が、 「Administrator」という名のユーザアカウントを使用した不正アクセスを

試みた場合、 サーバを守っているのはパスワードのみになってしまいます。

そこで、まず Windows2000 において既知のアカウントである [Administrator]と

[Guest]のアカウント名を変更することをおすすめします。 特に「Administrator」のアカ

ウント名を、 管理者権限と関連のない名前に変更することで、不正アクセス対策に

貢献します。

以下は、「Administrator」のアカウント名を変更する場合の手順です。

1. Windowsのスタートメニューから、 [スタート]-[プログラム]-[管理ツール]-[ドメインコントローラ セキュリティ ポリシー]を選択します。

2. 画面から、「セキュリティ オプション」を選択し、その中の「Administrator アカウント名の変更」をダブルクリックします。

3. 「セキュリティ ポリシーの設定」画面から、 [このポリシーの設定を定義する]にチェックをつけ、 変更後のアカウント名を入力します。

4. OKボタンを押下して、画面を閉じます。

以上で、アカウント名の変更は終わりです。「Guest」についても、 「Guest アカウン

ト名の変更」という項目がありますので、 同様に変更を行ってください。

注意事項として、「Administrator」のアカウント名を変更するとき、 管理者であるこ

とが推測されにくいアカウント名に変更してください。

「root」「admin」やマシン名、ドメイン名をアカウント名にすると、 それを推測されや

すく大変危険です。

なお、上記の手順はサーバがドメインコントローラの場合です。 そうでない場合は[ロ

ーカル セキュリティポリシー]にて、変更を行います。

(3) 必要なときだけ管理者権限を使用する

常に管理権限で作業を行っていると、 トロイの木馬やウィルスなどの不正なプログ

ラム実行したとき、 その被害がシステム全体に及ぶ危険性があります。 よって、通

常のサーバへのログオンは、 サーバへのローカル接続を許可した「Domain Users」

グループのアカウントで行い、 必要な場合だけ、管理者権限でプログラムを実行す

ることをお勧めします。

下記に、「Domain Users」グループのユーザアカウントで、 ローカルログオンしたあ

と、管理ツールの「Active Directory ユーザとコンピュータ」 を、管理者権限で実行す

る手順を例に説明いたします。

1. 通常どおり、[スタート]-[プログラム]-[管理ツール]と選択します。 2. 「Shift」キーを押下しながら、[Active Directory ユーザとコンピュータ]を、 マウスの右ボタンで選択します。

3. 表示されたコンテキストメニューから、 [別のユーザとして実行]を選択します。

4. 管理権限のユーザ情報を入力し、OKボタンを押下します。

以上で、指定したユーザとして「Active Directory ユーザとコンピュータ」が実行さ

れます。他のプログラムの場合も、同様の手順で実行します。

また、コマンドプロンプトから行うときには runas コマンドが使用できます。

これも、指定したユーザ名でプログラムを実行することができます。

(4) 新規ユーザの追加

前節にて、サーバへのローカルログオンは「Domain Users」 などのアカウントを使

用し、必要な場合だけ管理者権限で実行する、 という方法を解説しました。

ここではこれをふまえ、ユーザの追加方法を説明します。

1. [スタート]-[プログラム]-[管理ツール]で、 [Active Directory ユーザとコンピュータ]を選択します。

2. 表示された画面から「Users」フォルダを、マウスの右ボタンで選択し、 表示されたコンテキストメニューから、[新規作成]-[User]を選択します。

3. ユーザを作成するための、新規オブジェクト画面が表示されます。 必要なユーザ情報を入力し[次へ]ボタンを押下します。

4. パスワードの初期値を入力し、必要に応じてそれぞれの項目にチェックをつけ、 [次へ]ボタンを押下します。

5. 設定内容を確認し、[完了]ボタンを押下します。

以上で、新規ユーザの登録が完了しました。

なお、サーバーがドメインコントローラでない場合、ユーザグループの設定は、 [管

理ツール]の[コンピュータの管理]にて新規ユーザを作成します。

2.3.4 パスワードのセキュリティ設定

(1) 設定の内容

パスワード自体に制限を設けることで、セキュリティをより強固なものにします。

本書では、次の 7 つの項目を設定します。

• パスワードの長さの制限 • パスワードの有効期間 • パスワードの履歴を記録する • パスワードは要求する複雑さを満たす • アカウントロックアウトのしきい値

• ロックアカウントのリセット • ロックアカウントの期間

それぞれの設定は、Windows のスタートメニュから、 [スタート]-[設定]-[コントロー

ルパネル]で、表示された画面の「管理ツール」 をダブルクリックします。そして、「ロ

ーカル セキュリティ ポリシー」 のアイコンをダブルクリックします。すると、「ローカル

セキュリティ設定」 画面が表示されます。この画面の、「アカウント ポリシー」の設定

に、 上記の項目が含まれています。

ただし、ドメインコントローラを使用する場合、ここで設定する ローカルポリシーより

「ドメインコントローラ セキュリティ ポリシー」が優先されます。

操作はローカルセキュリティポリシーの設定と同様で、Windows のスタートメニュか

ら、 [スタート]-[設定]-[コントロールパネル]で、表示された画面の「管理ツール」 を

ダブルクリックします。そして、「ドメインコントローラ セキュリティポリシー」 のアイコン

をダブルクリックします。

(2) パスワードの長さの制限

パスワードの長さを設定することで、ユーザの設定したパスワードが、 短くて簡単

なものになることを防ぐことができます。特にデフォルトでは、 パスワードの指定を

「なし」とすることが可能なため、 この項目の設定は必須です。

1. ローカル セキュリティ設定画面から、「アカウントポリシー」を選択し、 その中の「パスワードのポリシー」を選択します。

2. パスワードのポリシーの中にある、 「パスワードの長さ」をダブルクリックします。 3. 「ローカル セキュリティ ポリシーの設定」画面が表示されます。 4. ローカルポリシーの設定欄で、制限文字数を指定します。 文字数が多くなればなるほど、セキュリティが厳しくなります。 反対に、長すぎると利用者がパスワードを忘れる可能性があり、 逆効果となるかもしれません。 0を指定すると、パスワードなしを許可することになり非常に危険です。

5. 指定したら、OK ボタンを押下し、「ローカル セキュリティ ポリシーの設定」 画面を閉じます。

6. 設定を反映するために、「ローカル セキュリティ設定」画面を閉じます。

(3) パスワードの有効期間

パスワードの有効期間を指定することで、利用者に対して、 定期的なパスワード

の変更を実施させることができます。

新しいパスワードを常に使うことによって、 パスワード推定による不正アクセスを

未然に防ぐことができます。 ただし、この機能は「パスワードの履歴を記録する」 と

併用することが必須といえます。

1. ローカル セキュリティ設定画面から、「アカウントポリシー」を選択し、 その中の「パスワードのポリシー」を選択します。

2. パスワードのポリシーの中にある、「パスワードの有効期間」 をダブルクリックします。

3. 「ローカル セキュリティ ポリシーの設定」画面が表示されます。 4. ローカルポリシーの設定欄で、有効期限を指定します。 有効期間が短すぎると、利用者がパスワードを忘れる可能性があり、 逆効果となるかもしれません。 また、0を指定すると、パスワードを無期限にすることになり非常に危険です。

5. 指定したら、OK ボタンを押下し、「ローカル セキュリティ ポリシーの設定」 画面を閉じます。

6. 設定を反映するために、「ローカル セキュリティ設定」画面を閉じます。

なお、「ドメイン コントローラ セキュリティ ポリシー (非ドメインコントローラはロー

カルセキュリティポリシー)」にて、 パスワードの期限が切れる前に、 その変更を促す

メッセージを表示することができます。

「セキュリティ オプション」にある、 「パスワードが無効になる前にユーザに変更を

促す」で設定します。

(4) パスワードの履歴を記録する

パスワードの履歴を記録し、同じパスワードを何度も使用することによって、 結果

的に古いパスワードのままになる問題を、回避することができます。

ただし、この機能は「パスワードの有効期間」と併用することが必須といえます。

1. ローカル セキュリティ設定画面から、「アカウントポリシー」を選択し、 その中の「パスワードのポリシー」を選択します。

2. パスワードのポリシーの中にある、 「パスワードの履歴を記録する」をダブルクリックします。

3. 「ローカル セキュリティ ポリシーの設定」画面が表示されます。 4. ローカルポリシーの設定欄で、履歴をとるパスワード数を指定します。 有効期間が短すぎると、利用者がパスワードを忘れる可能性があり、 逆効果となるかもしれません。 また、0を指定すると、パスワードを無期限にすることになり非常に危険です。

5. 指定したら、OK ボタンを押下し、「ローカル セキュリティ ポリシーの設定」 画面を閉じます。

6. 設定を反映するために、「ローカル セキュリティ設定」画面を閉じます。

(5) パスワードは要求した複雑さを満たす

この機能によって、ユーザが設定すパスワードが、 簡単で推測されやすくなる問

題を回避できます。

有効にすると、パスワード文字列中に、数字・大文字・小文字が、 それぞれ 1 字以

上含まれることが必要になります。

1. ローカル セキュリティ設定画面から、「アカウントポリシー」を選択し、 その中の「パスワードのポリシー」を選択します。

2. パスワードのポリシーの中にある、「パスワードは要求した複雑さを満たす」 をダブルクリックします。

3. 「ローカル セキュリティ ポリシーの設定」画面が表示されます。 4. ローカルポリシーの設定欄で、有効を選択します。 5. 指定したら、OK ボタンを押下し、「ローカル セキュリティ ポリシーの設定」 画面を閉じます。

6. 設定を反映するために、「ローカル セキュリティ設定」画面を閉じます。

(6) アカウントロックアウトのしきい値

この機能によって、何度もパスワードを入れてパスワードを推測し、 不法アクセス

が行われることを防ぐことができます。ここで指定する値は、 ログオンに失敗できる

回数です。「ロックアカウントのリセット」 と併用することが望まれます。

1. ローカル セキュリティ設定画面から、「アカウント ポリシー」を選択し、 その中の「アカウント ロックアウトのポリシー」を選択します。

2. アカウント ロックアウトのポリシーの中にある、 「アカウントのロックアウトのしきい値」をダブルクリックします。

3. 「ローカル セキュリティ ポリシーの設定」画面が表示されます。 4. ローカルポリシーの設定欄で、アカウントのロックアウト回数を指定します。 回数が多すぎると、逆効果となるかもしれません。 また、0を指定すると、ロックアウトをしない設定になり非常に危険です。

5. 指定したら、OK ボタンを押下し、「ローカル セキュリティ ポリシーの設定」 画面を閉じます。

6. 設定を反映するために、「ローカル セキュリティ設定」画面を閉じます。

(7) ロックアカウントのリセット

1. ローカル セキュリティ設定画面から、「アカウント ポリシー」を選択し、 その中の「アカウント ロックアウトのポリシー」を選択します。

2. アカウント ロックアウトのポリシーの中にある、「ロックアウトのリセット」 をダブルクリックします。

3. 「ローカル セキュリティ ポリシーの設定」画面が表示されます。 4. ローカルポリシーの設定欄で、 ロックアウトのカウントリセット時間を指定します。 5. 指定したら、OK ボタンを押下し、「ローカル セキュリティ ポリシーの設定」 画面を閉じます。

6. 設定を反映するために、「ローカル セキュリティ設定」画面を閉じます。

(8) ロックアカウントの期間

この機能は、実際にロックアウトを行う期間を指定します。

1. ローカル セキュリティ設定画面から、「アカウント ポリシー」を選択し、 その中の「アカウント ロックアウトのポリシー」を選択します。

2. アカウント ロックアウトのポリシーの中にある、「ロックアカウントの期間」 をダブルクリックします。

3. 「ローカル セキュリティ ポリシーの設定」画面が表示されます。 4. ローカルポリシーの設定欄で、ロックアカウントの期間を指定します。 5. 指定したら、OK ボタンを押下し、「ローカル セキュリティ ポリシーの設定」 画面を閉じます。

6. 設定を反映するために、「ローカル セキュリティ設定」画面を閉じます。

2.3.4 パスワードのセキュリティ設定

(1) 設定の内容

パスワード自体に制限を設けることで、セキュリティをより強固なものにします。

本書では、次の 7 つの項目を設定します。

• パスワードの長さの制限 • パスワードの有効期間 • パスワードの履歴を記録する • パスワードは要求する複雑さを満たす • アカウントロックアウトのしきい値 • ロックアカウントのリセット

• ロックアカウントの期間

それぞれの設定は、Windows のスタートメニュから、 [スタート]-[設定]-[コントロー

ルパネル]で、表示された画面の「管理ツール」 をダブルクリックします。そして、「ロ

ーカル セキュリティ ポリシー」 のアイコンをダブルクリックします。すると、「ローカル

セキュリティ設定」 画面が表示されます。この画面の、「アカウント ポリシー」の設定

に、 上記の項目が含まれています。

ただし、ドメインコントローラを使用する場合、ここで設定する ローカルポリシーより

「ドメインコントローラ セキュリティ ポリシー」が優先されます。

操作はローカルセキュリティポリシーの設定と同様で、Windows のスタートメニュか

ら、 [スタート]-[設定]-[コントロールパネル]で、表示された画面の「管理ツール」 を

ダブルクリックします。そして、「ドメインコントローラ セキュリティポリシー」 のアイコン

をダブルクリックします。

(2) パスワードの長さの制限

パスワードの長さを設定することで、ユーザの設定したパスワードが、 短くて簡単

なものになることを防ぐことができます。特にデフォルトでは、 パスワードの指定を

「なし」とすることが可能なため、 この項目の設定は必須です。

7. ローカル セキュリティ設定画面から、「アカウントポリシー」を選択し、 その中の「パスワードのポリシー」を選択します。

8. パスワードのポリシーの中にある、 「パスワードの長さ」をダブルクリックします。 9. 「ローカル セキュリティ ポリシーの設定」画面が表示されます。 10. ローカルポリシーの設定欄で、制限文字数を指定します。 文字数が多くなればなるほど、セキュリティが厳しくなります。 反対に、長すぎると利用者がパスワードを忘れる可能性があり、 逆効果となるかもしれません。 0を指定すると、パスワードなしを許可することになり非常に危険です。

11. 指定したら、OK ボタンを押下し、「ローカル セキュリティ ポリシーの設定」 画面を閉じます。

12. 設定を反映するために、「ローカル セキュリティ設定」画面を閉じます。

(3) パスワードの有効期間

パスワードの有効期間を指定することで、利用者に対して、 定期的なパスワード

の変更を実施させることができます。

新しいパスワードを常に使うことによって、 パスワード推定による不正アクセスを

未然に防ぐことができます。 ただし、この機能は「パスワードの履歴を記録する」 と

併用することが必須といえます。

7. ローカル セキュリティ設定画面から、「アカウントポリシー」を選択し、 その中の「パスワードのポリシー」を選択します。

8. パスワードのポリシーの中にある、「パスワードの有効期間」 をダブルクリックします。

9. 「ローカル セキュリティ ポリシーの設定」画面が表示されます。 10. ローカルポリシーの設定欄で、有効期限を指定します。 有効期間が短すぎると、利用者がパスワードを忘れる可能性があり、 逆効果となるかもしれません。 また、0を指定すると、パスワードを無期限にすることになり非常に危険です。

11. 指定したら、OK ボタンを押下し、「ローカル セキュリティ ポリシーの設定」 画面を閉じます。

12. 設定を反映するために、「ローカル セキュリティ設定」画面を閉じます。

なお、「ドメイン コントローラ セキュリティ ポリシー (非ドメインコントローラはロー

カルセキュリティポリシー)」にて、 パスワードの期限が切れる前に、 その変更を促す

メッセージを表示することができます。

「セキュリティ オプション」にある、 「パスワードが無効になる前にユーザに変更を

促す」で設定します。

(4) パスワードの履歴を記録する

パスワードの履歴を記録し、同じパスワードを何度も使用することによって、 結果

的に古いパスワードのままになる問題を、回避することができます。

ただし、この機能は「パスワードの有効期間」と併用することが必須といえます。

7. ローカル セキュリティ設定画面から、「アカウントポリシー」を選択し、 その中の「パスワードのポリシー」を選択します。

8. パスワードのポリシーの中にある、 「パスワードの履歴を記録する」をダブルクリックします。

9. 「ローカル セキュリティ ポリシーの設定」画面が表示されます。 10. ローカルポリシーの設定欄で、履歴をとるパスワード数を指定します。 有効期間が短すぎると、利用者がパスワードを忘れる可能性があり、 逆効果となるかもしれません。 また、0を指定すると、パスワードを無期限にすることになり非常に危険です。

11. 指定したら、OK ボタンを押下し、「ローカル セキュリティ ポリシーの設定」 画面を閉じます。

12. 設定を反映するために、「ローカル セキュリティ設定」画面を閉じます。

(5) パスワードは要求した複雑さを満たす

この機能によって、ユーザが設定すパスワードが、 簡単で推測されやすくなる問

題を回避できます。

有効にすると、パスワード文字列中に、数字・大文字・小文字が、 それぞれ 1 字以

上含まれることが必要になります。

7. ローカル セキュリティ設定画面から、「アカウントポリシー」を選択し、 その中の「パスワードのポリシー」を選択します。

8. パスワードのポリシーの中にある、「パスワードは要求した複雑さを満たす」 をダブルクリックします。

9. 「ローカル セキュリティ ポリシーの設定」画面が表示されます。 10. ローカルポリシーの設定欄で、有効を選択します。 11. 指定したら、OK ボタンを押下し、「ローカル セキュリティ ポリシーの設定」 画面を閉じます。

12. 設定を反映するために、「ローカル セキュリティ設定」画面を閉じます。

(6) アカウントロックアウトのしきい値

この機能によって、何度もパスワードを入れてパスワードを推測し、 不法アクセス

が行われることを防ぐことができます。ここで指定する値は、 ログオンに失敗できる

回数です。「ロックアカウントのリセット」 と併用することが望まれます。

7. ローカル セキュリティ設定画面から、「アカウント ポリシー」を選択し、 その中の「アカウント ロックアウトのポリシー」を選択します。

8. アカウント ロックアウトのポリシーの中にある、 「アカウントのロックアウトのしきい値」をダブルクリックします。

9. 「ローカル セキュリティ ポリシーの設定」画面が表示されます。 10. ローカルポリシーの設定欄で、アカウントのロックアウト回数を指定します。 回数が多すぎると、逆効果となるかもしれません。 また、0を指定すると、ロックアウトをしない設定になり非常に危険です。

11. 指定したら、OK ボタンを押下し、「ローカル セキュリティ ポリシーの設定」 画面を閉じます。

12. 設定を反映するために、「ローカル セキュリティ設定」画面を閉じます。

(7) ロックアカウントのリセット

7. ローカル セキュリティ設定画面から、「アカウント ポリシー」を選択し、 その中の「アカウント ロックアウトのポリシー」を選択します。

8. アカウント ロックアウトのポリシーの中にある、「ロックアウトのリセット」 をダブルクリックします。

9. 「ローカル セキュリティ ポリシーの設定」画面が表示されます。 10. ローカルポリシーの設定欄で、 ロックアウトのカウントリセット時間を指定します。 11. 指定したら、OK ボタンを押下し、「ローカル セキュリティ ポリシーの設定」 画面を閉じます。

12. 設定を反映するために、「ローカル セキュリティ設定」画面を閉じます。

(8) ロックアカウントの期間

この機能は、実際にロックアウトを行う期間を指定します。

7. ローカル セキュリティ設定画面から、「アカウント ポリシー」を選択し、 その中の「アカウント ロックアウトのポリシー」を選択します。

8. アカウント ロックアウトのポリシーの中にある、「ロックアカウントの期間」 をダブルクリックします。

9. 「ローカル セキュリティ ポリシーの設定」画面が表示されます。 10. ローカルポリシーの設定欄で、ロックアカウントの期間を指定します。 11. 指定したら、OK ボタンを押下し、「ローカル セキュリティ ポリシーの設定」 画面を閉じます。

12. 設定を反映するために、「ローカル セキュリティ設定」画面を閉じます。

2.3.5 リモートからのアクセス制限

(1) サービスへのアクセス制限

Windows2000 のインストールによって、普段使用しないようなサービスが起動し、未

使用のポートアドレスが開いたままになっている場合があります。

攻撃者はこれを利用して、不正アクセスを試みる場合があります。

ここでは、Routing and Remote Access サービスを使用して、 パケットフィルタリン

グを行い、必要なポートだけを開放する設定を行います。

一つ注意として、下記の説明では「下の条件に一致するパケットを除いたすべての

パケットを破棄する」を選択しており、指定されたフィルタ以外を拒否します。よってセ

キュリティレベルは、フィルタの項目が多いほど低くなり、少ないほど高くなります。フ

ィルタで指定されたものを拒否する場合は、「下の条件に一致するパケットを除いた

全てのパケットを受信する」を選択してください。

1. Windows のスタートメニューから、 [スタート]-[設定]-[コントロールパネル]を選択し、 表示された「コントロールパネル」から「管理ツール」をダブルクリックします。

2. 管理ツール画面から「ルーティングとリモート アクセス」 をダブルクリックします。

3. 「ルーティングとリモート アクセス」画面が表示されます。 4. 左側のツリーコントロールから、サーバ名のアイコン(「IPA(ローカル)」など)を、 マウスの右ボタンで選択し、 表示されたコンテキストメニューから [ルーティングとリモート アクセスの構成と有効化]を選択します。

5. 「ルーティングとリモート アクセス サーバのセットアップウィザード」 画面が表示されますので、[次へ]を押下します。

6. 「標準的な構成」の選択肢から、「手動で構成したサーバ」を選択し、 [次へ]ボタンを押下します。

7. [完了]を押下して、セットアップウィザードを終了します。 8. 「サービスを開始しますか？」の確認メッセージでは、[はい]を押下します。 9. 「ルーティングとリモート アクセス」画面に戻り、 左側のツリーコントロールから、「IPA(ローカル)」の中の「IPルーティング」 を選択します。

10. さらに「全般」選択します。

11. インターネット側にあたる、インタフェース(この例では、ローカル接続 2)を、 マウスの右ボタンで選択し、表示されたコンテキストメニューから、 [プロパティ]を選択します。

12. 表示された「ローカル エリア接続 2 のプロパティ」画面より、 [入力フィルタ]ボタンを押下します。 すると、[入力フィルタ]画面が表示されます。

13. 表示された画面にて、許可するフィルタ情報を入力します。 ここでは例として、HTTP接続を許可するための、以下の内容を入力します。

発信元ネットワーク 宛先ネットワーク

対象 チェック

の有無 IP

サブネット

マスク

チェック

の有無 IP

サブネット

マスク

プロトコル

発信元ポート 0 HTTP

（Input） 無 - - 有

インターネット

側

IPアドレス

255.255.255.255 TCP 宛先ポート 80

14. [OK]ボタンを押下し、「入力フィルタ」画面に戻ります。 「フィルタ」一覧に追加されていることを確認します。

15. [下の条件に一致するパケットを除いたすべてのパケットを破棄する]を選択し、 OKボタンを押下します。

16. プロパティ画面に戻り、さらに[出力フィルタ]ボタンを押下して、 「出力フィルタ」を設定します。 ここでは例として、HTTP 接続を許可するための、 以下の出力フィルタを設定します。 そして、「下の条件に一致するパケットを除いたすべてのパケットを破棄する」 を選択します。設定方法は、入力フィルタと変わりません。

発信元ネットワーク 宛先ネットワーク

対象 チェック

の有無 IP

サブネット

マスク

チェック

の有無IP

サブネット

マスク

プロトコル

発信元ポート 80HTTP(Output) 有

インターネット側

IPアドレス 255.255.255.255 無 - - TCP

宛先ポート 0

17. フィルタの設定を終え、プロパティ画面に戻りましたら、OKボタンを押下し、 設定を反映させます。

以上で、パケットフィルタの設定が終わりました。

なお、ここまでの説明では、 イントラネット側のパケットフィルタの設定は行っていま

せん。 必要に応じて、同様の手順で設定してください。

上記の例では、HTTP 接続のみの許可しか行っていません。 小規模サイトで使用し

ていると思われる以下のサービスについて、 入力フィルタと出力フィルタをまとめて

おきます。

• DNS • HTTP(Webサーバ) • SMTP • SSH • SSL

もちろん、これ以外のサービスを使用する場合は、 それぞれに必要なフィルタを作成

し、接続を許可するようにしてください。

• 入力フィルタ

発信元ネットワーク 宛先ネットワーク

対象 チェック

の有無 IP サブネット

マスク チェック

の有無IPアドレス

サブネット マスク

プロトコル

発信元ポート 0DNS(Input) 無 - - 有

インターネット側 IPアドレス

255.255.255.255 TCP 宛先ポート 53

発信元ポート 0HTTP（Input） 無 - - 有

インターネット側 IPアドレス

255.255.255.255 TCP 宛先ポート 80

発信元ポート 0SMTP(Input) 無 - - 有

インターネット側 IPアドレス

255.255.255.255 TCP 宛先ポート 25

発信元ポート 0SSH(Input) 無 - - 有

インターネット側 IPアドレス

255.255.255.255 TCP 宛先ポート 22

発信元ポート 0SSL(Input) 無 - - 有

インターネット側 IPアドレス

255.255.255.255 TCP 宛先ポート 443

• 出力フィルタ

発信元ネットワーク 宛先ネットワーク

対象 チェック の有無

IP サブネット マスク

チェックの有無 IPサブネット

マスク

プロトコル

発信元ポート 53DNS(Output) 有

インターネット側

IPアドレス 255.255.255.255 無 - - TCP

宛先ポート 0

発信元ポート 80HTTP(Output) 有

インターネット側

IPアドレス 255.255.255.255 無 - - TCP

宛先ポート 0

発信元ポート 25SMTP(Output) 有

インターネット側

IPアドレス 255.255.255.255 無 - - TCP

宛先ポート 0

発信元ポート 22SSH(Output) 有

インターネット側

IPアドレス 255.255.255.255 無 - - TCP

宛先ポート 0

発信元ポート 443 SSL(Output) 有

インターネット側

IPアドレス 255.255.255.255 無 - - TCP

宛先ポート 0

なお、必要に応じたフィルタ設定が必要ですが、 NetBIOS ポート(TCP および UDP

ポートの 135～139)は、 絶対に公開しないようにしてください。

後述の「null 接続」によって、ユーザ情報などが漏洩する可能性があります。 (ただ

し、イントラネット(内部 LAN)環境向けには、 このポートを開放してやる必要もありま

す。)

また、繰り返しになりますが、 「下の条件に一致するパケットを除いた全てのパケ

ットを受信する」と 「下の条件に一致するパケットを除いたすべてのパケットを破棄す

る」 の選択を間違えないようにしてください。意味が反対になるため、 思わぬ損害に

つながる恐れがあります。

さらに、この設定を行った後は、できる限り通信テストを行うことをおすすめします。

設定内容が複雑であることに加え、 サービスによってはポートを複数使用する場合

もあるため、 思わぬ機能が使用できなくなることも考えられます。

後になりますが、IP フィルタリングを行っても、公開されているポートを使用して、

悪意のあるユーザが攻撃を試みるかもしれません。 特に、セキュリティ ホール が

見つかった場合などは、 この弱点をついた攻撃を受けるかもしれません。よって、日

ごろのサーバ管理と、 セキュリティ情報のチェックが必要です。

(2) null(ヌル)接続の制限

null(ヌル)接続とは、ユーザ名とパスワードが空(null)の状態でサーバなどに接続を

行うことをいい、Windows 特有の問題です。

しかも、null 接続そのものは非常に簡単です。悪意のあるユーザは、この方法でサ

ーバに接続した後、さまざまなテクニックを使って、ネットワーク情報、共有、ユーザ、

グループ、レジストリなど、可能な限りの情報を収集しようと試みます。「レッドボタン」

問題、null セッション接続、匿名ログオンなどとも呼ばれ、侵入者が使用する も脅威

的な手段の 1 つとなっています。

Windows 2000 では、この接続に対する制限を行う機能を持っています。

以下に説明するレジストリの変更によって、この方法による情報漏洩の大部分を防

ぐことができます。

1. Windows のスタートメニューから [ファイル名を指定して実行 ]を選び、 「rededt32.exe」と入力して、OKボタンを押下します。

2. レジストリエディッタが表示されます。 3. レ ジ ス ト リ か ら 、

「HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥Control¥LSA」を選択します。

4. 「restrictanonymous」をダブルクリックし、 データの欄に「1」を設定します。

5. レジストリエディッタを終了し、マシンを再起動します。

この設定は、null 接続による動作を制限しているだけで、接続は可能です。

しかも、この制限をしているにもかかわらず、ある特定のツールを使用した、 ユー

ザとグループ情報の取得方法が知られています。 もちろん、この問題も他の対策と

組み合わせることで解決できます。 (前述の、Routing and Remote Accerss によるパ

ケットフィルタリングなど)

2.3.6 リソースへのアクセス制限

(1) ファイルシステム

Widows2000 インストールでも触れましたが、 ファイルシステムは NTFS を使用する

ようにしてください。

NTFS を使用しないと、ファイルのセキュリティ設定ができないため、大変危険です。

万一、FAT16/FAT32 のパーティションがある場合は、以下の手順で NTFS にコンバー

トできます。

ここでは、「ローカルディスク(D:)」が FAT32 であり、 これを NTFS に変換する作業を

例として説明します。

1. 起動中のアプリケーションをすべて終了します。 2. あらかじめ、大事なデータはすべてバックアップしておきます。 3. Windowsのスタートメニューで、 [スタート]-[ファイル名を指定して実行...]を選択します。

4. 表示された「ファイル名を指定して実行」画面の、 名前の欄に「convert d: /FS:NTFS」と入力し、OKボタンを押下します。

5. 下記のメッセージが表示されるので、「Y」を入力し ENTERを押下します。

ファイル システムの種類は FAT32です。 CONVERT で D: ドライブへの排他的アクセスを実行できないため、 現時点では変換できません。次回のシステム再起動時にドライブの変換を スケジュールしますか (Y/N)?

6. 画面が自動的に閉じます。(閉じない場合は、「次回のシステム再起動時に、 変換は自動的に実行されます。」というメッセージを確認後、画面を閉じます。)

7. システムを再起動します。 8. 起動時に下図のような画面が表示され、コンバート処理が行われます。 9. コンバート処理が完了すると自動的に再起動されます。 10. 再び Windows2000 が立ち上がりましたら、「ローカルディスク(D:)」 のプロパティにて、NTFSに変換されたことを確認します。

もし、ほかのドライブ「F:」などをコンバートする場合は、 手順 4 で「convert f:

/FS:NTFS」と入力します。

このように、「convert」の後ろにスペースをいれ、変換するドライブ名を指定します。

(2) ファイルシステムへのセキュリティ設定

Windows2000では、ユーザやグループに対しフォルダ単位のアクセス権を指定する

ことができます。

しかし、Windows2000 をインストールした時点では、 ユーザに関係なくローカルディ

スク内のファイルにアクセスできてしまいます。

ここでは、Web コンテンツの改竄を防ぐための、 「c:\InetPub\wwwroot」へのアクセ

ス権の設定方法を例に説明します。

1. エクスプローラを開きます。 2. セキュリティを指定するフォルダ「c:¥InetPub¥wwwroot」を開きます。 3. エクスプローラのメニューから、[ファイル]-[プロパティ]を選択します。 4. 表示された「wwwroot のプロパティ」画面にて、 「セキュリティ」タグをクリックします。

o ここでの問題点は、Everyoneがすでに設定され、 しかもフルコントロールになっていることです。

5. 「追加」ボタンを押下して、「ユーザ、コンピュータ、または グループ選択」 画面を表示させます。

6. 次表のグループ、ユーザを選択し選択し追加ボタンを押下し、 以下のアクセス権限を与えます。

名前 アクセス許可

(チェックされた許可項目) 備考

Administrators フルコントロール 公開用フォルダの管理と、コンテンツそのものの更新を行

います。コンテンツの変更者とフォルダの管理者が異なる

場合など、必要に応じてユーザを追加し、それぞれ設定し

てください。

SYSTEM フルコントロール Windowsがアクセスするために必要です。

Authenticated Users 読み取りと実行

フォルダの内容の一覧表示

読み取り

「Authenticated Users」は、「Everyone」グループとほぼ

同等です。よって、匿名アクセス用のWindows ユーザ ア

カウント以外も含まれます。より厳しいセキュリティ設定

としては、匿名アクセス用のアカウントのみを設定しま

す。

7. 「継承可能なアクセス許可を親からこのオブジェクトに継承できるようにする」 のチェックをはずします。

o 以下のようなメッセージボックスが表示されますが、 「削除」を選択します。

o 通常、このチェックは「オン」でも問題ありませんが、 親フォルダのセキュリティが変更された場合、 このフォルダにもそれが影響します。場合によっては、 これが問題となる場合があるので、チェックを外すこととします。

8. 詳細ボタンを押下し、「wwwrootのアクセス制御の設定」画面を表示します。 9. wwwroot 以下のすべてのフォルダに設定を継承させるため、 「すべての子オブジェクトのアクセス許可を元に戻し、 継承可能なアクセス許可を継承できるようにする」にチェックをつけ、 OKボタンを押下します。この作業は必須ではありません。 特に、既にアクセス件の設定が行われているフォルダがある場合、 その設定を上書きしてしまいますので、注意してください。

10. 次のようなメッセージが表示されますので、「はい」を押下します。

11. プロパティ画面に戻りましたら、OKボタンを押下して画面を閉じます。

以上の設定で、「Administrators」権限を持っていないと、 c:\InetPub\wwwroot 内

のファイルを変更できなくなりました。

「Authenticated Users」グループのユーザは、 ファイルを書き込むことができない

ため、 勝手にデータが書き変えることができません。 これによって、データの改竄を

予防することができます。

他のフォルダについても、設定を変更する必要があります。 前述のように Windows

2000 をインストールした直後は、 全てのユーザに「フルコントロール」が割り当てら

れています。 機密性の高いデータなどは、必ずアクセス権を設定して行うようにして

ください。

2.3.7 ログの確認

Windows 2000 のログは UNIX システムと大きく異なり GUI を使用します。

これは、イベントログと呼ばれ、全ての情報を一括して管理します。

イベントログに含まれるものは、各アプリケーションごとのロギングを行うアプリケー

ションログ、Active Directory および関連したサービスのロギングを行うディレクトリサ

ービス、DNSの照会やゾーン転送などのロギングを行うDNSサーバー、システムで使

用するファイル複製処理のロギングを行うファイル複製サービス、ログオン情報やグ

ループポリシーのロギングを行うセキュリティ、システム状態のロギングを行うシステ

ムなどに分類されます。

Windows 2000やExchange 2000の動作は全てここでロギングが行われるため、 管

理者が異常がないかを見るには便利です。

しかし、何かのプログラムを通して処理するには、インターフェースや使用する言語

知識が必要となり、少々やっかいです。 実際には、WSH や VB を使用しコンポーネン

トを呼び出しログの処理を行います。

見るべきログはこれだけではありません。IIS を使用したサービスに関しては、 イベ

ントビュアーにロギングされるものは、各サービスの起動や終了、そしてサービスのエ

ラーなどです。 また、認証されたユーザはセキュリティの中に記録されます。

SMTP や Web サイトのコンポーネント個別の利用状態は各コンポーネントのプロパ

ティで設定されたディレクトリに保存されます。

デフォルトは以下のディレクトリとなっています。

%WinDir%¥System32¥LogFiles

第 3 章 ソフトウェアの設定方法

サイトの規模に関わらず、サーバやクライアントのインストールだけではセキュアな

環境は確保できません。

そこで、主要なソフトウェアのインストールや設定において十分注意する必要があ

ります。

ここでは、各ソフトウェアごとにセキュアな環境を構築するように設定方法を解説し

ます。

なお、ここで解説する内容はセキュリティに関するもののみであり、 個々のソフトウェアに関する設定は解説しません。

• 3.1 DNSの設定 • 3.2 SMTPの設定 • 3.3 POPの設定 • 3.4 FTPの設定 • 3.5 SSHの設定 • 3.6 HTTPの設定 • 3.7 SSLの設定 • 3.8 VPN • 3.9 IPFW • 3.10 Webクライアント

3.1 DNS のセキュリティ

ゾーン転送

DNS サーバーは、負荷分散や障害対策のために、ゾーンデータのコピーを複数の

DNS サーバーに保持できます。 元となるゾーンデータを持つ DNS サーバーをプライ

マリネームサーバー、 コピーを保持する DNS サーバーをセカンダリネームサーバー

と呼びます。

ゾーンデータのコピーは、元となるゾーンデータを必要とするセカンダリネームサー

バーが、 プライマリネームサーバーから取得することで実行されます。

この動作のことを、ゾーン転送といいます。 ゾーン転送は、TCP ポートの 53 番を利

用します。

ゾーン転送の設定は、プライマリネームサーバーに対して行います。 ゾーン転送

に関して設定する項目には、以下ようなものがあります。

• ゾーン転送を許可するサーバーの登録 • ゾーン転送の実行／停止

この設定にミスがあったり、設定そのものをし忘れている場合、 ゾーンデータが第三者に漏洩してしまう可能性があります。

これらのことに留意し、設定を行ってください。

また、FTP,SMTP と並んでセキュリティホールが報告されるサービスであり、 さらに

DNS 情報を書換ることによって本物のサービスが攻撃されていないのにかかわらず、

他のサーバを参照させることによって攻撃されているかのように見せるということも発

生しています。

セキュリティ情報に注意し、常に 新のソフトウェア、またはパッチを適用するよう

に留意してください。

ここでは、UNIX において多く使用されている BIND と、Windows 2000 で使用されて

いる DNS サービスを取り上げます。

• 3.1.1 BINDのセキュリティ設定 • 3.1.2 Microsoft DNSサービスのセキュリティ設定

3.1.1 BIND の設定

たとえば IP Spoofing の 後に紹介した DNS Spoofing や、 Web 改竄 の手法とし

て使用されている DNS 操作に関して、 必要以外のゾーン転送を防ぐことが必要で

す。

また、DNS に登録されているホストを不必要に見せないという面においても有効な

手段です。

(1) ゾーン転送先の制限

bind-8.1.2 以降であれば、これは簡単です。

もし、192.168.0.1 というホストで稼動している DNS サーバがあり、セカンダリとして

172.16.0.1 を設定しようとする場合、ゾーン転送は 172.16.0.1 に対して行えば良いので

す。

named.confの設定

options { directory "/etc/namedb"; allow-transfer { 172.16.0.1; }; named-xfer "/usr/libexec/named-xfer"; query-source address * port 53; };

設定を行った後に、ndc restart を行うだけで設定は完了します。

bind-8.1.2 以降であれば、これは簡単です。

172.16.0.0/16 のネットワーク全体に対してゾーン転送を許可する場合、次のように

記述します。

named.confの設定

allow-transfer { 172.16.0.0/16; };

ACL(アクセス制御リスト)を使用することもできます。

// アクセス制御リスト acl ipasec { 192.168.0.0/24; 172.16.0.0/16; 127.0.0.1; };

options { directory "/etc/namedb"; allow-transfer { ipasec; }; named-xfer "/usr/libexec/named-xfer"; query-source address * port 53; };

(2) ゾーン転送の停止

セカンダリ DNS サーバなどのように、 ゾーン転送を許可しない場合は以下のよう

に記述します。

allow-transfer { none; };

3.1.2 Microsoft DNS サービスのセキュリティ設定

Microsoft DNS サービスのセキュリティ設定は、DNS コンソールから行います。

タスクバーの[スタート]ボタンをクリックし、 [プログラム(P)]-[管理ツール]-[DNS]を

選択して下さい。

ゾーン転送

ゾーン転送による第三者へのゾーンデータの漏洩を防止するために、 以下の項

目について設定します。

• ゾーンデータ中の不要なレコードの削除 • ゾーン転送先の制限 • ゾーン転送の停止

なお、Microsoft DNS サービスのデフォルト設定は、 ゾーン転送が停止された状態

になっているため、 ゾーン転送の必要がない場合は以降のゾーン転送の設定は必

要ありません。

(1) ゾーンデータ中の不要なレコードの削除

ゾーン転送により複製されるゾーンデータとして本当に必要なレコードは、 インタ

ーネットに公開しても良いレコードだけです。

以下に示すレコードは、インターネットに公開する必要性がなく、 逆に攻撃する側の

材料となるレコードです。

• 内部ネットワークのホストの Aレコード • HINFOレコード、TXTレコード

これらのレコードが必要である理由が無ければ必ずゾーンデータから削除して下さ

い。

なお、Active Directory 用に設定された DNS サーバーは、 Active Directory 情報を

保持するために、 以下のサブドメインおよびレコードが必要になります。

• 4つ(_msdcs、_sites、_tcp、_udp)のサブドメイン • 上記サブドメイン内の SRVレコード

Active Directory を利用する場合、 これらのデータは削除しないように気をつけて

下さい。

(2) ゾーン転送先の制限

ゾーン転送が必要な場合は、 同じゾーンデータを持つ必要のあるセカンダリネー

ムサーバーのみをゾーン転送先として許可して下さい。

DNS コンソールからゾーン転送の制限を行うゾーンを右クリックし、 [プロパティ]を

選択します。

図 3.1.2-1 該当ドメインのプロパティを開く

次に、[ゾーン転送を許可するサーバー(O):]をチェックし、 [次のサーバーのみ(H)]

をオンにして下さい。

これで、ゾーン転送を許可するサーバーの設定が可能になります。 ゾーン転送を

許可するセカンダリネームサーバーを追加するには、 セカンダリネームサーバーの

IP アドレスを[IP アドレス(P):]に入力してから、 [追加(D)]ボタンをクリックして下さい。

このとき、セカンダリネームサーバーが複数存在する場合は、 更に追加しておいて

下さい。

図 3.1.2-2 プロパティでゾーン転送を許可

更に、TCP ポートの 53 番へのアクセスも、 セカンダリネームサーバーのみを許可

するように設定して下さい。

(3) ゾーン転送の停止

ゾーン転送が必要ない場合は、ゾーン転送の停止を行って下さい。

ゾーン転送の停止は、[ゾーン転送を許可するサーバー(O):]のチェックを外すことで

行えます。

更に、TCP ポートの 53 番へのあらゆるアクセスを禁止します。

これは、TCP ポートの 53 番を利用する未知のセキュリティホールへの対策として有

効です。

3.2 SMTP

SMTP において も注意しなければならない点は、 spam の踏み台とならないこと

です。

また、SMTP のコマンドを使用してユーザ情報を得ることができるため、 関連する

コマンドを使えないように設定する必要があります。

なお、SMTP を使用すると、メールの内容を盗聴される可能性があります。

これは、経路を暗号化することによって対策可能ですが、この場合は設定した相手

との間でてしか通信を行うことができません。 組織内での利用を除き、メールサーバ

は不特定多数のサイトから自サイトへメールを受信しなければならないため盗聴対策

は難しいと言えます。

現状では、機密性の高いメールに関しては個別に PGP 等で暗号化を行うしかあり

ません。

• 3.2.1 sendmailの設定 • 3.2.2 Microsoft Exchange Server 2000 SMTPサービスのセキュリティ設定

3.2.1 sendmail の設定

sendmail で spam の踏み台とならないためにいくつかの設定を行う必要がありま

す。

ここでは、sendmail の基本的な設定の他に行わなければならない spam の踏み台と

ならないための設定を行います。

spam の対策には、大きく分けて 2 種類あります。1 つは踏み台とならないために中

継の禁止をおこなうもの、もう 1 つは自サイトに対して spam を送られないようにするた

めのものです。

sendmail の設定を行う際、自サイトのメール設定だけでなく、中継を行わないように

設定する必要があります。

(1) 中継の禁止

中継を許可したばかりに spam の踏み台となってしまっては、自サイトの影響だけで

なく、多くのサイトに迷惑をかけ無駄な資源を使用してしまうことになります。 そこで、

他サイトから自サイトに対するメール以外を排除します。

ここの説明は sendmail.8.11.3 を前提としています。

sendmail において中継の禁止は sendmail.cf において設定します。sendmail の起動

時に、その動作を定義するものです。 ここでは、sendmail.cf を m4 形式のマクロを使

用し生成します。今回は、ipa-sec.mc というファイル名で作成しますが、任意の判りや

すい名前で構いません。

このマクロの雛型は、sendmail のソースに含まれており、sendmail-8.11.3/cf/cf の

パスに OS ごとに置かれています。

Linuxの場合はgeneric-linux.mc、FreeBSDの場合はgeneric-bsd4.4.mcを ipa-sec.mc

というファイルにコピーします。

このときの ipa-sec.mc の内容は次の通りです。

divert(0)dnl VERSIONID(`$Id: generic-bsd4.4.mc,v 8.10 1999/02/07 07:26:02 gshapiro Exp $') OSTYPE(`bsd4.4')dnl DOMAIN(`generic')dnl MAILER(`local')dnl MAILER(smtp)dnl

FreeBSD においてのみ注意しなければならない点があります。 それは

4.2-RELEASE から mail.local のインストール方法が変わったことです。 これによって、

mail.local をメール配送に使用している場合は、 sendmail.cf の Mlocal において F=S フ

ラグを設定する必要があります。

ipa-sec.mc ファイルには次の行を追加します。

MODIFY_MAILER_FLAGS(`LOCAL', `+S')dnl

ここまでは通常のメール設定です。

ここからは、/etc/mail/aliases をはじめとする sendmail の動作に必要な設定が終わ

っているとして解説を行います。

中継を禁止するには、さらに次の一行を加えます。 これは、メールの転送や中継

の制限や、受け取りたくないメールアドレスやドメインを記述します。

FEATURE(`access_db', `hash -o /etc/mail/access')dnl /etc/mail/accessには、中継を許可するサイトの設定を記述し、 次のようにデータベースを作成します。 # makemap hash /etc/mail/access < /etc/mail/access この他、メールサーバの本来の動作を行う設定を記述し、 次のように sendmail.cf を生成します。 % m4 -D_CF_DIR_=./sendmail-8.11.3/cf/cf/ ./sendmail-8.11.3/cf/m4/cf.m4 ipa-sec.mc > sendmail.cf 最 後に、sendmail を再起動するか、システムを再起動することによって、 最新のsendmail.cfが読み込まれます。 中継しないことを確認する

設定したサーバが中継するかどうかを確認することが必要です。

これには、abuser.net が提供しているテストによって確認することができます。Mail

relay testing

(2) データベースを参照し禁止する

中継を許可しているサイトを集めたデータベースが存在します。 一種のブラックリスト

として考えて良いでしょう。

このデータベースに掲載されているサイトからはメールを拒否する設定も可能です。

このためには、ipa-sec.mc に次の行を追加します。

FEATURE(dnsbl,`inputs.orbs.org')dnl FEATURE(dnsbl,`outputs.orbs.org')dnl FEATURE(dnsbl,`dul.maps.vix.com')dnl

FEATURE(dnsbl,`relays.mail-abuse.org')dnl FEATURE(dnsbl,`rbl.maps.vix.com')dnl

(3) 特定のメールを拒否する

sendmail の設定では、中継を拒否するだけでなく特定のドメインから自サイトに届く

メールを拒否することも可能です。 これには、/etc/mail/access ファイルを修正しま

す。たとえば、以下のように記述します。

user@sample-spam.com REJECT relay-dom.com REJECT 拒否する方法はいくつかあります。

• ドメインを拒否 • IPアドレスを拒否 • メールアドレスを拒否 • ユーザ名を拒否

ドメインを拒否

もし、spam を送るドメイン全体を拒否したい場合は次のように指定します。

これは、sample-spam.com ドメインが spam の発信源である、または中継に利用さ

れやすいサーバであり、このドメインから自サイトに対するメールは一切拒否するとい

う場合に使用します。

なお、このドメインは架空のものであるため、実際に拒否するメールアドレスを使用

してください。

relay-dom.com REJECT IPアドレスを拒否

もし、特定の IP アドレス(192.168.128.1)から自サイトに対するメールは一切拒否す

るという場合に使用します。

なお、この IP アドレスは架空のものであるため、実際に拒否する IP アドレスを使用

してください。

192.168.128.1 REJECT メールアドレスを拒否

特定のユーザが spam を送信している場合、このユーザから自サイトに対するメー

ルは一切拒否するという場合に使用します。なお、このメールアドレスは架空のもの

であるため、実際に拒否するメールアドレスを使用してください。

user@sample-spam.com REJECT ユーザ名を拒否

spam@といった明らかに spam 送信を目的としたユーザ名を全て拒否する場合は次

のように指定します。ただし、この場合は spam を目的としたユーザ以外も拒否するた

め、 使用には十分注意する必要があります。 また、spam777@といったユーザ名に

は有効にならない点にも注意しておく必要があります。

spam@ REJECT

(4) 拒否したメール

これらの設定を行うごとに makemap コマンドによって access ファイルのデータベー

スを作成する必要があります。データベースを作成し、実際に拒否されたメールは、

次のようにログに記述されます。ログは FreeBSD の場合/var/log/maillog となります。

ここには、次のように記述されます。

日時 mail sendmail[2210]: f44FSEe02210: ruleset=check_mail, arg1=, relay=mail.ipa-sec.com, reject=550 5.7.1 ... Message from user@sample-spam.com rejected もし、拒否せず受信できるようにするためには、/etc/mail/access から該当行を削除します。なお、既に拒否したメールは送信者に返されているため、再送信してもらわなければ

受信者に配送することはできません。

(5) ユーザ情報列挙の拒否

SMTP のコマンドには EXPN と VRFY があります。

つまり、これらを使用すると、そのユーザが存在するかということが分かります。

たとえば、下の赤色部が、 telnet コマンドで SMTP のポートに接続し、EXPN コマン

ドを入力したところです。

% telnet mail.ipa-sec.com smtp Trying ::1... telnet: connect to address ::1: Connection refused Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 mail.ipa-sec.com ESMTP Sendmail 8.11.3+3.4W/8.11.3; Mon, 3 Mar 2001 21:06:18 +0900 (JST) HELO www.ipa-sec.com 250 mail.ipa-sec.com Hello localhost [192.168.0.1], pleased to meet you EXPN yamada 250 2.1.5 YAMADA Taro >yamada@ipa-sec.com<

これらを禁止するには、ipa-sec.mc にて、noexpn と novrfy を定義することが必要で

す。

このためには、ipa-pre.mc に次の一行を追加します。

define(`confPRIVACY_FLAGS', ``authwarnings,noexpn,novrfy'')dnl

3.2.2 Microsoft Exchange Server 2000 SMTP サービスのセキュリティ設定

Microsoft Exchange Server 2000 SMTP サービスのセキュリティ設定は、 Exchange

システムマネージャから行います。 タスクバーの[スタート]ボタンをクリックし、 [プロ

グラム(P)]-[Exchange Server]-[システムマネージャ]を選択して下さい。

(1) メールの不正中継

メールの不正中継による spam メール転送を防止するために、 以下の項目につい

て設定します。

• メール中継の制限 • メール中継の停止

なお、Microsoft Exchange Server 2000 SMTP サービスのデフォルト設定は、 メー

ル中継が停止された状態になっていますので、 メール中継の必要がない場合は、以

降のメール中継の設定は必要ありません。

メール中継の制限

メールの中継が必要な場合は、中継に使用するコンピュータだけに中継を許可しま

す。

Exchange システムマネージャの左ペインにて、 [[組織名] (Exchange)]-[サーバ

ー]-[[サーバー名]]-[プロトコル]-[SMTP]-[[SMTP 仮想サーバー]]を右クリックし、

[プロパティ]を選択します。 ここでは、[IPAOrganization (Exchange)]-[サーバ

ー]-[nurikabe]-[プロトコル]-[SMTP]-[既定の SMTP 仮想サーバー]のプロパティを選

択します。

図 3.2.1-1 SMTPコンポーネントのプロパティを開く

[アクセス]タブをクリックした後、[中継(E)...]ボタンをクリックします。

図 3.2.1-2 プロパティを開き中継ボタンをクリック

[中継の制限]ダイアログが表示されます。

中継を許可するコンピュータを追加するには、 まず[以下のリストに含まれるコンピ

ュータのみ(O)]をチェックします。 これで、許可するコンピュータを追加するモードにな

ります。 次に[追加(A)...]ボタンをクリックして下さい。

中継に使用するコンピュータを追加します。

コンピュータの指定には、IP アドレス、ネットワークアドレス、 ドメイン名の 3 種類の

うち、いずれかを使用できます。

ここでは、中継に使用するコンピュータとして、 "mail.trustedsite.com"をドメイン名で

追加します。 "追加した後、[OK]ボタンをクリックして下さい。

図 3.2.1-3 中継を許可するドメインを設定

"mail.trustedsite.com"が、 中継に使用するコンピュータとして許可されたことを確

認した後、 [OK]ボタンをクリックして下さい

図 3.2.1-4 中継許可の設定

なお、上記のように[以下のリストに含まれるコンピュータのみ(O)] をチェックした後

に追加を行った場合、 追加したコンピュータは、中継を許可されたことになり、 リスト

にないコンピュータは、中継を拒否されることになります。

逆に、[以下のリストに含まれるコンピュータ以外のすべて(X)] をチェックした後に

追加を行った場合、 追加したコンピュータは、中継を拒否されたことになり、 リストに

ないコンピュータは、中継を許可されることになります。 設定を行うときは、このチェッ

クに注意して下さい。

メール中継の停止

メールの中継が必要ない場合は、メール中継の停止を行って下さい。 メール中継

の停止は、[以下のリストに含まれるコンピュータのみ(O)] をチェックした後、 リストに

あるコンピュータを全て削除することで設定します。

図 3.2.1-5 一覧から削除し中継の停止を行う

(2) ユーザー情報の列挙

Microsoft Exchange Server 2000 SMTP サービスには、 ユーザー情報の列挙を行

う SMTP コマンドである EXPN、VRFY が実装されていません。 そのため、EXPN、

VRFY によるユーザー情報の列挙は無効です。

3.3 POP, IMAP

現在、多く使用されている POP3 は、 盗聴で解説したようにパスワードが知られる

恐れがあります。

ここではそれらに対する設定を行います。 また、Exchange 2000 においては標準で

IMAP も使用できるため併せて設定の解説を行います。

• 3.3.1 qpopperのセキュリティ設定 • 3.3.2 Microsoft Exchange Server 2000 POP, IMAPサービスのセキュリティ設定

3.3.1 qpopper の設定

(1) POP3 の問題

現在、Windows などのクライアントにメールサーバに届いたメールを取込むには、

POP3 と呼ばれるプロトコルが使用されています。

しかし、POP3 はサーバとクライアントの間の通信を平文で行っているため、盗聴の

項で述べたようにユーザ名やパスワードが簡単に盗聴できてしまいます。

実際に、下のように telnet コマンドを使用して手動で接続するとこれがよく判りま

す。

このため、現在では認証部分は APOP が主流になっています。

telnetで POP3と接続

% telnet mail.ipa-sec.com 110 Trying 192.168.0.1... Connected to mail.ipa-sec.com. Escape character is '^]'. +OK QPOP (version 3.1.2) at mail.ipa-sec.com starting. user yamada ユーザ名

+OK Password required for htnari. pass hIkj7S_44Q パスワード +OK yamada has 2 visible messages (0 hidden) in 65495 octets.

これらの理由により、現在では POP3 は推奨されていません。

本書でも、POP3 は推奨せず APOP の使用を推奨します。

ただし、APOP はクライアント側の対応が必要となるため、 APOP 環境を構築した

後では APOP 非対応のメールクライアントはメールを取込むことができなくなります。

APOP 対応のメールクライアントを使用しているユーザから移行するようにしてくだ

さい。

(2) APOP

APOP は、これまでの POP3 におけるユーザ認証の問題を解消するために強化し

たものです。

これまで、POP3 サーバに接続した時のユーザ認証が平文で行われることに対し、

APOP では、パスワードをやり取りする際、暗号化して送るため、 POP3 を用いるより

もセキュリティの向上がはかれます。

何より、POP3 の場合は、いくら類推困難なパスワードを頻繁に変更しようとも、 盗

聴されることによってサーバと一度通信を行うだけでパスワードが知られてしまってい

ました。

暗号化を行うことによって、盗聴によるパスワード漏洩を防ぐことができます。

APOP では、認証時に暗号化が行われると書きましたが、 これはあくまでも認証に

おいてのみです。

メールの本文は暗号化されません。 よって、メール本文の盗聴は APOP では防ぐ

ことができません。

APOP の利点はこれだけではありません。

POP3 のパスワードは、基本的にシステムのパスワードと同一のものを使用します。

すなわち、POP3のパスワードが盗聴されるということは、 システムのパスワードが盗

聴されるということに繋がります。

APOP では、パスワードの管理はシステムとは別となり、単独で管理されます。 こ

れによって、システムを運用し管理する側にとっても芋蔓式にパスワードが漏れること

を防げることとなります。しかし、その反面、ユーザに対してパスワード変更を促す箇

所が増えるため、 あらかじめユーザに対してパスワード変更の重要性を知らせ、各

人が意識するように促しておく必要があります。

APOPの設定

現在、Qualcomm 社が配布している qpopper の利用が多いでしょう。 ここでは、

qpopper3.1.2 を使用します。

ftp://ftp.qualcomm.com/eudora/servers/unix/popper/

まず、popper が使用するアカウントを作成する必要があります。FreeBSD ならば

adduser、Linux ならば useradd でアカウントを作成します。 今回は apop というアカウ

ントを作成しました。

次に、APOP 対応で popper をビルドします。なお、赤色の部分は個々の環境に合

わせてください。

# ./configure --enable-apop=/etc/pop.auth --with-popuid=apop# make # cd popper # install popper /usr/libexec # install -m 4755 -o apop popauth /usr/libexec

これで APOP 対応の popper がインストールされました。

ここからは、POP3 とは異なる作業が入ります。 前述の通り、パスワード管理は

APOP の場合は POP3 とは異なります。 ユーザごとに認証の用意を行います。ここで

は、ユーザ yamada さんを APOP に対して有効にします。

# popauth -init # popauth -user yamada

Changing POP password for yamada.Old Password: ************ Retype new password: ***********

これでユーザ yamada さんが APOP に対して有効になりました。実際にクライアントを

起動して試してみてください。

(3) tcp_wrapper による制限

APOP を使用している場合であっても、色々なところから接続されることはセキュリ

ティ上好ましくありません。 たとえば、管理する側の立場で考えると、インターネットか

らの POP3 や APOP の接続を拒否したいものです。

また、出張などで遠隔地からメールを取込む場合、出張先のネットワークからのよ

うに使用するネットワークが固定されている場合や特定の ISP から接続する場合など

があります。この場合は、そのネットワークに対してのみポートを開き、他は全て遮断

したいものです。

このような場合は、tcp_wrapper を使用します。 POP3 や APOP の処理を行う

popper は、FreeBSD,Linux 共に inetd から起動されるため、 /etc/hosts.allow に記述

するだけで制御が可能です。

もし、LAN 側のネットワークと、出張先である remotesite.com からの POP3 接続の

みを許可する場合は次のように記述します。

pop3 : localhost : allow pop3 : 192.168.0.0/255.255.255.0 : allow pop3 : 172.16.0.0/255.255.0.0 : allow pop3 : .remotesite.com : allow

これで LAN 側と remotesite.com からのみ POP3 を許可することができました。

もちろん、APOP も同様に設定することができます。

3.3.2 Microsoft Exchange Server 2000 POP,IMAP サービスのセキュリティ設

定

Microsoft Exchange Server 2000 POP, IMAP サービスのセキュリティ設定は、

Exchange システムマネージャから行います。 タスクバーの[スタート]ボタンをクリック

し、 [プログラム(P)]-[Exchange Server]-[システムマネージャ]を選択して下さい。

(1) ログオン名やパスワードの漏洩

Microsoft Exchange Server 2000 の POP サービスは POP3、 IMAP サービスは

IMAP4 を実装しています。 POP3、IMAP4 共に、ログオン時にクリアテキストでログイ

ン名、 パスワードの受け渡しが発生するため、 盗聴が可能であれば、 簡単にアカ

ウントを奪取されてしまいます。 対策としては、以下のような項目が考えられます。

1. サーバーに接続可能なコンピュータを制限する 2. 通信を暗号化して、盗聴されてもログオン名、 パスワードが簡単に判明しないようにする

接続可能なコンピュータの制限

POP3 に接続可能なコンピュータを設定する場合は、 Exchange システムマネージ

ャの左ペインにて、 [[組織名] (Exchange)]-[サーバー]-[[サーバー名]]-[プロトコ

ル]-[POP3]- [[POP3 仮想サーバー]]を右クリックし、[プロパティ]を選択します。

ここでは、[IPAOrganization (Exchange)]-[サーバー]-[nurikabe]-[プロトコル]-

[POP3]-[既定の POP3 仮想サーバー]のプロパティを選択します。

図 3.3.2-1 IMAP4のプロパティを開く

IMAP4 に接続可能なコンピュータを設定する場合は、[既定の IMAP4 仮想サーバ

ー] のプロパティを開いて下さい。なお、以降の説明は、POP3、IMAP4 に共通な設定

となっています。

初に、[アクセス]タブの中にある[接続(N)...]ボタンをクリックします。

図 3.3.2-2 接続ボタンをクリック

[接続]ダイアログが表示されます。

接続を許可するコンピュータを追加するには、 まず[以下のリストに含まれるコンピ

ュータのみ(O)]をチェックして下さい。 これで、許可するコンピュータを追加するモード

になります。 次に[追加(A)...]ボタンをクリックして下さい。

接続を許可するコンピュータを追加します。

コンピュータの指定には、IP アドレス、ネットワークアドレス、 ドメイン名の 3 種類の

うち、いずれかを使用できます。 ここでは、接続を許可するコンピュータとして、

"pop.trustedsite.com"をドメイン名で追加します。 追加した後、[OK]ボタンをクリック

して下さい。

図 3.3.2-3 接続を許可するドメインを追加

"pop.trustedsite.com"が、 中継に使用するコンピュータとして許可されたことを確

認した後、 [OK]ボタンをクリックして下さい

図 3.3.2-4 中継を許可するドメインを確認

なお、上記のように[以下のリストに含まれるコンピュータのみ(O)] をチェックした後

に追加を行った場合、 追加したコンピュータは、中継を許可されたことになり、 リスト

にないコンピュータは、中継を拒否されることになります。 逆に、[以下のリストに含ま

れるコンピュータ以外のすべて(X)] をチェックした後に追加を行った場合、 追加した

コンピュータは、中継を拒否されたことになり、 リストにないコンピュータは、中継を許

可されることになります。

設定を行うときは、このチェックに注意して下さい。

POP3、IMAP4 は、接続可能なコンピュータを内部ネットワークのコンピュータだけに

制限すると、 外部ネットワークにログオン名やパスワードが漏洩することがなくなるた

め、よりセキュアな環境となります。

外出先からメールを見る必要がない場合は、 内部ネットワークのコンピュータから

のアクセスだけを許可するように設定してください。

(2) 暗号化

外出先からメールを見なければならない場合は、 通信を暗号化するのが望ましい

です。

幾つかの方法で、POP3、IMAP4 の通信を暗号化することができます。 以下に代

表的なものを挙げます。

1. sshポートフォワーディング 2. SSL 3. IPsec 4. APOP

これらの方法のうち、Windows 2000 および Exchange Server 2000 で使用可能な暗

号化は、SSL と IPsec です。

SSL による暗号化については、 SSL で説明している IIS Web サイトの暗号化通信

の設定を参考にして下さい。

IPsec による暗号化については、 VPN で説明している IPsec の設定を参考にして

下さい。

3.4 FTP

FTP のサービスは、ファイル転送プロトコルという性質上、 ユーザの管理や、思わ

ぬセキュリティホールからユーザの情報が流れ出すことや、 プログラムの実行など

の問題が多く発生しています。また、自サイトへの直接的な攻撃ではなく、不当なファ

イルの交換に使われるなどの被害も発生します。

FTP のセキュリティは、権限の設定だけでなく、必ず 新版のソフトウェアを使用す

る (またはパッチを適用する)ように注意してください。

また、FTP クライアントとの通信では、パスワード情報が盗聴される可能性がありま

す。 これは、SSHのポートフォワーディング機能を使用するなどで対策するようにして

ください。

ここでは、UNIX システムで多く使用されている wu-ftpd と、Windows 2000 において

標準で添付されている FTP サービスについて解説します。

• 3.4.1 wu-ftpdのセキュリティ設定 • 3.4.2 Microsoft FTPサービスのセキュリティ設定

3.4.1 wu-ftpd の設定

ftpd として wu-ftpd を使用している場合が多いでしょう。

Linux,FreeBSD といった OS のインストールを行い、ftpd を起動しなければならない

場合に考えなければならない点がいくつかあります。

• ftpサービスを提供する範囲 • Anonymousを許可するか

ftpd を動かす際、まず wu-ftpd のバージョンがいくつかを確認することから始まりま

す。特に wu-ftpd においては何度もセキュリティホールが発見され、その度毎に新し

いバージョンが出されています。もし、 新版でなければ ftpd を起動する前に 新版

に入れ替えてください。

これは、ファイル転送を行うプロトコルであるがために、root 権を奪われたり、パス

ワードファイルを盗まれたり、任意のプログラムを実行するということが可能なセキュ

リティホールが潜んでいる可能性があるためです。

現在発見されているセキュリティホールで致命的な部分がいくつかあります。

まず、SITE EXEC のバグがないかどうかを確認します。これは、"2.2 以前にあった

問題です。SITE EXEC コマンドを使用することによって、システムにある実行可能なプ

ログラムやスクリプトを実行することができます。

よって、ftpd は 新にしなければならないのです。

使用している ftpd が wu-ftpd でなくても 新版に入れ替えるべきです。たとえば、

ProFTPD 1.2.0 以前では、一つでも書きこみ可能なディレクトリが存在する場合に対象

となるホストの root 権を取得することができる問題がありました。

(1) ディレクトリの権限

Anonymous FTP サーバを構築する場合、まず FTP のホームディレクトリは書き込

み不可にすべきです。これ以下のディレクトリやファイルの権限をいくら注意深く設定

しても、ホームディレクトリの権限が間違っていると全て意味の無いものになります。

# chmod 555 # chown root たとえば、これを行わないと、攻撃側から.rhostsを送り込まれるのです。 また、この他のディレクトリやファイルに対しても間違った権限が付与されていることが

あります。 以下の表を参考にしてアクセス権限を設定してください。

表 3.4.1-1 設定するアクセス権

ディレクトリ アクセス権限 ユーザのアクセス権

ftp ownerは root アクセス権は 555

読み取りと実行

ftp/bin ownerは root アクセス権は 555

読み取りと実行

ftp/bin/ls ftp/bin/date

ownerは root アクセス権は 111

実行

ftp/etc ownerは root アクセス権は 555

読み取りと実行

ftp/etc/passwd ownerは root アクセス権は 444

読み取り

ftp/etc/group ownerは root アクセス権は 444

読み取り

(2) incoming ディレクトリの削除

もし、古いバージョンのから 新にアップグレードを行い続けたサーバの場合、

incoming ディレクトリが残っている場合があります。このディレクトリは、ユーザがファ

イルを公開する際に put を行う場所でした。しかし、これは誰でも put/get できるため、

不正なファイルの交換に悪用されることがあります。このディレクトリは削除し運用方

法を見直すべきです。

% ls -l

total 4

dr-xr-xr-x 2 root operator 512 7/12 1999 bin

dr-xr-xr-x 2 root operator 512 7/12 1999 etc

drwxrwxrwt 2 root operator 512 4/17 2000 incoming

drwxr-xr-x 2 root operator 512 7/12 1999 pub

(3) tcp_wrapper の設定

もし、この FTP サーバが特定のネットワークのみを対象とする場合、 tcp_wrapper

を利用し制限することができます。たとえば、この FTP サーバを ipa-sec.com からのみ

しか接続させない場合は、 /etc/hosts.allow を以下のように設定します。

ftpd : localhost : allow

ftpd : .ipa-sec.com : allow

wu-ftpd の ftphosts ファイルによって制御することもできますが、メールで管理者へ

の通知を行うよう tcp_wrapper を設定している時などは、 tcp_wrapper で処理したほう

が便利でしょう。

なお、tcp_wrapper で設定した場合であっても、念のために ftphosts には必要 小

限度のの設定を書いておいてください。

ftphosts では、アカウント毎にアクセス制御を行います。

allow に続いてユーザ名とホスト名を記述し、該当するユーザが該当のホストからロ

グインしてきたときのみログインを許可します。

たとえば、ユーザ yamada さんが、www.ipa-sec.com からログインしてきたときのみ

許可する場合です。

allow yamada www.ipa-sec.com

(4) /etc/ftpaccess の設定

wu-ftpdでは、ftpaccessファイルによって、セキュリティの設定を行うことができます。

特に注意するところは、ユーザからファイルを put する許可と、パスワードチェックで

す。

Anymous FTP では、ログイン時にユーザ名として anonymous を使用し、パスワード

には慣例的にそのユーザのメールアドレスを用います。

このパスワードを出来る限り厳重にチェックすることが必要となります。

しかし、メールアドレスのチェックにも限度があるため、入力されたメールアドレスが

RFC822 のフォーマットに適合するかをチェックし、適合しない場合は接続を拒否しま

す。もちろん、このチェックからは有効なメールアドレスと考えられるものかを判断する

のみとなっているため、他人のメールアドレスを使用した場合などは判断できません。

passwd-check rfc822 enforce

次に、anonymous ユーザにおいてファイルのアップロードを禁止する必要がありま

す。これは、不正なファイルの交換を防ぐためです。

incoming ディレクトリも削除するようにしてください。

デフォルトの設定では anonymous FTP ユーザにも incoming ディレクトリにはファ

イルのアップロードができるようになっているため、allow の部分を no に変更します。

upload /home/ftp * no

upload /home/ftp /pub/incoming no ftp daemon 0666 nodirs

3.4.2 Microsoft FTP サービスのセキュリティ設定

(1) FTP バウンズアタック

FTP バウンズアタックとは、許可されていないユーザが、 ターゲットのサーバにア

クセス可能な別のマシンを経由して、 FTP サーバにアクセスすることを言います。

この攻撃は、サーバと、ターゲットのサーバにアクセス可能なマシンの、 セキュリテ

ィ設定の欠陥をついたものといえます。もちろん、それ以外の攻撃にも対処しなけれ

ばなりませんが、 FTP サーバを稼動させることは、サーバのセキュリティを考える上

で、 決して好ましいとはいえません。

どうしても必要な場合は、 IPSec による暗号化通信と組み合わせることをお勧めし

ます。

セッションの制限

FTP サーバのセッション制限は、 管理ツールの「インターネット サービス マネー

ジャ」行うことができます。

ここで、「既定の FTP サイト」のプロパティ画面を開いてください。

図 3.4.2-1 FTPサイトのプロパティを開く

この画面の「 大接続数」はデフォルト値になってい場合があります。

これが、必要以上の値の場合は、必要十分な値に設定してください。 また、接続

のタイムアウトについても、より小さな値を設定することで、 ある程度の Dos 攻撃から

はシステムを守ることができます。

なお、「現在のセッション」ボタンを押下すると、 FTP サーバにアクセスしているユ

ーザ、接続元が表示され、 強制的に接続を切断することもできます。

(2) 匿名アクセスのアカウント変更

IIS の設定では、デフォルトの状態では「匿名アクセス」を認めています。

この場合、パスワードを入力することなく、ユーザ名「anonymous」を使って、 誰でも

FTP ログオンすることができます。

anonymous でログオンした場合、サーバではあらかじめ設定された、 Windows ユ

ーザアカウントを使用して、ファイルにアクセスします。 少々問題なのは、デフォルト

状態では、 IIS をインストールしたときに作成されたアカウントが割り当てられている

ため、 これを予想されやすいということです。

これが悪用されることを避けるために、匿名アクセスを許可する場合は、 新たに

FTP 匿名アクセス用のアカウントを作成し、割当を行うようにしてください。

以下は、アカウントを匿名アクセス用として割り当てる手順です。

1. 匿名アクセス用のアカウントを作成します。 2. 作成したアカウントに、FTP公開用のフォルダのアクセス権を設定します。 このとき設定するアクセス許可は、任意の設定を行いますが、 無差別にアクセスされることを考え、 「読み取り」のみを許可することをおすすめします。 「書き込み」や「変更」などを許可すると、 その設定が匿名ログオンしたときにも反映されるため、大変危険です。

3. 「インターネット サービス マネージャ」を開き、 「既定の FTP サイト」のプロパティを開きます。

4. 「セキュリティ アカウント」タグをクリックします。 5. 匿名アクセスを許可するの欄のユーザ名に、 先ほど作成した匿名アクセス用のアカウントのユーザ名とパスワードを指定します。

6. 「IISによるパスワードの管理を許可する」にチェックをつけます。 7. OKボタンを押下して、プロパティ画面を終了します。

以上で、anonymous による匿名アクセスに、 新しく作ったアカウントが割り当てられ

ました。

(3) 匿名接続の有効性

匿名アクセスでは、「anonymous」というユーザ名で誰でもログオンできるため、 非

常に危険に思えます。

では、仮に匿名アクセスを許可しない場合はどのような問題が考えられるでしょう

か。

匿名アクセス続を許可しない場合、FTP にログオンするときは、 Windows ユーザ

ー アカウントを使用します。しかしこの場合、ユーザ名とパスワードが暗号化されるこ

となく送信されるため、 これを盗聴される恐れがあり、非常に危険です。このため、

「インターネット サービス マネージャ」において、FTP サイトの匿名接続の設定には、

「匿名接続のみを許可する」という設定を使用できるようになっています。

匿名アクセスを許可しない場合、 あるいは Windows ユーザアカウントを FTP ログ

オンに使用する場合は、 別の対策と組み合わせることが必要です。

(4) 特定の IP アドレスからのみアクセスを許可する

匿名アクセスであっても、 特定の IP アドレスからのみの接続を許可する方法によ

って、 ユーザの制限を行うことができます。ただし、FTP サイトの「セキュリティ アカ

ウント」設定において、 「匿名接続のみを許可する」にチェックをつけていないと、

Windows ユーザアカウントでログオンすることもできるため、 依然としてユーザ情報

傍受の危険性があります。

以上をふまえ、 特定の IP アドレスからのみのログオンを許可する設定手順を説明

します。

1. インターネット サービス マネージャにおいて、 FTP サイトのプロパティ画面を開き、「ディレクトリ セキュリティ」 タブをクリックします。

2. 「既定では、すべてのコンピュータからのアクセスを」の項目において、 「拒否する」を選択します。

3. 「ただし次のものは除きます」から、追加ボタンを押下します。 4. 「アクセス拒否」ダイアログが表示され、許可する IP アドレスを指定し、 OK を押下します。ここでは、IP アドレスとサブネットマスクを組み合わせて、 グループ化されたコンピュータのを指定することもできます。

5. 最後に、プロパティ画面を閉じ、設定を終了します。

手順 2 において、「拒否する」の選択を忘れないようにしてください。

「許可する」を選んだ場合、指定した特定 IP アドレスのマシンのログオンを、 受付

けなくなってしまいます。

(5) 暗号化を用いた接続

前述のように、特定のユーザだけにアクセスを許可するためには、 ユーザ名とパ

スワードを入力する必要があります。

しかし、これらを暗号化せずに通信することは大変危険です。

今回は、この問題を解決するために、IPSec による暗号化を行います。

1. 以下の設定の、２つの IPセキュリティフィルタを作成します。

タグ名 項目 設定内容 備考

発信元アドレス任意の

IPアドレス

宛先アドレス 特定の

IPアドレス

表示されたアドレス入力欄に、イ

ンターネット側の IPアドレスを

入力します。

フィルタ操作

の管理

ミラー化 チェック有

表示されたアドレス入力欄に、イ

ンターネット側の IPアドレスを

入力します。

プロトコルの

種類の選択 TCP

IPプロトコル

ポートの設定

「任意の発信ポート」

を選択

プロトコル

IPプロトコル

ポートの設定

「次の宛先ポート」

を選択

エディットコントロールに 21

と入力

説明 説明 任意に設定 フィルタについて任意の説明を

入力します。

2.

タグ名 項目 設定内容 備考

発信元アドレス任意の

IPアドレス

宛先アドレス 特定の

IPアドレス

表示されたアドレス入力欄に、イ

ンターネット側の IPアドレスを

入力します。

フィルタ操作

の管理

ミラー化 チェック有

表示されたアドレス入力欄に、イ

ンターネット側の IPアドレスを

入力します。

プロトコルプロトコルの

種類の選択 TCP

IPプロトコル

ポートの設定

「任意の発信ポート」

を選択

IPプロトコル

ポートの設定

「次の宛先ポート」

を選択

エディットコントロールに 20

と入力

説明 説明 任意に設定 フィルタについて任意の説明を

入力します。

3. すでに割り当てを行っている Active Directory IPセキュリティ ポリシーがあれば、 作成したフィルタをポリシーに追加します。 ポリシーが存在しない場合は新規作成を行い、割り当てを行います。 (これらの設定方法の詳細は、VPN にて説明しています。)

4. パケットフィルタの「入力フィルタ」として、 次の接続を許可する設定を行います。 他のフィルタ設定がすでにある場合は、追加する形で行います。 この設定によって、別ポートで FTP 接続が行われた場合、 IPSec による通信が行われなくなる問題を回避します。 これらの設定方法の詳細は、リモートセキュリティ設定にて説明しています。)

発信元ネットワーク 宛先ネットワーク

対象 チェック

の有無 IP サブネット

マスク

チェック

の有無 IP

サブネット

マスク

プロトコル

発信元ポート 0FTP 無 - - 有

インターネット側

IPアドレス 255.255.255.255 TCP

宛先ポート 20

発信元ポート 0FTP 無 - - 有

インターネット側

IPアドレス 255.255.255.255 TCP

宛先ポート 21

�「下の条件に一致するパケットを除いたすべてのパケットを破棄する」の選択を忘れないようにしてください。

5. 同様に、パケットフィルタの「出力フィルタ」として、 次の接続を許可する設定を行います。他のフィルタ設定がすでにある場合は、 追加する形で行います。

発信元ネットワーク 宛先ネットワーク

対象 チェック

の有無 IP

サブネット

マスク

チェック

の有無 IPサブネット

マスク

プロトコル

発信元ポート 20 FTP 有

インターネット側

IPアドレス 255.255.255.255 有り - - TCP

宛先ポート 0

発信元ポート 21 FTP 有

インターネット側

IPアドレス 255.255.255.255 無 - - TCP

宛先ポート 0

�「下の条件に一致するパケットを除いたすべてのパケットを破棄する」の選択を忘れないようにしてください。

以上で、暗号化を用いた FTP 接続が可能になります。

(6) FTP 公開用のフォルダを変更する

既定のディレクトリを、そのまま使用するのではなく、 別ドライブにフォルダを作成

し、それを公開用として割り当てます。

これは、システムディレクトリから切り離すことにより、 攻撃によるダメージを少しで

も軽減することを目的とします。

以下の例では、D:ドライブに FTP 公開用フォルダ「FTPFolder」を作成し、 「インター

ネット サービス マネージャ」にて、 このフォルダを FTP サーバのルートディレクトリと

して割り当てます。

1. エクスプローラなどで、「D:¥」ドライブに「FtpFolder」という名前の、 フォルダを作成します。

2. 作成された「FtpFoler」で、アクセス権の設定を行います。 なお、 「継承可能なアクセス許可を親からこのオブジェクトに継承できるようにする」 のチェックを、外すことを忘れずに行ってください。 ここで設定したセキュリティが、FTPでログオンしたときのアクセス権となります。

3. 「インターネット サービス マネージャ」を開き、 「既定の FTP サイト」をマウスの右ボタンで選択します。

4. 表示されたコンテキストメニューから、「プロパティ」を選択します。 5. 表示された「既定の FTPサイトのプロパティ」から、「ホームディレクトリ」 タブをクリックします。

6. 「FTP サイトのディレクトリ」欄のローカルパスとして、「D:¥FtpFolder」 を指定します。

7. OKボタンを押下して、プロパティ画面を閉じます。

3.5 SSH (Secure Shell)

小規模サイトをとりまく脅威と現状 の章で説明したように、 UNIX の r 系コマンドや

telnet などといったものには、 盗聴、固有のセキュリティホール、 IP Spoofing といっ

た危険があります。

インターネットに限らず、組織のネットワークにおいて、 rcp や rsh を始めとする r 系

コマンドと呼ばれるものはまず使用されません。 r 系コマンドだけでなく、telnet さえあ

まり使用されなくなりました。

これらに代わるものとして、SSH(Secure SHell)と呼ばれるソフトウェアを使用します。

SSH は、標準で UNIX に実装されているものではありませんが、 特に r 系コマンド

(rlogin や rsh など)の代用、 そして telnet をはじめとする各種アプリケーションに使用

できます。

SSH は暗号化によって通信経路の安全を確保するソフトウェアです。

r系コマンドは共通して信頼関係のある相手に対しては認証を緩めます。 これに使

用されるファイルが/etc/hosts.equiv や.rhosts であり、 ここに記述されているホストが

信頼しえるホストであるかどうかの判断に使用されます。 これらのファイルに記述さ

れたホストは信頼できるホストであると判断し、 以降の認証が行われません。

それでは telnet は安全ではないのでしょうか？

答えは残念ながら YES です。

telnet を使用しリモートでログインした場合を考えてみましょう。この場合、全ての通

信は平文と呼ばれる目視可能な形式で通信を行います。つまり、いくらパスワードを

頻繁に変更しておいた場合であって、 パスワードを入力した端から知られてしまうの

です。 さらに、su コマンドで管理者になった場合、 管理者のパスワードも知られてし

まうことになります。

更に深刻な事を言うならば、 ネットワークのトポロジーがスター型であり、 なおか

つシェアードハブ等を使用している場合、 セグメント内部のどこからでもデータを取得

することができるようになります。 つまり、ユーザがログインするときのパスワードと、

su コマンドで管理者になったときのパスワードは全てセグメント内に流れており、 デ

ータを取得することができるのです。

このように、これまでの r 系コマンドや telnet は次の問題があります。

• パスワードが平文で流れる • データそのものも保護されていない • r系コマンドは認証が甘い

SSH を導入すると、これまで使用していた rlogin, rcp, rsh といったコマンドは使用す

る必要が無くなります。 その代わりに、SSH からは slogin, scp, ssh といったコマンドが

提供されます。 これらのコマンドは r 系コマンドより厳しい認証を行います。

さらに、パスワードの保護だけでなく、通信内容そのものもすべて保護されます。

これによって、上の 3 つの問題を解消することができるのです。

さらに、ポートフォワーディング機能と呼ばれるものを使うことにより、例えば POP3

や X11 といったものも SSH 経由で使用することができます。 これをフォワーティング

機能と呼びます。

SSHの種類

SSH は他のアプリケーションと異なり、 これまでの経緯から大きく分けて 3 種類存

在します。

• SSH1, SSH2 • OpenSSH • LSH

元々オープンソースのソフトウェアです。

しかし、SSH2 と呼ばれるバージョンで商利用に関してはライセンス費用が発生する

ことになりました。非商用目的のみに限って無償で利用できます。現在では、SSH

Communications Security 社 が開発およひライセンス提供を行っています。

ライセンス費用が発生することはビジネスの上では至極当然のことですが、 本来、

優れたセキュリティ製品は全ての OS に搭載され、 自由に利用できることが望ましい

のです。 しかし、暗号化製品においては特許などが障壁となってしまいます。

そこで、BSD 系の開発メンバーが集まり、 現在でもオープンソースとして公開されて

いる SSH1 を元にし SSH2 とほぼ同じ機能を持つソフトウェアを作成しました。 これが

OpenSSH です。

現在は暗号化に OpenSSL を使用するなどセットアップが若干煩雑ですが、 これも

順次整備される予定になっています。

SSHの設定

3.5.1 OpenSSH

3.5.2 Tera Tarm Pro と TTSSH

3.5.1 OpenSSH

OpenSSH は、OpenSSL のライブラリを使用します。

よって、OpenSSH をインストールするためには OpenSSL をインストールしておく必

要があります。

ただし、OpenBSD に関しては OpenSSL がシステムに含まれています。

FreeBSD は 4.1-RELEASE から含まれるようになりました。また、この時は CRYPTO

をインストールする必要がありましたが、4.1.1-RELEASE からは本体に含まれるよう

になりました。

http://www.openssh.com/

http://www.openssl.org/

OpenSSH は、サーバとクライアントのモジュールに分かれています。

(1) OpenSSH Server

OpenSSH をインストールする前に OpenSSL をインストールする必要があります。

OpenSSL のインストールは、Apache-SSL の項を参照願います。

OpenSSH をインストールすると/etc/ssh/sshd_config ファイルもインストールされま

す。 このファイルは次のようになっています。(コメント等を一部削除しています)

sshd_config例

Port 22 HostKey /etc/ssh/ssh_host_key HostDsaKey /etc/ssh/ssh_host_dsa_key ServerKeyBits 768 LoginGraceTime 120 KeyRegenerationInterval 3600 PermitRootLogin no ConnectionsPerPeriod 5/10 IgnoreRhosts yes StrictModes yes PrintMotd yes KeepAlive yes SyslogFacility AUTH LogLevel INFO RhostsAuthentication no RhostsRSAAuthentication no RSAAuthentication yes PasswordAuthentication yes PermitEmptyPasswords no CheckMail yes

通常の運用であれば、これだけで使用可能になります。

sshd を起動しクライアントから接続し確認してみます。

(2) OpenSSH Client

OpenSSH をインストールすると/etc/ssh/ssh_config ファイルもインストールされま

す。 このファイルは次のようになっています。

sshd_config例

# Host * # ForwardAgent yes # ForwardX11 yes # RhostsAuthentication yes # RhostsRSAAuthentication yes # RSAAuthentication yes # PasswordAuthentication yes # FallBackToRsh no # UseRsh no # BatchMode no # CheckHostIP yes # StrictHostKeyChecking no # IdentityFile ~/.ssh/identity # Port 22 # Protocol 2,1 # Cipher blowfish # EscapeChar ~

ssh クライアントは、このままでも使用可能になっています。サーバ側で特に変更が

無い限りはこのままで良いでしょう。では、試しに ssh でログインしてみましょう。ssh コ

マンドに続いてログイン先のホスト名を入力します。

sshを使用したログイン

% ssh mail.ipa-sec.com yamada@mail.ipa-sec.com's password: Last login: Tue Mar 6 22:23:38 2001 from www.ipa-sec.com Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.2-RELEASE (GENERIC) #0: Mon Nov 20 13:02:55 GMT 2000 Welcome to FreeBSD! You have new mail. %

(3) telnet の停止

ここまで確認できたところで、telnet は不要になります。

サーバ側の inetd.conf から telnet のエントリを削除し、inetd を再起動します。

#で telnetのエントリをコメントアウト

# telnet stream tcp nowait root /usr/libexec/telnetd telnetd

次に、inetd に kill -HUP シグナルを送ります。

なお、赤色で示したプロセス番号は毎回またはシステムによって異なるため、 必

ず事前に ps コマンド等で確認してください。

# ps -auwx | grep inetd yamada 252 0.0 0.5 1048 620 p0 S+ 10:59PM 0:00.01 grep inetdroot 111 0.0 0.6 1032 788 ?? Is 9:38PM 0:00.01 inetd -wW

# kill -HUP 111

これでこの UNIX システムに対して telnet による接続は行えなくなりました。 今後は

ssh コマンドまたは、Windows 環境では TTSSH を使用して接続するようにしてくださ

い。

(4) ポートフォワーディング

POP3 などでは、全てが平文で通信を行うためにユーザ名やパスワード、 そして取

込むメールの本文などが盗聴される可能性がありました。

パスワードに関しては APOP を使用することで回避できます。

しかし、これには APOP 対応のメールクライアントが必要になってきますし、 メール

本文は平文のままです。

APOP 以外にも SSH のポートフォワーディング機能を使用するという方法がありま

す。ここでは、このポートフオワーディング機能を紹介します。

たとえば、mail.ipa-sec.com のポート 110(POP3 のポート)をポート 8110 に転送し、

8110 との間で通信を行う場合を考えてみます。これには、ssh コマンドに-L オプション

を付けて使用します。

% ssh -L 接続ポート:相手ホスト:対象ポート 相手ホスト

それでは、mail.ipa-sec.com のポート 110 をポート 8110 に転送し通信を行う方法を見

てみましょう。

% ssh -L 8110:mail.ipa-sec.com:110 mail.ipa-sec.com

このように、ポートフォーワーディング機能を使用することによって、 暗号化された通

信経路を確保することができます。

3.5.2 Tera Tarm Pro と TTSSH

ここでは、Windows 2000 のクライアントから、 SSH にて Telnet Server に接続す

る手順を説明します。

Telnet Server に接続するターミナルエミュレーターとして、 Tera Term Pro を使用

します。

このソフトウェアは下記の URL から入手することができます。

http://hp.vector.co.jp/authors/VA002416/

このソフトウェアをインストールしただけでは、 SSH を使用した通信は行われませ

ん。

TTSSH というモジュールが必要です。次の URL から、ダウンロードできます。

http://www.zip.com.au/~roca/ttssh.html

なお、本書作成時点の 新版は、次の通りです。

ソフトウェア バージョン

Tera Tarm Pro 2.3

TTSSH 1.5.3

(1) Tera Tarm Pro と TTSSH のインストール

まず Tera Tarm Pro のインストールを行います。

1. ダウンロードしてきた、Tera Tarm Pro のファイルを任意のフォルダに展開。 2. setup.exeを実行。 3. 通常のアプリケーションと同じようにセットアップを行います。

以上で、Tera Tarm Pro のインストールは完了です。

次に、TTSSH のインストールを行います。

1. ダウンロードしてきた、TTSSHのファイルを任意のフォルダに解凍します。 2. 解凍後のファイルを、 Tera Tarm Pro をインストールしたフォルダにコピーします。

インストールは以上です。

通常、Tera Tarm Pro を起動するとき「ttermpro.exe」を実行しますが、 TTSSH を使

用するためには、「ttssh.exe」を実行します。頻繁に使う場合などは、スタートメニュー

のショートカットを変更してください。

(2) TTSSH を使用した Telnet Server への接続

1. Tera Tarm Proを「ttssh.exe」を実行することで起動します。 2. メニューの「ファイル」から、「New Connection...」を選択し、 新規接続画面を表示させます。 (Tera Tarm が起動されたときに、既に表示される場合があります。)

図 3.5.2-1 接続先のホスト名や IPアドレスを入力

3. 「TCP/IP」の欄の「Host」の欄に、 接続先の Telnet Serverのアドレスを入力します。

4. 「Service」から、「SSH」を選択し OKボタンを押下します。 5. 表示された画面にて、通常 Telnet Serverにログインするユーザ名と、 パスワードを入力します。

図 3.5.2-2 sshの認証を行うためのユーザ名とパスワードを入力

以上で、SSH を使用した通信が行われます。

3.6 HTTP

Web サイトにおける要は httpd および WWW サービスです。

これらに対して適切な設定を行うこと、および不必要な設定を行わないことが も

重要な部分となります。

もちろん、これを行っても DNS Spoofing などの被害は免れません。 つまり、HTTP

単体でセキュリティを確保するだけでは攻撃を食い止めることはできないのです。だ

からと言って、HTTP の設定を放置するわけにはいきません。 出来る限りの設定を行

った上で、他の部分の対策をとらなければならないのです。

ここでは、UNIX システムにおいて多く使用されている Apache と、 Windows 2000 に

おいて標準で添付されている WWW サービスの設定について解説します。

• 3.6.1 Apacheのセキュリティ設定 • 3.6.2 Microsoft WWWサービスのセキュリティ設定

3.6.1 Apache の設定

現在 UNIX システムにおいて も多く使われているであろう httpd は Apache です。

Apache の設定を行うファイルは、従来のバージョンでは httpd.conf, access.conf,

srm.conf の 3 本に分かれていましたが、現在のバージョンでは httpd.conf に一本化さ

れています。

今回取り上げるバージョンは 1.3.19 です。

以前のバージョン(1.0.3 以前)では、phf によってパスワードファイルを取得すること

ができましたが、現在ではこれは出来ないようになっています。

(1) phf 攻撃

phfとは、NCSA httpd やApache に添付されていたCGICommon Gateway Interface)

のスクリプトです。 実際に使用しなくとも非常に危険なスクリプトとされています。

なぜなら、このスクリプトを参考にして作成されたスクリプトにも同じ危険が潜んで

いるからです。

phf 攻撃は、phf がインストールされているサーバーに対し、いくつかのコマンドを記

述した URL を送ることによって、相手のサーバが URL として渡されたコマンドを実行し

てしまいます。これによって、パスワードファイルが Web クライアントに表示されるとい

ったことがありました。

つまり、phf 攻撃は URL にコマンドを記述することができる人であれば、 Web クライ

アントだけでパスワードファイルを閲覧することができたのです。現在では NCSA

httpd, Apache 共に、このファイルの添付は行っていません。

もし、従来からの OS や httpd をアップグレードし続けたサーバであれば、cgi-bin デ

ィレクトリに phf が存在しないか確認してください。

残っているようでしたら速やかに削除しログの確認等を行ってくだい。 特に、ログ

の中で GET メソッドのステータスコードが 200 の場合はパスワードファイルの取得が

成功している可能性があるため、全ユーザのアカウントリセットなどを行うようにしてく

ださい。

(2) 実行するユーザ

httpd をセキュアな環境に設定するための第一歩は実行するユーザを正しく設定す

るということです。

これは httpd.conf の次の項目で設定します。

User nobody Group #-1

デフォルトでユーザは nobodyに設定されています。 もし、nobodyが他に動かすものが無ければこのままで良いでしょう。しかし、nobodyで他に動作するプログラムがあるならば、別のユーザ権限で動作させるべきです。 ここで言う別のユーザとは、既存のユーザに変更するのではなく、 httpd を起動する以外は何も起動しないユーザ、つまり新規で作成します。 たとえば、apacheというユーザを作成し、この権限で動作させます。 このユーザに対して、httpd を起動するだけ必要最小限度の権限のみを付与しておけば、 もしこのユーザの情報が漏れてもシステム全体に影響することはありません。

(3) ドキュメントディレクトリ

Web において httpd の動作に次いで重要なものがドキュメントディレクトリの設定で

す。

デフォルトではドキュメントルートが次のように設定されています。

このディレクトリの権限を正しく設定する必要があります。 もちろん、必要以上に権

限を出してはいけません。 外部からの攻撃だけでなく、内部から誤ってデフォルトド

キュメント(index.html など)を書き換えてしまったという事故も有り得ます。特に 上位

のデフォルトドキュメントは、組織のホームページとなる部分です。この部分を間違っ

て書き換えてしまう、または外部から改竄されてしまうということのないように設定して

ください。

DocumentRoot "@@ServerRoot@@/htdocs"

次に、ドキュメントルートのオプションを確認します。

デフォルトでは次のように設定されています。

Options FollowSymLinks ここには、絶対に Indexesを書き加えてはいけません。 なぜなら、何らかの理由でデフォルトドキュメント(index.htmlなど)を httpdが認識しなくなったとき、ディレクトリ中の一覧を表示してしまいます。 最上位のディレクトリに限らず、Indexes の利用は必要最小限度に留めておくべきです。 たとえば、あるディレクトリでファイルの一覧を手作業で作成せずに必要なファイルをユ

ーザが取得するといった運用を行うページ以外では Indexes の使用を避けるようにしてください。

Indexes を使用しなくとも、悪意を持ったユーザがファイル名を推測し取得しようとす

る場合があります。

このファイルは主に次の 3 つです。

• .htaccess • .htpasswd • .htgroup

.htaccess は、各ディレクトリごとにユーザが任意に動作を決めるもので、 アクセス

制限等に使用される場合が多いようです。

その他の 2 つは、基本認証において使用されます。

これらは、Apache が提供するデフォルトのファイル名を使用する場合が多く、 これ

らのファイルが第三者に取得されるケースが少なくありません。

あらかじめ、httpd.conf や各.htaccess でアクセス制御を行っておくべきです。

.htaccessの例

<FilesMatch "^¥.(htaccess|htpasswd|htgroup)$"> order allow,deny deny from all </FilesMatch>

また、この場合、そもそも.htpasswd や.htgroup をドキュメントツリーの中に置くことが

良くありません。これら認証に使用するファイルは、組織外のユーザに対しサービスを

行っているなどのサーバ以外では必ずドキュメントツリー外に置くようにしてください。

(4) アクセス制御ファイル

先に説明した FileMatch によってユーザの認証や参照できるネットワークなどを制

限することができます。

ユーザの認証は基本認証(ベーシック認証とも呼ばれる)が使用されますが、 参照

するクライアントが属するネットワークが限定されている場合、 IP アドレスやドメイン

名で制限するほうが確実です。 なぜなら、基本認証を使用すると、ユーザ名やパス

ワードを盗聴される可能性があるからです。

たとえば、社外に出て一般の ISP から接続する営業マンが居る環境では、不特定

のネットワークから特定のユーザが接続することとなります。この場合は基本認証で

行うしかありません。この場合は SSL などを使用するべきでしょう。

ネットワーク単位で指定する場合は次のように行います。

192.168.0.0/24 のネットワーク全体、および ipa-sec.com 全体、そして 172.16.0.1 の

ホストが接続できるようにするためには次のように設定します。

参照可能なクライアントを制限した例

<LIMIT GET POST> Order deny,allow Allow from 192.168.0. .ipa-sec.com 172.16.0.1 Deny from all </LIMIT>

このようにして httpd.conf または.htaccess に記述します。これは、ディレクトリ単位

で有効になるため、ユーザが作成したディレクトリごとや、Web サーバ全体としてのポ

リシーを検討の上設定するようにしてください。

(5) .htaccess の禁止

httpd.conf において、Option と共に記述されたディレクトリごとの設定は、

httpd.conf を書き換えることなく各ディレクトリにおいて.httaccess ファイルを記述する

ことによって任意に変更することができます。

しかし、各ディレクトリ内で変更させないということが行えます。 これには、以下の

記述を httpd.conf に追加します。

httpd.confで.htaccessを使用させないようにする

<Directory /> AllowOverride None Options None allow from all </Directory>

この設定によって、.htaccess は無効となり、管理者が設定したディレクトリの設定で

動作することとなります。

(6) SSI

Apache では SSI(Server Side Include)が利用できるようになっています。

しかし、これはイントラネットなどの限られた環境以外では無効にすべきです。

特に、SSI を使用した EXEC 命令は各種の危険が伴います。 このため、

IncludesNoExec を設定しておく必要があります。

Options IncludesNoExec

3.6.2 Microsoft Web サービスのセキュリティ設定

(1) Web サービスの準備

IIS をインストール後、最新のセキュリティパッチの適応を、 絶対に忘れないようにしてください。 多発する不正なアクセスを使用したコンテンツ改竄のトラブルは、 IISが持っているセキュリティホールを狙ったものがほとんどです。

Windows 2000 インストール関連でも紹介しましたが、 マイクロソフト社が発信する下記のセキュリティ情報を、最低 1日ごと、 できればそれ以上の短いサイクルで確認するようにしてください。 http://www.asia.microsoft.com/japan/technet/security/current.asp

(2) 不要な仮想ディレクトリの削除

IIS をインストールした場合、デフォルト状態でいくつかのかの、 仮想ディレクトリが

作成されています。

仮想ディレクトリとは、まったく別の場所にある物理ディレクトリを、 Web サイトのホ

ームディレクトリのサブディレクトリとして割り当て、 あたかもそこに存在するように見

せるものです。 これら仮想ディレクトリには、それぞれのアクセス権を指定できるので、

非常に便利な機能といえます。

インストール時に自動作成された仮想ディレクトリには、 「実行アクセス権」として

「スクリプトおよび実行可能ファイル」の権限が、 与えられているものもあります。 (実

行アクセス権の詳細については後述を参照してください。)

この仮想ディレクトリに不正なアクセスが行われた場合、 「スクリプトおよび実行可

能ファイル」権限を悪用されることは十分考えられます。 特に、&quot 実行可能ファイ

ル&quot の実行アクセス権によって、 予想をはるかに越えるトラブルを起こすかもし

れません。

そこで、特にデフォルトとして作成されているディレクトリで不要なものは、 削除す

ることを強く勧めます。

以下に、不要とと思われるデフォルト時の仮想ディレクトリを、掲載します。

表 3.6.2-1 不要な仮想ディレクトリ

仮想ディレクトリ名

IISHelp

IISSamples

MSADC

Printers

なお、上記以外に「IISAdmin」という仮想ディレクトリが作成されている場合がありま

す。

Internet Explorer でこのディレクトリにアクセスすると、 IIS をブラウザ上で管理する

ことができます。 デフォルトでは、この機能はサーバ自身からアクセスした場合のみ

に使用可能ですが、 設定の変更により、インターネット上どこからでも IIS を管理でき

るようになります。 この機能が必須な環境でなければ、 この仮想ディレクトリも削除

してください。

(3) 不要なアプリケーション マッピングの削除とオプションの変更

1. 「インターネット サービス マネージャ」にて、 Webサイトのディレクトリ(仮想ディレクトリ)のプロパティ画面を開きます。

2. 表示されたプロパティ画面から「ホームディレクトリ(仮想ディレクトリ)」 タブを

選択し、 「アプリケーションの設定」欄の「構成」ボタンを押下します。

図 3.6.2-1 Webサイトのプロパティ

3. 表示された「アプリケーションの構成」の「アプリケーションのマッピング」 リストで、不必要な項目を選択し削除します。 以下の表は、不要と思われる項目です。これ以外においても、 不要と判断されるものについては、削除するようにしてください。 これらを削除しておくことで、悪意のある攻撃方法が新たに発見された場合に、 サイトの危険を少しでも減らすことができます。

表 3.6.2-2 不要な拡張子

不要と思われる項目(拡張子)

.htw

.ida

.idq

.cer

.cdx

.htr

.idc

.shtml

.stm

4. 必要な項目については、一覧より選択後、「編集」ボタンを押下します。 5. 表示された「アプリケーションの拡張子マッピングの追加/編集」画面から、 「ファイルの存在を確認する」にチェックをつけ、OKボタンを押下します。

図 3.6.2-2 拡張子との関連付け

6. 「アプリケーションの構成」画面に戻り、「アプリケーションのオプション」 タブをクリックします。

7. 「親のパスを有効にする」のチェック外し、 OKボタンを押下して画面を閉じます。

図 3.6.2-3 親のパスを有効にし終了

(4) Web ディレクトリのアクセス権

各 Web ディレクトリごとに、アクセス権を指定できます。

設定画面は、以下の手順で表示します。

1. 管理ツールより、「インターネット サービス マネージャ」を開きます。 2. Web ディレクトリのアクセス権を指定するフォルダの、 プロパティ画面を開きます。

3. プロパティ画面上で、「ホームディレクトリ(仮想ディレクトリ)」 タブをクリックします。

次に、アクセス権を指定します。

以下に、アクセス権に関する項目とその内容を解説します。

表 3.6.2-2 アクセス権一覧

項目名 内容 推奨の設定

スクリプトソース アクセス

ASP 等のスクリプトソースを、ブラウザー上から参照できるようにします。

チェックを外します。ソースが公開される

ことは大変危険です。

ログアクセス ディレクトリへのアクセスを、ログファイルに記

録します。 チェックを付けます。

読み取り ディレクトリへのアクセスとして、読み取りを可

能にします。 チェックを付けます

このリソースに索引を

付ける

Microsoft Indexing Service を使用しているときの、Web サイトのフルテキストインデックスボックスに入れます。

チェックを外します。Indexing Serviceを使用している場合も、予期せぬ情報漏洩

を防ぐために、外すことをおすすめしま

す。

書き込み サーバへの書き込み機能をサポートするブラウザ

において、ファイルなどの書き込みができるよう

にします。

チェックを外します。データの改竄の原因

になります。

ディレクトリの参照 ディレクトリ内の、ファイル一覧をブラウザ上で

表示できるようにします。 チェックを外します。通常は表示されない

はずのページにアクセスされる可能性が

あり、情報漏洩の危険があります。

なし HTML や画像ファイルなど、静的なファイルのみにアクセ

スを許可します。

スクリプトのみ ASP 等のスクリプトのみの実行を許可します。

実行アクセス権

スクリプト および 実行可能ファイル

全てのファイルアクセスと、

アプリケーションの実行を許

可します。

必要に応じて設定を行います。Web アプリケーションを使用しない場合は、「なし」

を選択します。 「スクリプトおよび実行可能ファイル」を

選択しておけば、サービス性は高くなりま

すがセキュリティ・レベルは低くなりま

す。

低 (IIS プロセス)

Web サーバサービスと同じプロセスで実行させます。

中 (プール)

既に実行されている、他の

Web アプリケーションと同じプロセスで実行させます。

アプリケーション保護

高 (分離プロセス)

他のプロセスから分離され

た、独立プロセスで実行させ

ます。

必要に応じて設定を行います。「高(分離プロセス)」を選択すれば、１つアプリケーションがクラッシュなどの問題を起こし

ても、Web サービスや他のアプリケーションに影響を避けることができ、DoS 攻撃対策になります。

(5) 認証済みアクセス

普段のブラウザによる Web サーバへのアクセスは、 匿名アクセスとして扱われま

す。

匿名アクセスでは、これに割り当てられた Windows ユーザアカウントを使用し、 サ

ーバ内のフォルダにアクセスが行われます。

よって、全ての人に Web コンテンツを参照してもらうには、 それを公開するフォルダに

匿名アクセス用ユーザ アカウントに読み取り許可のアクセス権が必要です。 なお、

ここでいうアクセス権限とは、NTFS アクセス制御のことであり、 エクスプローラなどで

ファイルやフォルダを選択し、 これらのプロパティ画面から設定するセキュリティのこ

とです。

対して、匿名アクセス用の読み取り許可が与えられていないフォルダに Web ブラウザ

からアクセスすると、 ブラウザー上には、ユーザ名とパスワードの入力を要求するダ

イアログが表示されます。

この場合、フォルダへのアクセス許可がある Windows ユーザ アカウントの名とパ

スワードを入力することで、アクセスが可能になるのですが、デフォルトの設定では

Internet Explorer からのみ可能となります。

これを、ブラウザに関係なく行うためのの手順を、以下に説明します。

1. Webサイトのプロパティを開きます。 2. 「ディレクトリ セキュリティ」タグをクリックし、 「匿名および認証コントロール」の欄の「編集」ボタンを押下します。

3. 表示された「認証方法」画面にて、「認証済みアクセス」の欄にある、 「基本認証」のチェックボックスにチェックを付けます。

以上で、ほとんどのブラウザでの認証済みアクセスが可能になります。

ただし、ユーザ名とパスワードが暗号化されずに通信されるため、 セキュリティレ

ベルが低くなります。

この問題を解決し、ブラウザの種類に関係なく、 ユーザ名とパスワードを暗号化に

よって通信するためには、 SSL を使用してください。

(6) コンテンツ公開用のフォルダを変更する

既定のディレクトリを、そのままコンテンツ公開用とするのではなく、 別ドライブにフ

ォルダを作成し、それを公開用として割り当てます。

これは、システムディレクトリから切り離すことにより、 攻撃によるダメージを少しで

も軽減することを目的とします。

これから解説する例では、「D:」ドライブにコンテンツ公開用フォルダ「WebFolder」

を作成し、「インターネット サービス マネージャ」にて、 このフォルダをWebサーバの

ルートディレクトリとして割り当てるものです。

コンテンツ公開用フォルダを作成

1. エクスプローラなどで、「D:¥」ドライブに「WebFolder」という名前の、 フォルダを作成します。

2. 作成された「WebFoler」で、以下のセキュリティ設定を行います。

表 3.6.2-3 公開用フォルダのアクセス権

名前 アクセス許可

(チェックされた許可項目) 備考

Administrators フルコントロール 公開用フォルダの管理と、コンテンツそのものの更新

を行います。コンテンツの変更者とフォルダの管理者

が異なる場合など、必要に応じてユーザを追加し、そ

れぞれ設定してください。

SYSTEM フルコントロール Windowsがアクセスするために必要です。

Authenticated Users 読み取りと実行

フォルダの内容の一覧表示

読み取り

「Authenticated Users」は、「Everyone」グループとほぼ同等です。よって、匿名アクセス用のWindows ユーザ アカウント以外も含まれます。より厳しいセキュリティ設定としては、匿名アクセス用のアカウン

トのみを設定します。

3. なお、「継承可能なアクセス許可を親からこのオブジェクトに継承できるようにする」のチェックを、外すことを忘れずに行ってください。

図 3.6.2-4 公開用フォルダのアクセス権

以上で、公開用のフォルダの準備は完了しました。

次に、「インターネット サービス マネージャ」にて、公開用のフォルダを、 Web サ

ービスのホームディレクトリとして割り当てます。

1. 「インターネット サービス マネージャ」を開き、 ホームディレクトリ(既定のWebサイト)のプロパティ画面を開き、 「ホームディレクトリ」タグをクリックします。

2. 「ローカル パス」の欄に、新しく作成した公開用フォルダのパスを入力します。 なお、「参照」ボタンを押下しフォルダの参照画面にて設定できます。

以上で、コンテンツ公開用のフォルダのの変更が完了しました。

3.7 SSL

Web サイトにおいて、たとえば通信販売などを行うサイトを構築した場合、 個人情

報や決済において盗聴されることを防がなければなりません。

ここでは、Webサイトにおけるサーバとクライアント間の暗号化に使用するSSLにつ

いて解説します。

(1) 公的 CAの利用

公的 CA とは、証明書の発行を行う第三の CA のことを指します。 社会的な信頼が

必要な場合や不特定多数のユーザーがアクセスするようなサイトの場合は、 公的

CA に証明書の発行を依頼した方がよいと思います。 ただし、公的 CA に依頼した場

合、証明書の発行にある程度の費用と期間が必要となりますので、 予算および運用

の開始等への影響を予め考慮した上で依頼を行って下さい。 代表的な公的 CA とし

て、VeriSign 社等があります。

ここでは、公的 CA として VeriSign 社を利用した場合の手順を説明します。 公的

CA を利用した場合に Web サイト側で行う作業は、以下の通りです。

1. サーバー証明書要求の作成 2. 公的 CAへのサーバー証明書要求の送信 3. サーバー証明書のインストール 4. Webサイトの SSL暗号化通信の設定

注意点として、上記設定を行う前に、予めドメイン名の登録を済ませておいて下さい。

本書では、公的 CA を使用した場合とそうでない場合を例にとり記述します。

(2) 設定方法

• 3.7.1 Apacheと OpenSSL • 3.7.2 IIS Webサイトの SSL暗号化通信の設定

3.7.1 Apache-SSL

Web サイトにおいて SSL を使用する場合、いくつかの選択肢があります。

ここでは、httpd に Apache を使用し Apache-SSL で SSL 環境を作成します。

Apache を使用する場合は、OpenSSL 以外にも選択肢がありますが、 SSH の項に

おいても使用することから OpenSSL を採用します。

設定までの方法が判り辛い点もあるため、簡単なインストール方法を含めて解説し

ます。

(1) OpenSSL の設定

まず、Apache-SSL を設定するには OpenSSL を使用します。 これは、Apache-SSL

が OpenSSL のライブラリを使用するためです。

このため、あらかじめ OpenSSL をインストールしておく必要があります。 SSH の解

説においても OpenSSL のライブラリを使用するため、 ここでインストールしておいてく

ださい。

ソースは http://www.openssl.org/から入手可能です。

なお、Apache1.3.12+ssl1.39 で使用する OpenSSL のバージョンは 0.9.5a です。

OpenSSL はバージョンアップも頻繁に行われているため、バージョンの不一致に注意

してください。

% ./config % make % make test # make install CAの作成

インストールが行われると次は CA の作成です。

もし、外部の CA から証明書がされた場合はこの設定作業は行う必要がありませ

ん。

% cp /usr/local/ssl/openssl.cnf . % cp /usr/local/ssl/misc/CA.sh . % ./CA.sh -newca

CA.sh -newca によって CA を作成します。 秘密鍵のパスフレーズや DN の情報な

どが聞かれ、問題なければ CA の証明書や管理用ファイルが作成されます。

表 3.7.1-1 OpenSSL関連のファイル

cacert.pen CAの自己署名証明書

serial 証明書発行のシリアル番号

newcerts 発行した証明書格納ディレクトリ

private 秘密鍵格納ディレクトリ

次は、CSR を作成します。

% ./CA.sh -newreq

CSR が作成されると CA によって署名を行います。

このときに、パスフレーズを入力し、問題なければ証明書の確認が行われます。

% ./CA.sh -sign

全て問題なく終了すると newcert.pem という名前でユーザの証明書が表示され、

ファイルが作成されます。

Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: md5WithRSAEncryption Issuer: C=JP, ST=Tokyo, L=Bunkyo, O=IPA-SEC, OU=SEC, CN=Yamada TARO 08¥x08/Email=yamada@ipa-sec.com Validity Not Before: Mar 6 11:49:12 2001 GMT Not After : Mar 6 11:49:12 2002 GMT Subject: C=JP, ST=Tokyo, L=Bunkyo, O=IPA-SEC, OU=SEC, CN=Suzuki JIRO/Email=suzuj¥x08ki-ipa-sec.com Subject Public Key Info:

Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:dd:47:1b:90:fd:25:0f:d6:16:e7:1a:6e:49:71: d5:4e:4f:a4:cc:b2:73:fe:2f:73:72:27:ae:2b:00: 9e:b1:dd:88:4e:39:d1:db:d2:4b:21:3b:46:5d:ca: de:ee:83:b9:0a:c8:3c:c3:97:9e:84:98:f9:a2:da: f5:c2:5a:f5:7e:3c:88:4c:fb:32:e7:6f:98:6e:c8: 86:fb:7d:e3:72:01:5c:b8:e7:1d:ff:cf:69:17:bd: 45:d6:7d:47:4a:e3:9b:ad:aa:dc:2c:22:3e:22:41: 92:d8:2d:2a:c4:5b:60:c0:b2:3b:8d:2a:df:9f:d9: f8:d4:d8:b9:94:d4:b7:be:bb Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 5B:5B:0F:77:62:13:70:A2:F2:34:4B:72:FE:B0:C0:AC:53:2C:13:F6 X509v3 Authority Key Identifier: keyid:08:90:16:06:28:53:8C:62:F5:15:02:55:00:99:E7:78:F1:E7:08:8 A DirName:/C=JP/ST=Tokyo/L=Bunkyo/O=IPA-SEC/OU=SEC/CN=Yamada TAR¥x 08¥x08¥x08/Email=yamada@ipa-sec.com serial:00 Signature Algorithm: md5WithRSAEncryption 14:08:a2:f1:3e:b0:2c:fd:1e:22:68:d3:ad:eb:29:06:dd:fe: fc:7f:25:7d:aa:82:31:86:80:c8:df:f5:8e:7a:c6:da:31:90: 84:e0:75:f4:23:59:e5:f9:1a:b5:89:1c:4a:43:d0:8f:d6:fe: aa:3e:50:a8:bb:07:56:09:ce:be:d3:4d:08:05:11:df:3b:82: 29:46:37:36:37:47:1c:34:43:9a:be:02:28:4e:11:5e:e7:a3:

10:9c:83:59:e9:d5:30:17:d3:70:2f:7d:c5:3c:31:8e:72:51: dc:09:13:f9:5c:01:7e:fc:80:c6:fb:ba:35:21:cf:8a:7c:1f: d1:47 -----BEGIN CERTIFICATE----- MFdg4zCCAwygAwIBAgIBATANBgkqhkiG9w0BAQQFADCBiTELMAkGA1UEBhMCSlAx DjAMBgNVBAgTBVRva3lvMQ8wDQYDVQQHEwZCdW5reW8xEDAOBgNVBAoTB0lQQS1T RUMxDsfKBgNVBAsTA1NFQzEWMBQGA1UEAxQNWWFtYWRhIFRBUggICDEhMB8GCSqG SIb3DQEJARYSeWFtYWRhQGlwYS1zZWMuY29tMB4XfsTAxMDMwNjExNDkxMloXDTAy MDMwNjEcccsxMlowgYsxCzAJBgNVBAYTAkpQMQ4wDAYDVQQIEwVUb2t5bzEPMA0G A1UEBxMGQnVua3lvMRAwDgYDVQQKEwdJUEEtU0VDMfasafYDVQQLEwNTRUMxFjAU BgNVBAMUDVN1enVrb2kIIEpJUk8xIzAhBgkqhkiG9w0BCQcsGZN1enVqCGtpLWlw YS1zZWMuY29tdsffMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7RxuQ/SUP1hbn Gm5JcdVOb6TMsnPuL3NyJ64rAJ6x3IhOOdHb0kshO0Zdyt7ug7kKyDzDl56EmPmi 2vXCWvV+PIZM+zLnb5huyIb7feNyAVy45x3/z2kXvUXWfUdK45utqtwsIj4iQZLY LSrEW2DAsjuNKt+vcsjU2LmU1Le+uwIDAQABo4IBFTCCAREwCQYDVR0TBAIwADAs BglghkgBhvhCAQ0EHxYdT3ujtyxfxFBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYD VR0OBBYEFFtbD3diE3Ci8jRLcv6wwKxTLBP2MIG2BgNVHSMEga4wgauAFAiQFgYo U4xi9RUCVQCZ53jx5wkjhkGPpIGMMIGJMQswCQYDVQQGEwJKUDEOMAwGA1UECBMF VG9reW8xDzANBgNVBAcTBkJ1bmt5bzEQMA4GA1UEChMHSVBBLVNFQzEMMAoGA1UE CxMDU0VDMRYwFAYDVQQDFA1ZYW1hZGEgVEFSCAgIMSEwHwYJKoZIhvcNAQkBFhJ5 YW1hZGFAaXBhLXNlYy5jb22CAQAwDQYJKoZIhvcNAQEEBQADgYEAFAii8T6wLP0e ImjTrespBt3+/H8lfaqCMYaAyN/1jnrG2jGQhOB19CNZ5fkatYkcSkPQj9b+qj5Q qLsHVgnOvtNNCAUR3zuCKUY3NjdHHDdhffGrKE4RXuejEJyDWenVMBfTcC99xTwx jnJR3AkT+VwBfvyAxvu6NSHPinwf0Uc= -----END CERTIFICATE-----

(2) Apache-SSL の設定

OpenSSLのライブラリがインストールできるとApacheのソースを展開します。 通常

は、ここで configure を行いますが、その前に Apache-SSL のパッチを充てます。

Apache-SSL のパッチは http://www.apache-ssl.org/から入手できます。

なお、Apache のバージョンと Apache-SSL のバージョンを必ず合わせるようにしてく

ださい。本書作成時点での 新は、Apache1.3.12+ssl1.39 です。Apache は 1.3.17 が

新ですが、Apache-SSL に合わせて Apache1.3.12 を使用してください。

http://www.apache.org/

http://www.apache-ssl.org/

% gzip -d < apache_1.3.12.tar.gz | tar xvf - % cd apache_1.3.12 % gzip -d < ../apache_1.3.12+ssl_1.41.tar.gz | tar xvf - % ./FixPatch % ./configure % ./make % ./make install

インストールが終了すると、httpd.conf の設定を行います。

SSL に関する設定は以下の部分です。途中のコメントや httpd としての動作を記述

したもの以外を抜粋しました。

ここでの設定に必要なものは、サーバ証明書とサーバ秘密鍵です。 そして、CA か

ら発行された CA 証明書の 3 点が必要になります。 これは、上の CA の設定を参照し

てください。

httpd.conf例(抜粋)

Port 443

SSLEnable

SSLRequireSSL

SSLCacheServerPath /usr/local/apache-ssl/bin/gcache

SSLCacheServerPort logs/gcache_port

SSLVerifyClient 3

SSLVerifyDepth 10

SSLCacheServerRunDir /tmp

SSLSessionCacheTimeout 15

SSLCertificateFile /usr/local/apache-ssl/certs/https.cert.cert

SSLCertificateKeyFile /usr/local/apache-ssl/certs/https.cert.key

SSLCACertificateFile /usr/local/apache-ssl/certs/httpsd.pem

今回 SSL で使用するポートは 443 を使用する設定になっています。 他のポートを

使用する場合は Port を書き換え Apache を再起動してください。

3.7.2 IIS Web サイトの SSL 暗号化通信の設定

(1) SSL の設定

サーバー証明書要求の作成

サーバー証明書要求は、 [インターネットインフォメーションサービス]から作成しま

す。 タスクバーの[スタート]ボタンをクリックし、 [プログラム(P)]-[管理ツール]-[イン

ターネットインフォメーションサービス] を選択すると、 [インターネットインフォメーショ

ンサービス]が起動します。 [インターネットインフォメーションサービス]ウインドウの

左ペインにて、 SSL 暗号化通信を設定したい Web サイトを右クリックして、 [プロパテ

ィ(R)]を選択します。ここでは、[既定の Web サイト] に SSL 暗号化通信を設定するの

で、 [既定の Web サイト]のプロパティを開きます。

次に、Web サイトのプロパティの[ディレクトリセキュリティ]タブをクリックし、 [サーバ

ー証明書(S)...]ボタンをクリックします。

図 3.7.2-1 Webサイトのプロパティでサーバー証明書をクリック

サーバー証明書ウィザードが起動します。 [次へ>]ボタンをクリックして下さい。

証明書の割り当て方法を選択します。 ここでは、新規にサーバー証明書を作成す

るので、 [証明書の新規作成(C)]を選択します。

図 3.7.2-2 証明書の新規作成

要求の送信方法を選択します。

ここでは、後で要求を送信するので、 [証明書の要求を作成して後で送信する(P)]

をチェックして下さい。

図 3.7.2-3 要求の送信方法選択

証明書の名前と暗号化キーのビット長を設定します。 ここでは、名前を「既定の

Web サイト」、ビット長を 512 ビットとします。

証明書の強度を上げたい場合は、より大きなビット長に設定して下さい。

図 3.7.2-4 証明書の名前を入力する

組織名と部門名を設定します。 ここでは、架空の組織である「IPA-sec」と架空の

部門である「Web Publishing」 を設定します。

図 3.7.2-5 組織名と部門名を入力

サイトの一般名を設定します。 サイトの一般名とは、Web サイトのドメイン名のこと

です。 ここでは、本書で例として取り上げている架空の"www.ipa-sec.com"を設定し

ます。

図 3.7.2-6 主にWebサーバ名を入力する

地理情報を設定します。 ここでは、国/地域を「JP(日本)」、都道府県を「Tokyo」、

市区町村を「Bunkyo-ku」とします。

図 3.7.2-7 地域情報を英数字で入力

証明書要求の内容を出力するファイルを設定します。

図 3.7.2-8 要求ファイル名を入力

ここまでの設定内容が表示されます。問題がなければ、 [次へ>]ボタンをクリックし

て下さい。

[完了]ボタンをクリックすれば、サーバー証明書要求の作成は完了です。 証明書

要求の内容がファイルに出力されていることを確認して下さい。

公的 CAへのサーバー証明書要求の送信

上記で作成したサーバー証明書要求を公的 CA に送信します。

ここでは、公的 CA として、VeriSign 社を利用した場合の手順について説明します。

VeriSign 社の場合、 VeriSign 社のホームページ からサーバー証明書要求の送信が

可能です。

なお、以降の説明は、VeriSign 社へサーバー証明書の発行を依頼するための手順

の一部だけを説明しているため、 必ず VeriSign 社のサーバ ID センター を参照し、

全体の流れやその他必要な手続き等を確認してから実施して下さい。

このホームページ内にあるセキュアサーバーID 登録申請手順ページから、 緑色

の[今すぐ登録申請！]ボタンをクリックして下さい。

図 3.7.2-9 申請手順

[ウェブからの登録申請]ページが表示されます。 このページに一通り目を通した

後、ページの下の方にある[セキュアサーバーID]もしくは[グローバルサーバーID]を

選択して、 [Continue]ボタンをクリックします。

ここでは、[セキュアサーバーID]を選択します。

図 3.7.2-10 グローバルサーバーIDの選択

[CSR の提出(セキュアサーバーID)]ページが表示されます。 このページの下の方

にある[CSR の貼り付け]テキストボックスに、 上記で作成したサーバー証明書要求フ

ァイルの内容をコピーして貼り付け、 [Continue]ボタンをクリックします。

図 3.7.2-11 先に作成した CSRを貼付ける

[セキュアサーバーID 登録申請情報の入力]ページが表示されます。 ここに、サー

バー証明書要求の内容が表示されます。 もし、内容が表示されなかったり、表示さ

れた内容に誤りがある場合は、サーバー証明書要求の作成に戻り、 再度サーバー

証明書要求の作成からやり直して下さい。

図 3.7.2-12 要求の内容を確認

続いて、申請情報の入力を行い、登録申請書を作成し、同意することでサーバー

証明書要求の送信は完了です。

残りの申請手続きを完了させた後、約 4～5 営業日後に、 VeriSign 社からサーバ

ー証明書を含むメールが送られます。 メールから、サーバー証明書のテキストを抜

き出し、 サーバー証明書ファイルとして保存して下さい。 なお、ファイル名には、拡

張子&.cer&amp を付けて下さい。

サーバー証明書のインストール

サーバー証明書要求を作成した Web サイトのプロパティの[ディレクトリセキュリテ

ィ]ページから、 [サーバー証明書(S)...]ボタンをクリックします。

サーバー証明書要求の作成時と同じように、 サーバー証明書ウィザードが起動し

ます。

[次へ>]ボタンをクリックして下さい。

サーバー証明書要求の作成時には、証明書の割り当て方法の選択だったページ

が、 保留中の証明書の要求の選択のページに切り替わっています。 ここで、[保留

中の要求を処理し、証明書をインストールします(P)]を選択します。

図 3.7.2-13 証明書をインストールする

証明機関の応答ファイルのパスとファイル名を入力します。 証明機関の応答ファ

イルとは、サーバー証明書のことです。 ここでは、上記でファイルとして保存したサー

バー証明書へのパスとファイル名を指定します。

図 3.7.2-14 受け取った証明書ファイルを指定

サーバー証明書の設定内容が表示されます。[次へ>]ボタンをクリックして下さい。

[完了]ボタンをクリックすれば、サーバー証明書のインストールは完了です。

Web サイトのプロパティの[ディレクトリセキュリティ]ページから、 [証明書の表示

(V)...]ボタンをクリックし、 サーバー証明書が正しくインストールされていることを確認

して下さい。

Webサイトの SSL暗号化通信の設定

サーバー証明書をインストールした Web サイトのプロパティの[ディレクトリセキュリ

ティ]ページから、 [編集(D)...]ボタンをクリックします。

[セキュリティ保護された通信]ダイアログが表示されます。 SSL 暗号化通信を有効

にするには、[保護されたチャンネル(SSL)を要求する(R)]をチェックした後、 [OK]ボタ

ンをクリックして下さい。

図 3.7.2-15 IISに SSLの設定を行う

以上で、公的 CA を利用した Web サイトの SSL 暗号化通信の設定は完了です。

(2) 独自 CA の構築と設定

Microsoft 証明書サービスを利用すると、 VeriSign 社のような公的 CA とは別に独

自の CA を設けることができます。 独自 CA は、機能的には公的 CA と変わりません

が、手元に CA が構築できるので、 証明書の発行等も手軽に行えます。 そのため、

公的 CA による SSL 暗号化通信の事前テストや、 プライベートなネットワークでの

SSL 暗号化通信の実施等に役立ちます。

独自 CA 側で行う作業は、以下の通りです。

1. Microsoft証明書サービスのインストール 2. サーバー証明書の発行 3. サーバー証明書の返信

Web サイト側で行う作業は、基本的には公的 CA の場合と変わりませんが、 以下

の作業が増えます。

1. CA証明書のインストール

また、独自 CA を利用する場合は、Web クライアント側の設定として、 以下の作業

が必要です。

1. CA証明書のパスのインストール

全体的な作業の流れは、以下のようになります。

1. Microsoft証明書サービスのインストール(独自 CA側) 2. CA証明書のインストール(Webサイト側) 3. CA証明書のパスのインストール(Webクライアント側) 4. サーバー証明書要求の作成(Webサイト側) 5. 独自 CAへのサーバー証明書要求の送信(Webサイト側) 6. サーバー証明書の発行(独自 CA側) 7. サーバー証明書の取得(Webサイト側) 8. サーバー証明書のインストール(Webサイト側) 9. Webサイトの SSL暗号化通信の設定(Webサイト側)

(3) Microsoft 証明書サービスのインストール(独自 CA 側)

Microsoft 証明書サービスは、 通常の Windows 2000 インストールには含まれてい

ないため、 インストールされていない場合は、追加インストールを行って下さい。

[アプリケーションの追加と削除]コントロールパネルアプレットから [Windows コンポ

ーネントの追加と削除]を起動し、 [証明書サービス]をチェックして下さい。

図 3.7.2-16 証明書サービスのインストール

CA の種類の選択を求められますので、いずれかを選択します。

各 CA には、以下のような目的があります。

表 3.7.2-1 各 CAの目的

種類 目的

エンタプライズ

のルート CA

Windows 2000ベースの社内用ルート CAです。 主に企業内のユーザーやコンピュータに証明書を発行するためのCAです。 Active Directoryドメイン内の自動的な証明書の発行をサポートしています。 なお、Active Directoryと連携する必要があるため、 Active Directory未インストール時は利用できません。

エンタプライズ

の下位 CA

Windows 2000ベースの社内用下位 CAです。 主に企業内のユーザーやコンピュータに証明書を発行するための CAです。 他の CAの下位層に位置します。 なお、Active Directoryと連携する必要があるため、 Active Directory未インストール時は利用できません。

スタンドアロン

のルート CA 単独で機能するルート CAです。 主にインターネット上のユーザーやコンピュータに証明書を発行するための CAです。 Webサーバー用に SSLの証明書を作成するだけであれば、この CAで十分です。

スタンドアロン

の下位 CA 単独で機能する下位 CAです。 主にインターネット上のユーザーやコンピュータに証明書を発行するための CAです。 他の CAの下位層に位置します。

ここでは、インターネットに公開する Web サーバーのための SSL の証明書が必要であ

るため、 スタンドアロン CA を選択します。

図 3.7.2-17 CAの種類を選択

CA の識別情報を入力します。ここでは例として、 例として取り上げている架空の

CA「IPA-sec CA」を作成します。

図 3.7.2-18 CAの情報を入力

この後、データベースとログの位置を設定して、インストールは完了です。

CA証明書のインストール(Webサイト側)

独自 CA を利用する SSL 暗号化通信を行う場合、 独自 CA の CA 証明書を Web

サイト側に予めインストールする必要があります。

公的 CA を利用する際は、この作業を行いませんでしたが、 これは公的 CA の CA

証明書が、Web サーバー(IIS)に予めインストールされているため、 インストールする

必要がなかったからです。 独自 CA を利用する Web サーバーは、独自 CA の CA 証

明書をインストールすることで、 独自 CA から発行されるサーバー証明書を信頼する

ことができます。

CA 証明書は、独自 CA の[証明書サービス Web ページ]からダウンロードします。

独自 CA の[証明書サービス Web ページ]は、以下の URL にありますので、 Web クラ

イアントからアクセスして下さい。

http://[独自 CAのドメイン名もしくはコンピュータ名]/CertSrv/

ここでは、独自 CAのドメイン名を、"ca.ipa-sec.com"とします。 [CA証明書または証明書失効リストの取得]をチェックして、[次へ>]ボタンをクリックします。

図 3.7.2-19 証明書の取得

[CA 証明書のダウンロード]をクリックして、CA 証明書をダウンロードします。

図 3.7.2-20 証明書をダウンロード

ダウンロードした CA 証明書をダブルクリックします。 CA 証明書の内容が表示され

ます。 ここで、[証明書のインストール]ボタンをクリックして下さい。

図 3.7.2-21 証明書の確認を行う

証明書のインポートウィザードが起動します。

以降、ウィザードのデフォルト設定のまま［次へ>］ボタンをクリックしていけば、 CA

証明書のインストールは完了です。

CA証明書のパスのインストール(Webクライアント側)

独自 CA を利用する SSL 暗号化通信を行う場合、 独自 CA の CA 証明書のパスを

Web クライアント側に予めインストールする必要があります。

公的 CA を利用する際は、この作業を行いませんでしたが、 これは公的 CA の CA

証明書のパスが、 Web クライアントに予めインストールされているため、 インストー

ルする必要がなかったからです。 独自CAを利用する全てのWebクライアントは、 独

自 CA の CA 証明書のパスをインストールすることで、 独自 CA から発行されるサー

バー証明書をインストールした Web サイトを信頼することができます。

CA 証明書のパスは、独自 CA の[証明書サービス Web ページ]からインストールし

ます。

[CA 証明書または証明書失効リストの取得]をチェックし、 [次へ>]ボタンをクリック

します。

[この CA 証明書のパスをインストールして下さい]をクリックします。 なお、ここから

先は、Web クライアントによって動作が異なります。 ここでは、Netscape

Communicator と Internet Explorer における CA 証明書のパスのインストールについ

て説明します。

Netscape Communicatorでの CA証明書のパスのインストール

Netscape Communicator の場合は、証明書発行人アシスタントが起動します。 [次

へ>]ボタンをクリックして下さい。

図 3.7.2-22 証明書発行人アシスタント

証明書発行人の説明が表示されます。 [次へ>]ボタンをクリックして下さい。

図 3.7.2-23 証明書発行人アシスタント (続き)

証明書発行人の証明書の確認が表示されます。 [詳細...]ボタンをクリックすると、

証明書の内容が確認できます。 確認が終わったら、[次へ>]ボタンをクリックして下さ

い。

図 3.7.2-24 証明書の内容を確認

証明書発行人の受け付けを行う認証先の設定を行います。 Web サイトの認証用

に受け付ける場合は、 [この証明書発行人をネットワークサイトの認証用に受け付け

る]をチェックして下さい。

チェックが終わったら、[次へ>]ボタンをクリックして下さい。

図 3.7.2-25 証明書発行人を受け付ける

証明書発行人の受け付け時に警告をするか否かを選択します。 ここでは、警告を

出さないようにします。

[次へ>]ボタンをクリックして下さい。

図 3.7.2-26 証明書発行人の警告

証明書発行人を識別するためのニックネームを付けます。 ここでは、「IPA-sec

CA」とします。 入力が終わったら、[完了]ボタンをクリックして下さい。

図 3.7.2-27 ニックネームの付与

証明書がインストールされたことを確認します。

[Communicator(C)]メニューの[ツール(T)]-[セキュリティ情報(S)]を選択して下さい。

セキュリティ情報ページが表示されますので、[署名者]をクリックして下さい。 [受け付

けた証明書署名者の証明書:]リストに"IPA-sec CA"があることを確認して下さい。

図 3.7.2-28 証明書一覧で確認

Internet Explorerでの CA証明書のパスのインストール

Internet Explorer の場合は、ルート証明書ストアが起動します。 [はい(Y)]ボタンを

クリックして下さい。

図 3.7.2-29 ルートストアへの追加確認

証明書がインストールされたことを確認します。

[ツール(T)]メニューの[インターネットオプション(O)...]を選択して下さい。 [インター

ネットオプション]プロパティが表示されますので、 [コンテンツ]タブをクリックして下さ

い。

[証明書(C)..]ボタンをクリックすると、[証明書]ダイアログが表示されますので、 [信

頼されたルート証明機関]をクリックして下さい。 このリストに"IPA-sec CA"があるこ

とを確認して下さい。

図 3.7.2-30 証明機関に追加された

サーバー証明書要求の作成(Webサイト側)

サーバー証明書要求の作成方法は、公的 CA を利用した場合と同じです。 サーバ

ー証明書要求の作成を参照して下さい。

独自 CAへのサーバー証明書要求の送信(Webサイト側)

独自 CA へのサーバー証明書要求の送信は、独自 CA の[証明書サービス Web ペ

ージ]から送信できます。

[証明書の要求]をチェックして、[次へ>]ボタンをクリックします。

[要求の詳細設定]を選択して、[次へ>]ボタンをクリックします。

図 3.7.2-31 要求の詳細設定を選択

[次へ>]ボタンをクリックします。

図 3.7.2-32 要求の詳細設定

[保存された要求:]テキストボックスに、 上記で作成したサーバー証明書要求ファイ

ルの内容をコピーして貼り付け、 [送信]ボタンをクリックします。

図 3.7.2-33 要求の送信

サーバー証明書の発行(独自 CA側)

サーバー証明書の発行は、［証明機関］から行います。 タスクバーの[スタート]ボ

タンをクリックし、 [プログラム(P)]-[管理ツール]-[証明機関]を選択すると、 [証明機

関]が起動します。

[証明機関]]ウインドウの左ペインにて、 [証明機関(ローカル)]-[[証明機関

名]]-[保留中の要求]をクリックして下さい。

ここでは、[証明機関(ローカル)]-[IPA-sec CA]-[保留中の要求]をクリックします。

すると、右ペインに上記で送信したサーバー証明書要求が表示されます。 このサ

ーバー証明書要求を発行します。 証明書要求を右クリックして、[すべてのタスク

(K)]-[発行]を選択して下さい。

図 3.7.2-34 保留中の要求から発行する

サーバー証明書が発行されたことを確認するには、 [発行した証明書]をクリックし

て下さい。

右ペインにさきほど発行したサーバー証明書が表示されます。

図 3.7.2-35 発行した証明書に表示されることを確認

サーバー証明書の取得(Webサイト側)

VeriSign 社の場合、発行されたサーバー証明書は、メールにて送られてきましたが、

独自 CA の場合は、Web サイト側から取得することが可能です。

独自 CA で発行したサーバー証明書は、 独自 CA の[証明書サービス Web ページ]

から取得できます。[保留中の証明書の確認]をチェックして、[次へ>]ボタンをクリック

します。

上記で発行したサーバー証明書が、[保留中の証明書の要求の確認]に表示され

ます。 取得するサーバー証明書を選択して、[次へ>]ボタンをクリックします。

図 3.7.2-36 要求証明書の確認

[CA 証明書のダウンロード]をクリックして、サーバー証明書をダウンロードします。

図 3.7.2-37 サーバー証明書をダウンロード

サーバー証明書のインストール(Webサイト側)

サーバー証明書のインストールは、公的 CA を利用した場合と同じです。

サーバー証明書のインストールを参照して下さい。

Webサイトの SSL暗号化通信の設定(Webサイト側)

サーバー証明書のインストールは、公的 CA を利用した場合と同じです。 Web サイ

トの SSL 暗号化通信の設定を参照して下さい。

3.8 IPSec のセキュリティ設定

従来、暗号化はアプリケーションで行うものであったのに対し、 IPSec は IP レベル

で暗号化を行うため、 TCP 以外のプロトコルにも適応可能なセキュリティサービスで

す。

3.8.1 Windows 2000 高度暗号化パック

Windows 2000 には、デフォルトの状態で IPSec を使用した通信が行える機能を持

っています。

この時、Windows 2000 高度暗号化パック(High Encryption Pack)は、 暗号化を

128bit にアップグレードします。

必要に応じて、下記の URL からダウンロードし、インストールを行ってください。

Windows 2000 高度暗号化パック http://www.microsoft.com/japan/windows2000/downloads/recommended/encryption/default.asp

3.8.2 VPN 間の IPSec 設定

インターネットなどを経由し、 2 つの離れたネットワークの間を 1 つに扱うことができ

る、 仮想プライベートネットワーク(VPN)において、 そのネットワーク間だけを IPSec

にて暗号化する方法を説明します。

(1) IP フィルタの作成

IPSec によって暗号化を行う、IP フィルタを作成します。 作成された IP フィルタは、

後ほど作成する、全ての「IP セキュリティ ポリシー」 によって、共有されます。

IP フィルタの管理は、「IP フィルタ一覧とフィルタ操作の管理」で行います。 この画

面は、以下の手順で表示します。

1. Windowsのスタートメニューから[設定]-[コントロールパネル]-[管理ツール]- [ドメインコントローラ セキュリティ ポリシー]を選択します。

2. 表示された、「ドメインコントローラ セキュリティ ポリシー」の MMC(Microsoft 管理コンソール)において、画面左側のツリーコントロールから 「セキュリティの設定」のツリーを表示します。

図 3.8-1 セキュリティの設定の表示

3. 表示したツリーより、「Active Directory の IP セキュリティ ポリシー」 をマウスの右ボタンで選択し、表示されたコンテキストメニューから、 「IP フィルタ一覧とフィルタ操作の管理」を選択します。

「IP フィルタ一覧とフィルタ操作の管理」画面は、2 つの大きな項目に分かれていま

す。 今回は、IP フィルタを作成しますので、 「IP フィルタ一覧の管理」のみを扱いま

す。

表 3.8-1 IPフィルタ一覧とフィルタ操作の管理

タグ名 内容

IP フィルタ一覧の管理 暗号化を適応する IP フィルタを管理します。 一覧には、登録されたフィルタが表示されます。

フィルタ操作の管理 フィルタを操作方法を管理します。 一覧には、登録された操作方法が表示されます。

本章の例では、インターネットを経由し、 接続先の VPN サーバまでの通信に IP フ

ィルタを行います。 これを実現するための、IP フィルタを作成します。

1. 「IPフィルタ一覧の管理」において、「追加」ボタンを押下します。 2. 「IPフィルタ」画面において、「ウィザードを使用」のチェックを外し、 追加ボタンを押下します。

図 3.8-1 IPフィルタ画面で追加をクリック

3. 「フィルタのプロパティ」画面が表示されます。 以下を設定し、OKボタンを押下します。

表 3.8-2 フィルタの設定内容

タグ名 項目 設定内容 備考

発信元アドレス 特定の IPアドレス 表示されたアドレス入力欄

に、接続先の VPNサーバのIPアドレスを入力します。

宛先アドレス 特定の IPアドレス 表示されたアドレス入力欄

に、インターネット側の IPアドレスを入力します。

フィルタ操作 の管理

ミラー化 チェック有

プロトコルの

種類の選択 TCP

IPプロトコル ポートの設定

「任意の発信ポート」

を選択

プロトコル

IPプロトコル ポートの設定

「任意の発信ポート」

を選択

説明 説明 任意に設定 フィルタについて任意の説

明を入力します。

4. 「IP フィルタ」画面にて、追加したフィルタを確認し、 名前と説明を記入後「閉じる」ボタンを押下します。

図 3.8-2 追加したフィルタを確認

以上で、フィルタの作成は終了しました。

(2) IP セキュリティ ポリシーの作成

次に、先ほど作成した IP フィルタを使用する、 IP セキュリティ ポリシーの作成を行

います。

1. 「Active Directory の IP セキュリティ ポリシー」 をマウスの右ボタンで選択し、表示されたコンテキストメニューから、 「IP フィルタ一覧とフィルタ操作の管理」を選択します。

2. 「IP セキュリティ ポリシー ウィザード」が表示されます。 3. 「IP セキュリティ ポリシー名」では、任意の名前と、説明を記入します。 本コンテンツでは、名前を「VPN IPSec Policy」としました。

4. 「セキュリティで保護された通信の要求」では、 「既定の応答規則をアクティブにする」にチェックをつけます。 「既定の応答規則」を指定しておくことで、 セキュリティを要求するリモートからの接続に対応します。

5. 「既定の応答規則の認証方法」にて、 「次の文字列をキー交換(仮共有キー)の保護に使う」を選択し、 その下のエディットボックスに任意のキーを入力します。本コンテンツでは、 「VPNIPSec」と入力します。

図 3.8-3 次の文字列をキー交換の保護に使うを選択

6. 「IP セキュリティ ポリシーウィザードの完了」では、「プロパティ編集する」 のチェック外して、完了ボタンを押下します。

以上で、「ドメイン コントローラ セキュリティ ポリシー」の、「Active Directory の

IP セキュリティ ポリシー」に、ポリシーが新規作成されます。

図 3.8-4 作成されたポリシーを確認

さらに、新規作成したポリシーの詳細を設定します。

1. 新規作成したポリシー(VPN IPSec Policy)をマウスの右ボタンで選択し、 表示されたコンテキストメニューから、「プロパティ」を選択します。

2. 表示されたプロパティ画面にて「規則」タグを選択し、 「追加ウィザードを使用」のチェックを外し、「追加」ボタンを押下します。

3. 「新しい規則のプロパティ」画面が表示されます。以下の設定を行い、 OKボタンを押下します。

表 3.8-3 規則のプロパティ内容

タグ名 項目 設定内容 備考

IPフィルタ 一覧

IPフィルタ 一覧

(VPN Filter Set) を選択

先ほど作成した IP フィルタを選択します。本コ

ンテンツでは、「VPN Filter Set」となります。

フィルタ操作 フィルタ操作Require Security

を選択

この設定により、セキュ

リティ保護された接続

のみ許可します。

認証方法 認証方法の

優先順位 ※1

※1

トンネルの設定 次の IPアドレスでトンネルエンドポイントを指定す

る

接続先の VPNサーバのIPアドレス

接続の種類 すべてのネットワーク接続

※1 認証方法の編集

1. 編集する認証方法を選択し、編集ボタンを押下します。 2. 表示された「認証方法の編集のプロパティ」画面にて、 「次の文字列をキー交換(仮共有キー)の保護に使う」を選択し、 エディットボックスにキーを入力します。 なお、本コンテンツでは「VPNIPSec」と入力します。

3. OKボタンを押下して、編集を終えます。 4. 「新しい規則のプロパティ」での設定を終えたら、 ポリシーのプロパティ画面を閉

じます。

以上で、設定項目は全て終わりました。 後にポリシーの割り当てを行います。

1. 「ドメイン コントローラ セキュリティ ポリシー」にて、 割り当てる IP セキュリティポリシーを、マウスの右ボタンで選択します。

2. 表示されたコンテキストメニューから、「割り当て」を選択します。

図 3.8-5 ポリシーを割り当てる

(3) IPSec を使った通信の確認

では、実際に IPSec を使って通信を行います。これには手順はありません、 「IP セ

キュリティ モニタ」を使って、 本当に IPSec による暗号化通信が行われているかチェ

ックするのみです。 下記は、IP セキュリティ モニタの起動方法です。

1. Windowsのスタートメニューから、「ファイル名を指定して実行」を選択します。 2. 表示された「ファイル名を指定して実行」画面から、 名前として「ipsecmon.exe」と入力し OKボタンを押下します。

図 3.8-6 動作確認

もし、IP セキュリティモニタの「セキュリティ アソシエーション」の欄に、 何も表示さ

れていない場合は、IPSec による暗号化通信が行われていません。再度設定を確認

してください。

3.8.3 FTP サービスのみを IPSec で暗号化

ここでは、VPNとは関係なく、インターネット上から FTPサーバに接続する際、 IPSecによる暗号化を用いた通信を行う設定を紹介します。

(1) FTP サーバ側の IPSec 設定

本節で想定する FTP サーバは、同時にドメインコントローラであるとします。 よって、

IPSec の設定は、「管理ツール」の「ドメインコントローラ セキュリティ ポリシー」にて

行います。

(2) IP フィルタの作成

IPSec によって暗号化を行う、IP フィルタを作成します。 作成された IP フィルタは、

後ほど作成する、全ての「IP セキュリティ ポリシー」 によって、共有されます。

IP フィルタの管理は、「IP フィルタ一覧とフィルタ操作の管理」で行います。

この画面は、以下の手順で表示します。

1. Windowsのスタートメニューから[設定]-[コントロールパネル]-[管理ツール]- [ドメインコントローラ セキュリティ ポリシー]を選択します。

2. 表示された、「ドメインコントローラ セキュリティ ポリシー」 のMMC(Microsoft 管理コンソール)において、画面左側のツリーコントロールから 「セキュリティの設定」のツリーを表示します。

図 3.8-7 セキュリティの設定を表示

3. 表示したツリーより、「Active Directory の IP セキュリティ ポリシー」 をマウスの右ボタンで選択し、表示されたコンテキストメニューから、 「IP フィルタ一覧とフィルタ操作の管理」を選択します。

「IP フィルタ一覧とフィルタ操作の管理」画面は、 2 つの大きな項目に分かれています。

今回は IP フィルタを作成するため 「IP フィルタ一覧の管理」のみを扱います。

表 3.8-4 IPフィルタ一覧とフィルタ操作の管理

タグ名 内容

IP フィルタ一覧の管理 暗号化を適応する IPフィルタを管理します。一覧には登録されたフィルタが表示されます。

フィルタ操作の管理 フィルタを操作方法を管理します。一覧には、

登録された操作方法が表示されます。

この例では、インターネット経由の FTP のみに IP フィルタを行います。これを実現する

ための、IP フィルタを作成します。

1. 「IPフィルタ一覧の管理」において、「追加」ボタンを押下します。 2. 「IP フィルタ」画面において、「ウィザードを使用」のチェックを外し、追加ボタンを押下します。

図 3.8-8 フィルタの追加

3. 「フィルタのプロパティ」画面が表示されます。以下の設定し、 OKボタンを押下します。

表 3.8-5 フィルタのプロパティ内容

タグ名 項目 設定内容 備考

発信元アドレス 任意の

IPアドレス

宛先アドレス 特定の

IPアドレス 表示されたアドレス入力欄に、インター

ネット側の IPアドレスを入力します。

フィルタ操作 の管理

ミラー化 チェック有 表示されたアドレス入力欄に、インター

ネット側の IPアドレスを入力します。

プロトコルの 種類の選択

TCP

IPプロトコル ポートの設定

「任意の発信ポート」

を選択

プロトコル

IPプロトコル ポートの設定

「次の宛先ポート」 を選択

エディットコントロールに 21 と入力

説明 説明 任意に設定 フィルタについて任意の説明を入力しま

す。

4. 「IP フィルタ一覧」画面において、再度追加ボタンを押下し、 以下のフィルタを追加します。

表 3.8-6 フィルタの設定内容

タグ名 項目 設定内容 備考

発信元アドレス 任意の IPアドレス

宛先アドレス 特定の IPアドレス

表示されたアドレス

入力欄に、インターネ

ット側の IP アドレスを入力します。 フィルタ操作の管理

ミラー化 チェック有

表示されたアドレス

入力欄に、インターネ

ット側の IP アドレスを入力します。

プロトコルの

種類の選択 TCP

IPプロトコル ポートの設定

「任意の発信ポート」 を選択

プロトコル

IPプロトコル ポートの設定

「次の宛先ポート」 を選択

エディットコントロ

ールに 20 と入力

説明 説明 任意に設定 フィルタについて任

意の説明を入力しま

す。

5. 「IP フィルタ」画面にて、2 つのフィルタを確認し、 名前と説明を記入して「閉じる」ボタンを押下します。

図 3.8-9 追加したフィルタの確認

以上で、IP フィルタの作成は終了しました。

(3) IP セキュリティ ポリシーの作成

次に、IP セキュリティ ポリシーの作成を行います。

1. 「Active Directory の IP セキュリティ ポリシー」 をマウスの右ボタンで選択し、表示されたコンテキストメニューから、 「IP フィルタ一覧とフィルタ操作の管理」を選択します。

2. 「IP セキュリティ ポリシー ウィザード」が表示されます。 3. 「IP セキュリティ ポリシー名」では、任意の名前と、説明を記入します。 この例では、名前を「FTP IPSec Policy」としました。

4. 「セキュリティで保護された通信の要求」では、 「既定の応答規則をアクティブにする」にチェックをつけます。 「既定の応答規則」を指定しておくことで、 セキュリティを要求するリモートからの接続に対応します。

5. 「既定の応答規則の認証方法」にて 「次の文字列をキー交換(仮共有キー)の保護に使う」を選択し、 その下のエディットボックスに任意のキーを入力します。 この例では、「FTPIPSec」と入力します。

図 3.8-10 次の文字列をキー交換の保護に使うを選択

6. 「IP セキュリティ ポリシーウィザードの完了」では、 「プロパティ編集する」のチェック外して、完了ボタンを押下します。

以上で、「ドメイン コントローラ セキュリティ ポリシー」の、 「Active Directory の IP

セキュリティ ポリシー」に、 ポリシーが新規作成されます。

図 3.8-11 ポリシーの作成を確認

さらに、新規作成したポリシーの詳細を設定します。

1. 新規作成したポリシー(FTP IPSec Policy)をマウスの右ボタンで選択し、 表示されたコンテキストメニューから、「プロパティ」を選択します。

2. 表示されたプロパティ画面にて「規則」タグを選択し、 「追加ウィザードを使用」のチェックを外し、「追加」ボタンを押下します。

3. 「新しい規則のプロパティ」画面が表示されます。以下の設定を行い、 OKボタンを押下します。

表 3.8-7 規則のプロパティ

タグ名 項目 設定内容 備考

IPフィルタ 一覧

IPフィルタ一覧

(FTP Filter Set) を選択

先ほど作成した IP フィルタを選択します。この例では、「FTP Filter Set」となります。

フィルタ操作 フィルタ操作 Require Security

を選択 この設定により、セキュリティ保護され

た接続のみ許可します。

認証方法 認証方法の 優先順位

※1 ※1

トンネルの設定 この規則では IPSecトンネルを指

定しない

接続の種類 すべてのネットワーク接続

※1 認証方法の編集

1. 編集する認証方法を選択し、編集ボタンを押下します。 2. 表示された「認証方法の編集のプロパティ」画面にて、 「次の文字列をキー交換(仮共有キー)の保護に使う」を選択し、 エディットボックスにキーを入力します。 なお、この例では「FTPIPSec」と入力します。

3. OKボタンを押下して、編集を終えます。 4. 「新しい規則のプロパティ」での設定を終えたら、 ポリシーのプロパティ画面を閉じます。

以上で、設定項目は全て終わりました。 後にポリシーの割り当てを行います。

1. 「ドメイン コントローラ セキュリティ ポリシー」にて、 割り当てる IP セキュリティポリシーを、マウスの右ボタンで選択します。

2. 表示されたコンテキストメニューから、「割り当て」を選択します。

図 3.8-12 ポリシーの割り当て

(4) クライアント側の IPSec 設定

前述の、設定したサーバに接続するために、クライアントの IPSec の設定を行いま

す。

1. Windowsのスタートメニューから[設定]-[コントロールパネル]-[管理ツール]- [ローカル セキュリティ ポリシー]を選択します。

2. 表示された、「ローカル セキュリティ設定」のMMC(Microsoft 管理コンソール) において、画面左側のツリーコントロールから「セキュリティの設定」 のツリーを表示します。

3. 表示したツリーより、「ローカル コンピュータ の IP セキュリティ ポリシー」 を選択します。

4. 次に、右側のセキュリティ ポリシーの中から、「クライアント(応答のみ)」 をマウスの右ボタンで選択し、表示されたコンテキストメニューから 「プロパティ」を選択します。

図 3.8-13 クライアント(応答のみ)のプロパティ

5. 表示されたプロパティ画面から、「規則」タグをクリックします。 6. 「IP セキュリティの規則」から、「 既定の応答」の項目を選択し、 「編集」ボタンを押下します。

7. 「規則の編集のプロパティ」画面が表示されます。 認証方法タグを選択します。

8. 「認証方法の優先順位」から認証方法を選択し、 「編集」ボタンを押下します。 9. 表示された、「認証方法の編集のプロパティ」画面にて、 「次の文字列をキー交換(仮共有キー)の保護に使う」を選択し、 エディットボックスにキーを入力します。この例では「FTPIPSec」 と入力します。入力後、OK ボタンを押下して画面を閉じます。

10. 「規則の編集のプロパティ」を、OKボタンを押下して閉じます。 11. 最後に、ポリシーのプロパティ画面を閉じます。

以上で、クライアント側の設定は終わりです。

後に、設定したポリシーの割り当てを行います。

1. 「ローカル セキュリティ設定」にて、割り当てる IPセキュリティポリシーを、 マウスの右ボタンで選択します。

2. 表示されたコンテキストメニューから、「割り当て」を選択します。

図 3.8-14 ポリシーの割り当て

クライアント側の設定は以上です。

(5) IPSec を使った通信の確認

では、実際に IPSec を使って通信を行います。これには手順はありません、 FTP ツ

ールでサーバに接続してみてください。

次に、前述の「IP セキュリティ モニタ」を使って、 本当に IPSec による暗号化通信

が行われているかチェックします。

もし、IP セキュリティモニタの「セキュリティ アソシエーション」の欄に、 何も表示さ

れていない場合は、IPSec による暗号化通信が行われていません。 再度設定を確認

してください。

3.9 IPFW

• 3.9.1 ipchainsの設定 • 3.9.2 IPFWの設定 • 3.9.3 インターネット接続共有サービスの設定

3.9.1 ipchains

RedHat Linux 7.0 の IP フォワーディングは、ipchains を使用します。

(1) ルールの確認

現在の ipchains のフィルタリングルールを確認します。

# ipchains -L Chain input (policy ACCEPT): Chain forward (policy ACCEPT):

各行の"Chain"に続くチェーン名とその内容は以下の通りです。

Chain output (policy ACCEPT):

表 3.1.9-1 ipchainsにおけるチェーン名と内容

チェーン名 内容

input このシステムに入ってくるパケットに適用されるルールを保持するチェーン

forward このシステム内で転送されるパケットに適用されるルールを保持するチェーン

output このシステムから出ていくパケットに適用されるルールを保持するチェーン

(2) デフォルトポリシーの変更

チェーンに対して、ルールが設定されていない場合、 デフォルトポリシーと呼ばれ

るルールが適用されます。 ルールの確認で表示された、"(policy ACCEPT)"の部分

が、 デフォルトポリシーです。 デフォルトでは、デフォルトポリシーが全てのパケット

を許可しているため、 ポートスキャン等で稼動しているサービスを列挙されたり、 不

正なパケットによる DoS アタックを受ける危険性があります。 そこで、明示的にルー

ルが設定されていない限り、 アクセスを拒否するようにデフォルトポリシーを変更しま

す。

# ipchains -P input REJECT

デフォルトポリシーの変更が完了したら、ルールの確認を行って下さい。

また、デフォルトポリシーの設定が、 システム起動時に常に有効になるように設定

する場合は、 /etc/rc.d/rc.local に上記コマンドを追加して下さい。

例えば、sshを受け付けるルールは、以下のコマンドで追加します。

IP フォワーディング時のルールは、"forward"チェーンに設定します。

"forward"のデフォルトポリシーは、 デフォルトでは全てのパケット転送を許可して

いるため、 外部からサーバーを経由して、内部にアクセスされる可能性があります。

そこで、"forward"のデフォルトポリシーを拒絶に変更します。

# ipchains -P forward REJECT

デフォルトポリシーの設定が、 システム起動時に常に有効になるように設定する

場合は、 /etc/rc.d/rc.local に上記コマンドを追加して下さい。

(3) ルールの追加

サービスを提供するポートを許可するルールを追加します。

# ipchains -A input -j ACCEPT -p [プロトコル] -d [宛先 IP アドレス]/[マスクするビット数] [サービス名もしくはポート番号]

# ipchains -A input -j ACCEPT -p tcp -d 0.0.0.0/0 ssh

ルールの追加が完了したら、ルールの確認を行って下さい。

また、ルールの設定が、システム起動時に常に有効になるように設定する場合は、

/etc/rc.d/rc.local に上記コマンドを追加して下さい。

(4) IP フォワーディングの有効化

デフォルトでは、IP フォワーディングが無効になっていますので、 IP フォワーディン

グを有効にします。

IP フォワーディングは、 /proc/sys/net/ipv4/ip_forward の内容によって制御しま

す。

内容が"0"の場合は、IP フォワーディングが無効です。 逆に、内容が"1"の場合は、

IP フォワーディングが有効です。

デフォルトは、"0"になっていますので、"1"に変更します。

# echo 1 > /proc/sys/net/ipv4/ip_forward

IP フォワーディングの設定が、 システム起動時に常に有効になるように設定する

場合は、 /etc/rc.d/rc.local に上記コマンドを追加して下さい。

(5) IP マスカレードの設定

内部からサーバーの外部向け IP アドレスを使って、 外部ネットワークにアクセスす

るためには、 IP マスカレードという機能を利用します。

# ipchains -A forward -j MASQ -s [送信元 IP アドレス]/[マスクするビット数] -d [送信先 IP アドレス]/[マスクするビット数]

たとえば、内部ネットワークが 192.168.0.0/24 で、 任意の外部ネットワークに IP マスカレードでアクセスするための設定は、 以下のようなコマンドになります。

# ipchains -A forward -j MASQ -s 192.168.0.0/24 -d 0.0.0.0/0

IP マスカレードの設定が、システム起動時に常に有効になるように設定する場合は、

/etc/rc.d/rc.local に上記コマンドを追加して下さい。

3.9.2 IPFW

UNIX システムにおいて Firewall の機能はいくつかあります。 これは、カーネルや

SOCKET 等のネットワークの実装によって大きく異なってくる場合があります。

IPFW は、カーネル内において IP アカウンティングとシステムを通過するパケットの

フィルタリングを行う機能です。

ここでは、FreeBSD を例に IPFW を解説します。

IPFW システムは、必要とする機能によって、オプションをカーネルコンフィグレーシ

ョン ファイルに設定します。これに伴い、カーネルの再構築が必要になります。 カー

ネルの再構築方法については、FreeBSD のドキュメントを参照してください。

現在、このオプションは 3 種類あります。

表 3.9.2-1 IPFIREWALLのオプション

options IPFIREWALL パケットフィルタリング有効

options IPFIREWALL_VERBOSE パケットの情報を/var/log/messageに記録

options IPFIREWALL_VERBOSE_LIMIT=10

/var/log/message に記録するパケット数をエントリ毎に設定

(1) IPFW の設定

IPFW の設定は ipfw コマンドを使用します。ipfw コマンドは、次のように使用します。

ipfw コマンド 操作 プロトコル アドレス

コマンドは"add"または"delete"が使用できます。 このコマンドによって、IPFW にエ

ントリを追加や削除を行うことができます。

操作は"reject","allow", "deny", "count" があります。

rejectとallowは、それぞれパケットを破棄するか通過させるかです。 denyもパケッ

トを破棄しますが、rejectは発信元に対してICMPメッセージを返します。 denyの場合

は、ICMP メッセージさえも返しません。

そして、count の場合は、パケットの操作は行わずに、IPFW のパケットカウンタを更

新するのみです。

指定可能なプロトコルは 4 種類あり、次の通りです。

• all • icmp

• udp • tcp

これらを用いて、たとえば 192.168.0.0/24 に対するポート 20,21,22 に対する TCP パ

ケットを破棄する場合は次のように指定します。

ipfw add deny tcp from any to 192.168.0.0/24 20-21

ここで指定しているアドレスには、たとえば 192.168.0.1 といった特定の IP アドレスも

指定できます。さらに、IP アドレスに続いてポート番号を指定することができます。 た

だし、ポート番号はポートを使用するプロトコルのみ指定することができます。 つまり、

プロトコルが TCP または UDP の場合のみとなります。

そして、これまで解説しなかった from や to が付加されています。 上の例において

は"from any to"が「外部のネットワークが内部のネットワークに入る全て」ということに

なります。

ここまでで気づかれた方もいらっしゃるでしょう。

ルータの設定でこれに非常によく似た設定を行います。

もちろん、ルーティングを行い、通過するパケットを監視しフィルタリングするわけで

すから、ルータそのものなのです。

なお、IPFW の設定を行うときは、サーバのコンソールから行うようにしてください。

特に telnet のポートを閉じるときは、設定を行ったときに telnet のセッションが切れて

しまいます。

ssh も同様です。必要以外のネットワークからはパケットを破棄するという設定を行

っている場合で、誤って内部のネットワーク側を設定してしまうこともあります。

サーバが近くにある場合はサーバまで行けば良いだけですが、 場所の都合上、プ

ロバイダ中にハウジングさせている場合は、 移動する時間が必要になります。 その

間、設定された内容によっては内部のネットワークのパケットが全てフィルタリングさ

れてしまうのです。

3.9.3 インターネット接続共有サービスのセキュリティ設定

(1) インターネット接続の共有

Windows 2000 における IPFW は、非常に簡単です。

ただし、イントラネット側のクライアントは、 サーバの DHCP によって動的に IP アド

レスが割り当てられます。 イントラネット側の、サーバーの IP アドレスも「192.168.0.1」

に固定され、 サブネットマスクは「255.255.255.0」となります。

以下に、「インターネット接続の共有」機能を用いた、設定手順を説明します。

1. Windows のスタートメニューから、[スタート]-[設定]-[ネットワークとダイヤルアップ接続]を選びます。

2. 表示された画面から、インターネット側のネットワーク設定の、プロパティ画面を開きます。

3. 表示されたプロパティ画面から、「共有」タグをクリックします。 4. 「インターネット接続の共有」欄から、「この接続でインターネット接続の共有を使用可能にする」にチェックをつけます。

5. 下図のような画面が表示され、 イントラネット側のネットワークアダプタの設定が、 「192.168.0.1」になるという確認メッセージが表示されます。 OKを押下します。

図 3.9.3-1 共有の確認

6. 問題なく終了すると、プロパティ画面が閉じます。

以上で、設定は終わりです。

なお、イントラネットのクライアントは、そのネットワークの設定を、「IP アドレスを自

動的に取得する」にする必要があります。

しかし、場合によっては、イントラネットのクライアントも固定 IP にする必要が考えら

れます。この場合は、以下の内容を参考にネットワークアダプタの設定を行ってくださ

い。

IP アドレス 192.168.0.2～192.168.0.255

サブネットマスク 255.255.255.0

デフォルトゲートウェイ サーバのイントラネット側の IPアドレス

※IP アドレスの範囲などは、サブネットマスクの値によって変わります。

(2) インターネット接続の共有の詳細な設定

設定ボタンを押下し、表示された「インターネット接続の共有の設定」画面では、 以下

の項目の設定を行うことができます。

サーバのインターネット

側のネットワークアダプタ

のプロパティ画面にて、

インターネット接続の共

有を行うように設定しまし

たが、 このプロパティの

中にある「設定」ボタンを

押下すると、 さらに詳し

い設定を行うことができ

ます。

表 3.9.3-1 設定項目の内容

項目 内容 備考

アプリケーション

「インターネット接続の共有」を使

用して、イントラネット側のクライ

アントから利用可能にするアプリ

ケーションを設定します。

HTTP や FTP、POP などの標準的なアプリケーションについては、特

に設定する必要はありません。

サービス

「インターネット接続の共有」を使

用して、インターネット側に公開す

る、イントラネット側のアプリケー

ションを設定します。

この設定は、外部から内部サービス

の使用を可能にするものであり、大

変危険です。セキュリティを考えた

場合、この設定は不要です。

3.10 Web クライアント

通常、セキュリティ対策をしなければならないのは、サーバーソフトウェア等、 ユー

ザーにサービスを提供する部分と思われがちなため、 クライアントのセキュリティ対

策について、 十分に配慮されていないケースが数多くあります。 Web クライアントは、

大多数のユーザーが利用しているにも関わらず、 その危険性についてはそれほど

認知されていないクライアントソフトウェアの代表です。

セキュリティ対策の施されていない Webクライアントや、 古いバージョンのWebクラ

イアントは、 悪意のある Web サイトにアクセスするだけで攻略されてしまう危険性を

持っています。

クライアントをターゲットにしたアタックは、 初の段階ではクライアントの攻略を狙

っていますが、 一度クライアントの攻略が成功すると、 今度は攻略されたクライアン

トを別のターゲットへの迂回ルートとして利用します。

通常のルートではアクセスが困難なサーバーやネットワークへのアクセスも、 クラ

イアントを迂回することでいとも簡単に実行できてしまう場合があるため、 決して軽視

はできません。

ここでは、Web クライアントのセキュリティ上の問題点について解説した後、 代表

的な Web クライアントである、Netscape Communicator と Internet Explorer のセキュ

リティ対策について説明します。

(1) Web クライアントのセキュリティ

場合によっては、 これらセキュリティ面で問題がある機能を制限する必要がありま

す。

(2) Netscape Communicator のセキュリティ設定

Web クライアントにセキュリティ上の問題点は確かに存在しますが、 ソフトウェアの

問題よりも前に、Web クライアントを利用するユーザーの心構えが重要です。

Web クライアントは、ユーザー自身が悪意のある Web サイトに出向きさえしなけれ

ば、 アタックを受けることはほとんど有り得ません。 つまり、利用するユーザーの意

識次第で脅威を遠ざける努力はできるということです。 以下に挙げるような項目をユ

ーザーが徹底するだけでも、セキュリティは向上します。

• 信用できないサイトへのアクセスや信用できないサービスの利用をやめる • 最新のブラウザを利用する • インターネットからダウンロードしたファイルは、ウイルスチェッカ等で安全を確

認してから利用する

このように、利用するユーザーの意識次第で脅威を遠ざけることはできますが、完

全に排除することはできません。故意でなくても、悪意のある Web サイトに偶然アクセ

スしてしまう可能性は十分にあります。 悪意のある Web サイトは、以下の Web クライ

アントの機能を悪用して、アタックを仕掛けます。

• Javaアプレット • JavaScript • クッキー • ActiveX • VBScript

ここでは、その具体的な設定方法についてブラウザ毎に説明します。

新版の Netscape Communicator を入手して、インストールします。 Netscape 社

のダウンロードページからダウンロードして下さい。古いバージョンがすでにインスト

ールされている場合は、 新版にアップグレードして下さい。

Netscape Communicator のセキュリティ設定は、 [編集(E)]メニューの[設定(E)...]を

選択すると表示されるダイアログにて行います。

このダイアログの[カテゴリ]ツリーの[詳細]をクリックして下さい。

図 3.10-1 セキュリティ設定

Javaアプレット

Java アプレットを動作させる必要がない場合は、 [Java を有効にする]のチェックを

オフにして、Java アプレットを無効化します。

JavaScript

JavaScript を動作させる必要がない場合は、 [JavaScript を有効にする]のチェック

をオフにして、JavaScript を無効化します。

クッキーの受け付け

クッキーの受け付けをクッキー配布元のサーバーだけに制限する場合は、 [元の

サーバに戻される cookie のみを受け付ける(O)]をチェックします。

クッキーの受け付けを完全に拒否するのではなく、受け付けるか否かを選択できる

ように制限する場合は、 [Cookie を受け付ける前に警告する(W)]をチェックします。

また、クッキーを全く利用しない場合は、 [Cookie を無効にする(D)]をチェックして、

クッキーの受け付けを無効化します。

(3) Internet Explorer のセキュリティ設定

新版の Internet Explorer を入手して、インストールします。 Microsoft 社のダウン

ロードページからダウンロードして下さい。 古いバージョンがすでにインストールされ

ている場合は、 新版にアップグレードして下さい。

Windows Update からのアップグレードも可能です。

まず、[ツール(T)]メニューの[Windows Update(U)]を選択して下さい。 Windows

Update サイトに接続し、 "Windows Update Control Package"という ActiveX コントロ

ールのダウンロード要求ダイアログが表示されます。 もし、すでにダウンロードされて

いる場合は、ダイアログは表示されません。

図 3.10-2 ActiveXコントロールのダウンロード

ここで、[はい(Y)]ボタンをクリックします。

"Windows Update Control Package"が実行され、 クライアントマシンのインストー

ル状況がチェックされた後、 まだアップデートされていないソフトウェアが Web ページ

にリストアップされます。

ここから、Internet Explorer のアップグレードを実行します。

なお、すでに ActiveX のセキュリティ設定がされていた場合、 "Windows Update

Control Package"のダウンロード、 もしくは実行が失敗することがあります。詳しくは、

ActiveX の後半を参照して下さい。

Internet Explorer のセキュリティ設定は、 [ツール(T)]メニューの[インターネットオプ

ション(O)...]を選択すると表示されるプロパティにて行います。

このプロパティの[セキュリティ]タブをクリックします。 次に、[Web コンテンツのゾー

ンを選択してセキュリティのレベルを設定する(Z)]の[インターネット]ゾーンをクリックし、

[レベルのカスタマイズ(C)...]ボタンをクリックします。

図 3.10-3 セキュリティ設定

Javaアプレット

Java アプレットを動作させる必要がない場合は、 [設定(S):]ツリーの[Microsoft

VM]-[Java の許可]-[Java を無効にする]をチェックして、 Java アプレットの無効化を

行います。

図 3.10-4 Javaアプレットを無効にする

JavaScript

JavaScript を実行する直前に実行するか否かを選択できるようする場合は、 [設定

(S):]ツリーの[スクリプト]-[Java アプレットのスクリプト]-[ダイアログを表示する]をチェ

ックして下さい。

図 3.10-5 JavaScriptの実行選択または無効化

クライアントマシンにクッキーファイルを保存するクッキーを受け付けるか否か選択

できるようにする場合は、 [設定(S):]ツリーの[Cookie]-[コンピュータに保存されてい

る Cookie の使用許可]-[ダイアログを表示する]をチェックします。

また、JavaScript を動作させる必要がない場合は、 [設定(S):]ツリーの[スクリプ

ト]-[Java アプレットのスクリプト]-[無効にする] をチェックし JavaScript を無効化しま

す。

クッキー

クライアントマシンにクッキーファイルを保存するクッキーを受け付けないようにする

場合は、 [設定(S):]ツリーの[Cookie]-[コンピュータに保存されている Cookie の使用

許可]-[無効にする]をチェックします。

図 3.10-6 クッキーの選択または無効化

セッション(ブラウザが起動している 中の Web サイトへのアクセス)時のみのクッキ

ーを受け付けるか否か選択できるようにする場合は、 [設定(S):]ツリーの

[Cookie]-[セッションごとの Cookie の使用許可(保存なし)]-[ダイアログを表示する]を

チェックします。

セッション時のみのクッキーを受け付けないようにする場合は、 [設定(S):]ツリーの

[Cookie]-[セッションごとのCookieの使用許可(保存なし)]-[無効にする]をチェックしま

す。

また、クッキーを全く利用しない場合は、 両方の設定を[無効にする]にチェックして

下さい。

ActiveX

ActiveX をダウンロードするか否か選択できるようにする場合は、 [設定(S):]ツリー

の[ActiveX コントロールとプラグイン]-[署名済み ActiveX コントロールのダウンロー

ド]-[ダイアログを表示する]をチェックします。

ActiveX のダウンロードが必要ない場合は、 [設定(S):]ツリーの[ActiveX コントロー

ルとプラグイン]-[署名済み ActiveX コントロールのダウンロード]-[無効にする]をチェ

ックします。

図 3.10-7 ActiveXの選択または無効化

ダウンロード済みの ActiveX を実行する直前に実行するか否か選択できるようにす

る場合は、 [設定(S):]ツリーの[ActiveX コントロールとプラグイン]-[ActiveX コントロー

ルとプラグインの実行]-[ダイアログを表示する]をチェックします。 ダウンロード済み

の ActiveX の実行が必要ない場合は、 [設定(S):]ツリーの[ActiveX コントロールとプ

ラグイン]-[ActiveX コントロールとプラグインの実行]-[無効にする]をチェックします。

図 3.10-8 ダウンロード済みの ActiveXに対する選択

もし、ActiveX を全く利用しない場合は、 両方の設定を[無効にする]にチェックしま

す。

なお、前述した Windows Update は、 ActiveX コントロールを使ってクライアントマシ

ンの状態をチェックしているため、 ActiveX のセキュリティ設定によっては、Windows

Update が動作しなくなります。

Windows Update を正常に動作させるためには 、[インターネット]ゾーンのセキュリ

ティレベルをデフォルト設定に戻すか、 ActiveX のセキュリティレベルだけを適切な設

定に直して下さい。

デフォルト設定に戻す場合は、[インターネット]ゾーンを選択してから 、[規定のレ

ベル]ボタンをクリックします。 このとき、ActiveX 以外のセキュリティレベルも元に戻さ

れます。注意してください。

また、ActiveX のセキュリティレベルだけを適切な設定に直す場合は、 [設定(S):]ツ

リーの[ActiveX コントロールとプラグイン]中の項目を以下のように設定してます。

• [署名済み ActiveX コントロールのダウンロード]の[ダイアログを表示する]をチェ

ック • [ActiveXコントロールとプラグインの実行]の[ダイアログを表示する]をチェック • [スクリプトを実行しても安全だとマークされている ActiveX コントロールのスクリプトの実行]の[ダイアログを表示する]をチェック

VBScript

VBScript を実行する直前に実行するか否か選択できるようにする場合は、 [設定

(S):]ツリーの[スクリプト]-[アクティブスクリプト]-[ダイアログを表示する]をチェックしま

す

図 3.10-9 VBScriptの選択または無効化

また、VBScript を動作させる必要がない場合は、 [設定(S):]ツリーの[スクリプ

ト]-[アクティブスクリプト]-[無効にする]をチェックし、 VBScript を無効化します。

第 4 章 通信機器の設定方法

セキュアな環境において通信機器の設定を欠かすことはできません。

•

システム全体が、インフラ、通信機器、OS、プロトコル、アプリケーションという要素

から構成されています。 これらは、OSI の 7 階層モデルに類似した階層となることに

気づかれるでしょう。

この根底とも言えるインフラや通信機器の設定を行わなければ、 これらより上の

階層である OS やアプリケーションの設定で苦労することとなります。 つまり、それぞ

れの要素の特徴を考え、その要素において 適な設定を行うことによって、セキュア

な環境が構築できるのです。

4.1 ネットワークトポロジ • 4.2 ルータ • 4.3 ハブ

4.1 トポロジー

ネットワークセキュリティにおいて、トポロジーの重要性を解説した文献は多くありま

せん。しかし、これは非常に大きな要素となりえる場合があります。

ネットワークのトポロジーは、大きく 3 種類に分類されます。

• バス型 • リング型 • スター型

この中でも、多く使用されているであろうトポロジーはスター型です。

スター型トポロジを採用した場合、 セキュリティ面においていくつかの利点があり

ます。

4.1.1 スター型

ネットワークトポロジーとしてスター型を導入するメリットは、 特にスイッチングハブ

などを使用しているときに現れてきます。これは、ハブの項で解説します。

スター型のメリットとしては、まず管理の集中化があります。 これによってサーバが

ダウンしてもネットワークは通常通り動作します。 また、他のサーバやクライアントに

対して影響を及ぼすことはありません。

そして、セキュリティ設定の面では、 ポート毎に接続できるホストの制限やデータ

の暗号化、 他ポートへの流出を防ぐといったことが行えるようになります。

図 4.1-1 スター型トポロジ

逆に、スター型固有のデメリットもあります。

これは、ハブ等の通信機器に対して攻撃が行われ、 機能が停止したときには関係

のあるセグメントや VLAN が停止することとなるのです。 また、シェアードハブを使用

した場合は、 全てのデータが盗聴される可能性があります。 この対処方法として、

データの暗号化をホスト側で行う必要が出てきます。 この作業は全てのホストで行う

必要があるため、 多くの場合はハブの交換を行うようです。

4.1.2 バス型

バス型のトポロジーを採用しているネットワークは少なくなってきました。

運用の都合等でスター型に移行した環境もありますが、 このトポロジーが適してい

る環境はまだまだあります。

元々、バス型はクライアント/サーバシステムではなく、たとえばディスクレスシステ

ムなどで利用されることがあります。 これは、バス型ではパケットの衝突が発生する

可能性が高くなりなります。 そこにクライアント/サーバシステムを動かした場合、 サ

ーバとクライアントで頻繁なデータ交換が発生するためにパフォーマンスが得られな

いことがあります。特に、HTTP や FTP といったプロトコルを使用するとパフォーマンス

低下を招きます。

バストポロジーが採用される理由はいくつかあります。

一つは物理的な要因。ケーブルの取り回しや距離といった点。 もう一つは比較的

安価に構築できる点。 これらの要因によって導入される場合もあります。

図 4.2-2 バス型トポロジ

セキュリティにおいてバス型の致命的な問題は、 スター型でシェアードハブを使用

した場合と類似してます。 ネットワーク上のデータを盗聴することは非常に簡単です。

しかも、スター型と比べて防ぐことができません。 スター型は通信機器を交換すると

いう方法が残されていますが、 バス型ではデータを暗号化するということしか残され

ていません。

4.1.3 リング型

リング型を採用している環境はバス型より更に少なくなります。

しかし、これも適した環境があり、現在でも採用されています。

リング型は、障害が発生した場合の弱さが指摘されています。

リング型においては、各ホストがリピータのような役割を持っているため、 途中の

ホストが故障などの障害で停止すると通信できなくなるホストが出てきます。

図 4.2-3 リング型トポロジ

このことはセキュリティの弱さにも繋がります。 それは、特定のホストを攻撃するだ

けでネットワーク全体を利用不能にすることができることに繋がります。 さらに、途中

のホストで盗聴を行うことも可能になります。

4.2 ルータ設定

常時接続環境においてルータの設定を正しく行うことにより、 攻撃側にはルータが

初の障壁となることができます。

ここでは、ルータの正しい設定と、 ルータレベルのフィルタリングの設定を取り上げ

ます。

例として使用するルータは YAMAHA 社 RT シリーズですが、 他社の場合であって

も考え方は同じです。

4.2.1 ポートに対するセキュリティポリシー

ルータにおけるセキュリティには何があるでしょうか。

ルータに対してルーティング情報以外何も設定していない状態であれば、 攻撃す

る側からはルータは素通りできます。 もし、ここで何らかの制限があれば、攻撃側の

活動範囲を狭めることや、 攻撃が行えないようにすることも可能です。

ルータで設定できる範囲は非常に限られています。 しかし、大抵の場合、ポートの

利用を制限することを行うことができます。

特定のポートを利用させないことを「ポートを閉じる」と呼びます。 これは、自ネット

ワークに対する特定のポートを使用するパケットをルータが破棄します。これによって、

自ネットワークには特定のポートを使用した攻撃が使用できなくなります。たとえば、

「外部のネットワークからポート 23 へのアクセスを禁止する」という設定 行うと、外部

からの telnet 要求はルータで破棄されるということです。

ポートスキャンの項で解説したように、 外部からどのホストのどのポートが空いて

いるかをチェックするとき、 ルータでパケットを破棄させることによって自ネットワーク

内のホストが守られるということにもなります。

ポートを閉じるアプローチは二つあります。

1. 危険な(弱点となる)ポートを閉じる 2. 使用するポートのみ開ける

この二つは同じ結果を指しているようにも考えることができます。 しかし、実際に設

定されたルータを見てみると、 この二つは大きく違う設定がなされる場合が多いので

す。

また、使用するポートのみを開けるということは、一見単純作業のように見えます。

ところが、実は非常に奥の深いものなのです。 特に、TCP/IP の仕様について熟知し

ていなければ LAN 側からのアクセスに意図しなかった制限がかかってしまうこともあ

ります。

(1) 危険なポートを閉じる

まず行わなければならないこと。それは危険なポートを閉じるということです。

たとえば、NetBIOS や NFS を使用したファイル共有といったものは代表例です。 こ

れらは真っ先に閉じる設定が必要になります。 どうしても他のネットワークから利用

したい場合はルータでは開けておき、 LAN 側で対応する設定を行う場合もあります。

一般的に危険なものだけでなく閉じるべきポートとされているものを表にまとめまし

た。

必要でなければ、これらのポートはルータにおいてで閉じてしまうべきです。 もちろ

ん、ルータで閉じただけで安心せずに、LAN 上でも何らかの設定を行う必要がありま

す。

なぜなら、第一章で様々な脅威を解説しました。 このように、たとえばリモートアク

セスによるバックドアがある場合などが考えられるからです。

表 4.2-1 閉じるべきポート

ポート プロトコ

ル サービス 解説

1 TCP/UDP マルチプレクサ

11 TCP/UDP systat

15 netstat TCP

43 TCP/UDP whois

67 外部に公開する必要はない TCP/UDP bootp

69 TCP/UDP 外部からはフィルタリング tftp

69 TCP/UDP Oracle SQL*Net オラクルを使用している場合はフィ

ルタリング

70 TCP/UDP gopher Gopher を使用しなければフィルタリング

79 TCP/UDP finger ユーザ情報が漏れるためフィルタリ

ング

87 TCP/UDP link よく狙われる

95 TCP/UDP supdup よく狙われるためフィルタリング

109 TCP/UDP POP2 POP2を使用していることが問題

110 TCP/UDP POP3 APOPやSSHを使用したポートフオワーディングを推奨

137 TCP/UDP NetBIOS ネームサービス 必ずフィルタリング

138 TCP/UDP NetBIOS データグラムサービス

必ずフィルタリング

139 TCP/UDP NetBIOS セッションサービス

必ずフィルタリング

111 TCP/UDP sunrpc プログラムの使用ポートが漏れるた

めフィルタリング

161 TCP/UDP SNMP 外部には公開すべきではない

162 TCP/UDP SNMP TRAP 外部には公開すべきではない

177 TCP/UDP xdmcp Xのログインに使用する xdmが使用する

201 TCP/UDP AppleTalk ルーティングメンテナンス

204 TCP/UDP AppleTalk Echo

202 TCP/UDP AppleTalk ネームバインディング

206 TCP/UDP AppleTalk ゾーン情報

213 TCP/UDP IPX

220 TCP/UDP imap3 使用していなければフィルタリング

445 TCP/UDP Microsoft DS

512 UDP biff 必ずフィルタリング

512 TCP exec 必ずフィルタリング

513 TCP login 必ずフィルタリング

513 UDP who 必ずフィルタリング

515 TCP/UDP printer 外部にプリンタを公開する必要はな

い

517 TCP/UDP talk

518 TCP/UDP ntalk

520 UDP route

540 TCP/UDP uucp 使用しないのであればフィルタリン

グ

1025 TCP/UDP listner

1433 TCP/UDP Microsoft SQL Server SQL Server を使用している場合はフィルタリング

1434 TCP/UDP Microsoft SQL Monitor SQL Server を使用している場合は

フィルタリング

2049 TCP/UDP NFS 必ずフィルタリング

2766 UDP listen

3268 TCP/UDP Microsoft GC グローバルカタログ

3269 TCP/UDP Microsoft GC グローバルカタログ

5631 TCP/UDP pcANYWHERE data

5631 TCP/UDP pcANYWHERE stat

6000-6063 TCP/UDP X11 Xで使用するポートは全て塞ぐ

(2) 使用するポートのみ開ける

これは、一見単純な設定のように思えます。 しかし、単純に設定を行うと LAN 側か

らも通信できない等の現象を引き起こします。 この作業は、実は TCP/IP を理解して

いないと行えない設定作業なのです。

セキュリティポリシーを考える段階で充分に検討を行ってください。

(3) ルータでの防御は一要素にすぎない

ルータにおけるセキュリティ設定において心がけておくことがあります。 それは「ル

ータのセキュリティはサイト全体のセキュリティの一要素にすぎない」ということです。

前述のリモートアクセスの回線をバックドアとして利用する場合や、 もしルータに

致命的なセキュリティホールが見つかった場合などを考慮し、 その LAN 側でも防御

を行うべきでしょう。 しかし、もし守るべきデータがルータレベルのもので十分である

と判断した場合や、 利便性を考慮し別に設置する Firewall で賄うということであれば

相応の設定で構わないでしょう。

比較的よく設定されるケースは、ルータと Firewall で設定の役割を分けているもの

です。たとえば、LAN 全体における共通の設定かつ危険なポートに関してはルータで

設定。 それ以外は Firewall で設定という使い分けです。

ルータで設定すると、そのネットワーク全体に影響を及ぼします。 また、ルータの

OS によってはサイトの技術者では対応できない場合もあります。

このため、重大な問題を引き起こすもので設定が滅多と変わらないものをルータで

設定するということが行われています。

それでは実際にルータの設定方法を示します。

例にとりあげるルータは YAMAHA RT100 シリーズの Rev3 系と呼ばれるものを使用

します。 機種は RT100i/RT102i/RT140i,p,e/RT200i です。

4.2.2 ルータの設定方法

(1) プライベートアドレスを拒否する

攻撃を仕掛ける場合や踏み台として利用する場合の代表的な手法が IP アドレスの

偽装です。

特に、RFC1918 によって決められているプライベート IP アドレスやループバックアド

レス(127.0.0.1)に偽装するものが多く見受けられます。

インターネット上では、プライベートアドレスを発信元とされている TCP/IP のパケッ

トは全てフィルタリングしてしまうというポリシーを設定することができます。 これによ

って、プライベート IP アドレスを発信元として IP アドレスを偽装しているパケットを拒否

することができます。

また、インターネット上だけでなく、ルータが受け取る IP アドレスでループバックアド

レスが発信元であるパケットはあり得ないため、これも拒否することができます。

では、実際にそのフィルタルールを作成してみましょう。

ここで作成したフィルタは外部から内部へ向かうパケットでプライベートアドレスとル

ープバックアドレスは拒否するというものです。

ip filter 1 reject 10.0.0.0/8 * * * * ip filter 2 reject 172.16.0.0/12 * * * * ip filter 3 reject 192.168.0.0/24 * * * * ip filter 4 reject 127.0.0.1 * * * *

ここに示した 4 つのフィルタリングルールは、外から中に対してだけではありません。

中から外に対しても設定しておく必要があります。

大抵の場合、プライベート IP アドレスは接続している上流の IPS などでは、 プライ

ベート IP アドレスを他に流さないよフィルタリングされています。 しかし、サイトのポリ

シーとして、自サイトが踏み台になったときにや、 上流がルーティングしてしまったと

き、 プライベート IP アドレスで偽装したパケットを外に出さないようにしておくことが望

ましいでしょう。

「上流がフィルタリングしているはずだから不要だ」ではなく、 自サイトから出さない

という努力が必要なのです。

しかし、単純に拒否してしまうと、内部からのパケットも対象となってしまいます。 こ

の場合は、内部からサービスを提供しているポートは許可しておくことで解決できま

す。

(2) 自アドレスを拒否する

「自アドレスを拒否する」ということは、一見矛盾しているようにも思えます。

しかし、前述のプライベート IP アドレスが発信元として設定されているパケット同様、

自アドレスを設定して送信してくる場合があります。この場合、LAN 側から外部に対し

てデータが流れる場合はありますが、 外部から LAN に流れることはありません。 そ

の IP アドレスは自サイトにのみ存在する IP アドレスだからです。これらのことから、

自サイトの IP アドレスが発信元となっているパケットが外部から届いた場合、 攻撃の

ためであると判断することができます。

ip filter 5 reject 111.222.333.0/24 * * * *

(3) ソースルーティング

ソースルーティングが指定されている IP パケットを受け取った場合を考えてみまし

ょう。

小規模サイトでは様々な利用形態が考えられます。 もし、SOHO 環境などで組織

から指示が出ているといったケースを除けば、 ソースルーティングは行わないように

しておくことが懸命です。もし、これで問題が発生するようであればその相手と相談し

て有効にするかを検討してください。

ip filter source-route on

(4) ルーティング情報

ルーティング情報もソースルーティング同様に関係する組織から指示が出ていない

限りは拒否しておいたほうが無難です。

しかし、もし接続においてダイナミックルーティング等が行われていた場合、 これを

拒否すると接続のトラブルとなるため、 十分に検討しておく必要があります。

ip filter routing protocol none

(5) ルータに対する telnet 拒否

色々なサイトの設定を見ると、意外にもルータに対して telnet を許可している場合

が多いようです。もしルータが乗っ取られた場合に、重大な問題を引き起こします。

ルータはサイトに対するあらゆるパケットが通過します。 ルータを乗っ取るだけで、

そのサイトのあらゆるデータが参照でき、 あらゆる攻撃が可能になるのです。

また、telnet クライアントを持っているルータもあるため、 そのルータを踏み台にし

て他サイトに対して侵入を試みることも可能になります。これらのことから、必要がな

ければルータに対する telnet は拒否する、 または LAN 側からのみ許可するという設

定が必要になります。

小規模サイトでは、ルータの保守を外部に委託する場合もあります。 特にリモート

で保守を行う場合が無いかを事前に十分な検討が必要でしょう。たとえば、サイト内

の者がルータの保守を行うのであれば、 ルータに対する telnet 要求は LAN側からの

み許可するという設定も可能です。 リモート保守を行わず、ルータにシリアルケーブ

ルを接続し保守を行うのであれば、 全ての telnet 要求を拒否するという設定になる

わけです。

また、 近のルータは httpd を搭載し Web で設定できるようになっています。 これ

も、どこのネットワークからでも参照できるような設定では困ります。

httpd の機能でネットワークを制限してある場合であっても、 念のために HTTP が

使用する 80 番のポートをフィルタリングしても良いでしょう。赤色の部分はルータの IP

アドレスを設定します。

ip filter 6 reject * 172.16.255.254 tcp,udp * 23

ip filter 7 reject * 172.16.255.254 tcp,udp * 80

ここでは、 の IP アドレスを持つルータに対し、 外部からの telnet と

HTTP を拒否している例です。 同じ要領で、LAN 側の特定のホストに対し、 たとえば

telnet は禁止するという設定を加えることができます。

172.16.255.254

(6) ICMP を返さない

攻撃する側がポートスキャンを行う場合、稼動しているホストを絞り込みます。

もちろん、この作業を行わなくとも攻撃の対象となるサイトが所持している IP アドレ

ス全てにポートスキャンを行うことも可能ですが、稼動していないホストに対して行うこ

とは効率が良くありません。

そこで、ポートスキャンを行う前に予め使用されている IP アドレス(マシンが接続さ

れて稼動しているもの)を探しておきます。この時に、手っ取り早く確実に確認する方

法が ping を使う方法です。この ping で使用される ICMP をフィルタリングすることによ

って、 ICMP レベルでホストの存在を隠すことができます。ただし、ルータによっては、

ICMP そのものを拒否してしまうため、 LAN からの ping も通らない可能性もあります。

設定を行うには十分注意して行ってください。

ip filter 8 reject * * icmp-info * *

(7) 外部から Proxy を使用させない

Firewall から外に出るため、 LAN 側のクライアントからは Proxy を経由してインター

ネット上の各ホストに接続させる場合が多いでしょう。 これらは総称して Proxy と呼ば

れます。

攻撃する側も、これらは格好の材料となります。しかし、Proxy を攻撃するのではな

く、 Proxy を踏み台として別のサイトを攻撃するのです。 これによって、攻撃する側

は足跡を見つかりにくくするのです。これは、Proxy の中でも、外部から外部に対して

使えるようになっている Proxy を指し、 「串」や「漏れ串」という隠語が使われていま

す。

まず行わなければならない設定は、 それぞれの Proxy に対して LAN 側から外へ

のアクセスのみを許可するという設定です。 しかし、これだけでなく、ルータでも設定

することが望ましいでしょう。 ルータからは、特定のホスト(Proxy となっているホスト)

からの HTTP のみを許可するといった設定です。ここでは、Proxy サーバが

111.222.333.444 という IP アドレスを持ち、 Proxy としてだけでなく DNS なども動作し

ているとします。

ip filter 10 pass 111.222.333.444/24 * tcp,udp 53,80 *

これによって、111.222.333.444 のホストから外部に対するポート 53(DNS)と ポート

80(HTTP)を通過させることができます。また、これは、特定のホストから特定のプロト

コルのみしか外部に出さないという設定を行うときにも有効です。

ここまでの設定は、 ネットワークやサービスの種類に依らない共通となる基本設定

です。これをまとめると次のようになります。

ip filter 1 reject 10.0.0.0/8 * * * *

ip filter 4 reject 127.0.0.1 * * * *

ルータ以外に Firewall を設置する場合、 ルータのセキュリティポリシーと Firewall

のセキュリティポリシーを如何に分離させるかで LAN からの利便性が大きく変わりま

す。

ip filter 2 reject 172.16.0.0/12 * * * *

ip filter 3 reject 192.168.0.0/24 * * * *

ip filter 5 reject 111.222.333.0/24 * * * *

ip filter 6 reject * 172.16.255.254 tcp,udp * 23

ip filter 7 reject * 172.16.255.254 tcp,udp * 80

ip filter 8 reject * * icmp-info * *

ip filter 10 pass 172.160.0.0/16 * tcp,udp 53,80 *

ip filter source-route on

ip filter routing protocol none

ここからは各サイトごとにセキュリティポリシーを考え設定を行います。

利便性とセキュリティは相反する性質を持っており、 利便性が高くなるとセキュリテ

ィレベルが落ちることになります。 逆に、セキュリティレベルを高くすると、 利便性に

問題が出てくることになります。

特に、ルータレベルで設定を行うと LAN 全体に影響するため、 Firewall を設置して

いる場合は、LAN 全体を守るための設定などを行うことで良いでしょう。

(8) 危険なポートを塞ぐ

冒頭で紹介した危険なポートの一例を挙げましたが、 これ以外にも OS やアプリケ

ーションよにって危険なポートは存在します。 今回は、これらのポートを塞ぐ場合とし

て考えてみます。

LAN には Windows 系の OS を使用している場合も少なくないうえ、 NetBIOS を利用

した攻撃も後を絶ちません。 まず、この NetBIOS のパケットをルータで拒否してみま

す。

ip filter 11 reject * * udp,tcp 137-139 *

NetBIOS では、ポート 137,138,139 を使用しているということは有名なため、 ご存知

の方も多いでしょう。

ところが、このポートを使用して様々な攻撃が行われてきました。 NetBIOS を LAN

上で使用する分には問題はありませんし、 非常に便利なものです。 しかし、この

NetBIOS を使用してインターネットとのやり取りでどのくらい使用するでしょうか？ た

とえば、インターネットを介して共有ディレクトリを使用するといったことが考えられま

すが、危険を冒してまで共有する必要はありません。代替手段があるからです。

では、共有ディレクトリは LAN 内に留めておき、インターネット側との接続点である

ルータでポート 137,138,139 を使用するパケットを拒否してしまうことが出来るようにな

ります。もちろん、その内側の Firewall でも念のために拒否するよう施しておくと良い

でしょう。

この設定が上の一行なのです。

同様に、例えばデータベースが稼動している場合、Oracle SQL*Net であればポー

ト 66 を塞ぎます。SQL Server であればポート 1433 と 1434 を塞ぎます。 このようにし

て、内部で稼動している OS やアプリケーションと運用形態からどのポートを塞ぐかを

検討する必要があるのです。

4.3 ハブ

通信機器の中でハブに関してセキュリティの対策が必要と感じているところは少な

いようです。

しかし、この部分も非常に重要かつ、軽視すると重大な事態を招く恐れがありま

す。

特に難しい技術を使わなければならないものもありますが、 ここでは簡単にセキュ

リティを高めることができる方法をいくつか解説します。

4.3.1 スイッチの導入

まず、サイトの規模に関わらず、スイッチングハブを導入してください。 高価なもの

を導入する必要はありません。

盗聴の項で解説したように、シェアードハブのままにするとどうなるでしょうか。

その LAN を普段から使用している方はもちろんのこと、仮に外来者がネットワーク

の調査と偽り、持ち込んだノートパソコンをハブに接続しネットワークのモニタを始め

たときから全てのデータは盗聴されるのです。

しかし、スイッチングハブをはじめとするスイッチング装置をネットワークの途中に

置くことによって、ポートと相手以外にはデータが流れなくなります。 これによって、

小限度の被害で済むこととなるのです。

4.3.2 ポート利用の制限

展示会や大学のような環境ではよく使用されることですが、 ポート毎に接続できる

端末を限定することも重要です。

これは、ある一定以上の機能を実装したハブででしか行えないので、 費用が多少

必要となります。

ポートごとに端末を固定することによって、不正なポート利用を防ぐことができます。

固定する方法は、主にハブのポートに対して端末の MAC アドレスを登録するという方

法がとられます。

4.3.3 設定変更の防止

高級なハブの場合、ハブそのものにシリアル端末を接続したり telnet によって設定

を行うことができます。

この設定画面を簡単に出されると非常に困った事態になるわけです。 もちろん、

パスワード管理も必要ですが、必要以外はシリアル端末のみを使用するようにし、可

能であれば telnet で設定が行える端末を MAC アドレスで固定してしまうと良いでしょ

う。

ハブの種類は多様化してきています。しかし、小規模サイトとして考えた場合、 高

級なハブを導入する場合は少ないため、簡単な解説に留めました。

もし、使用する予定のハブに VLAN やルーティング機能があるならば、これらを有

効活用することによってセキュリティを高めることができます。

第 5 章 防衛方法のまとめ

ここまで、実際の攻撃例と対策を解説してきました。

攻撃の対策を行い、セキュアな環境を構築するには、 まずどのような攻撃が行わ

れているのかを知ることから始まります。

どのような攻撃が行われているのかを知らなければ、 対策をとることができないので

す。

また、実際に行われている攻撃は、そのほとんどが既存の手法を使用しています。

新しい手法を見つけ出し攻撃を行うという例はほんの僅かです。

また、対策を行っていても安心はできません。

新しいセキュリティホールが発見されると、その部分を突く攻撃が行われます。

この面においても、どのような攻撃が行われているのか、 セキュリティに関する情

報を常に集めることが必須となり、 これが次の対策に繋がるのです。セキュアなサイ

トを構築するためには一度の情報収集で済みますが、 セキュアなサイトを維持する

ためには、 セキュリティの情報を常に収集しなければならないのです。

本書を参考にサイトを構築、そしてセキュリティの情報を収集を行いサイトを維持し

ている場合であっても、これだけでは重大なことが欠けています。このサイトに対して

どのような攻撃が行われているのか、そしてサイトの状態はどうなっているのかという

ことを常に注意して監視しなければなりません。

ここでは、それぞれの攻撃について監視を中心に解説します。

5.1 ポートスキャン

ポートスキャンが行われていることを発見することは非常に難しいことです。

なぜなら、ログに残されたポートスキャンなのか、 何らかのアクセスなのかを見極

めることが難しいためです。 また、Anonymous FTP を使用したポートスキャンは FTP

のログとして残るだけです。

ポートスキャンが行われたことを見極めるためには、ログの内容から推測すること

しかありません。このときにポートスキャンであることを見極めるには、次の部分に注

目します。

• ポート接続後の利用がないこと • 複数のポートへの接続が行われていること • 複数のポートへの接続がほぼ同時刻であること

サーバのポートに対し接続が行われ、以降利用された形跡が無い場合はポートス

キャンの可能性があると考えられます。

重要なことは、ポートスキャンで何が見つかったかです。 危険なポートを開放して

いる場合、そのポートの存在が見つかったと考えるべきです。 もしそうであれば、次

は攻撃されると考え、 速やかに対策をとるようにしてください。

しかし、これだけではポートスキャンであると判断することはできません。 なぜなら、

たとえば telnet のポートに接続した直後、相手のモデムが切れてしまった場合が考え

られます。よって、接続後の利用が無いということだけでポートスキャンであると考え

ることはできません。

ポートスキャンの場合、一つのポートだけを調べることはあまりありません。 全く無

いわけではありませんが、一つのポートだけを調べる場合は、 既に攻撃方法が決ま

っており、その攻撃を行える相手を探しているときです。よって、多くの場合、ポートス

キャンは複数のポートに対して行われます。 たとえば、ポート 1 から 1024 までに対し

てスキャンを行うわけです。

この場合は、接続しただけで利用のないことがログに多数残っているはずです。

そして、それらがほぼ同時刻であれば、 ポートスキャンであろうと考えられるのです。

なお、ログのチェックはサーバだけではありません。

サイトの入り口であるルータでフィルタリングされたものはサーバまで到達しません。

確認する必要のあるログは、サーバとルータの両方です。しかし、ポートスキャンが行

われたからと言って、 即座に何か問題が発生するとは限りません。

まとめ

• ポートスキャンであるかを見極める • 常にログを確認する • 自らポートスキャンを行い危険なポートが開放されていないか確認

開放されているポートは閉じる(サービスを止める)

5.2 リモートアクセス

リモートアクセスは、ともすれば攻撃側に対して安全かつ簡単に侵入できる裏口を

提供してしまうことにもなります。

さらに、電話番号が 0120 で始まるフリーダイヤルを設定されている場合は、 通話料

金さえも負担することがなくなるのです。

攻撃側に対して好都合な条件が揃っているリモートアクセスは、 出来る限りの制

限を行うべきです。 しかし、インターネットからの接続では多くの制限がかかっており

不自由です。 もちろん、ここを開放すると攻撃側は正面から攻撃してきます。

そもそも、リモートアクセスの手段は、遠隔地から LAN と同じ制限で利用できるよう

に設ける場合が多いでしょう。 リモートアクセスを制限してしまうと設置する意味がな

くなります。このことは、多くの管理者を悩ませてきました。 現在は、いくつかの方法

によって裏口とならないように設定されています。

まず、裏口の存在を知られないように、サイトで使用している電話番号と、リモート

アクセスの電話番号を大きく離してしまうということが必要です。

特に、代表電話番号とリモートアクセスの番号を大きく離すことによって、 類推す

ることができなくなります。しかしながら、ウォーダイヤリングによって攻撃者が偶然見

つけてしまうこともあります。このためには、コールバックを設定する方法があります。

コールバックによって、クライアントから着信した後、一旦電話を切ります。 そしてサ

ーバ側から設定された電話番号にかけることになります。 これによって、たとえば社

員の自宅など、 あらかじめ登録しておいた電話番号にのみ電話をかけることになり

ます。

ウォーダイヤリングが行われたかどうかはログを確認することで判ります。

特に、コールバックが設定されていると、攻撃側は何度か電話をかけなおします。

接続後、勝手に電話が切れたことが、モデムや回線状態によるものか、 コールバッ

クが設定されているのかを確認するためです。

コールバックの仕組を導入することが難しい場合もあります。ユーザが公衆電話や

出張先のホテルなどから電話をかける場合などです。 この場合は、コールバックで

処理できないため、 ユーザ認証に頼るしかありません。ユーザ認証のみで運用した

場合、 類推したユーザ名やパスワードを入れられる危険性を含んでいます。このた

めに、コールバックを行わない場合は、リモートアクセスが使用できるユーザを限定し

なければなりません。 そして、そのユーザは定期的にパスワードを変更し、変更する

パスワードも類推が難しいものでなければなりません。

まとめ

• 電話番号はサイトで使用している電話番号と離れたものにする • コールバックの利用 • 常にログを確認する • リモートアクセスは必要なユーザにのみ提供する

5.3 spam

spam は配信されるだけでも不快なものです。 しかし、これが踏み台となってしまう

と事態は深刻です。何万件もの宛先にメールを配送するため、 実質的にメール機能

が麻痺してしまうこともあります。

メール機能が麻痺してしまうだけではありません。 自身が spam メールを受け取っ

た場合に不快だと感じたように、 今まさに中継しているメールを受け取った相手も不

快だと感じます。場合によっては、受け取った方から抗議があるかもしれません。

この抗議の対応も行わなければなりません。 しかし、何よりも先に現在の中継を止

めることが先決です。

もし、踏み台となってしまった場合、気づいた時点でキューの削除を行います。 ス

プールは、多くの UNIX システムの場合は/var/spool/mqueue です。 Exchange 2000

の場合は SMTP サービスにあります。ここにあるメールを削除または移動することに

より、 現在配送を行っているメールを止めることができます。この時に、sendmail のプ

ロセスや SMTP サービスを停止しておかなければ、 次の spam が届く可能性がありま

す。キューからメールを削除または移動する際は、 必ず sendmail や SMTP サービス

を停止し処理してください。 もちろん、ネットワークインターフェースからケーブルを抜

く方法もあります。

そして、サービスを再開する前に、 本書で解説している設定を書き加えてくださ

い。

まとめ

• 構築時に spam防止の設定を行う • 定期的にキューの確認を行う • 踏み台になった場合はキューから削除

5.4 IP Spoofing

IP Spoofing を発見することは困難です。

発見するにはルータを監視することです。 ルータの外部から内部に対するトラフィ

ックを監視し、 ソースとローカルドメインにある宛先アドレスの両方を含むパケットが

通過したとき、 IP Spoofing が行われていると考えられます。

ルータで検出されない場合があります。 それは、LAN 上で IP Spoofing が行われた

場合です。

IP Spoofing を行うには、 偽装する IP アドレスを持つホストを停止させる必要があり

ます。 たとえば DoS 攻撃などを仕掛けますが、LAN 上であればこの必要はなくなりま

す。 偽装する IP アドレスを操作している人が帰宅する時間まで待ち、 クライアントの

電源が落とされた後に偽装すれば良いのです。

LAN上のIP Spoofingは、ルータなどでロギングできないため発見すること非常に難

しいこととなります。さらにネットワークがスイッチング環境で構築されていると尚更で

す。

現在のところ、全ホストに対して監視用のモジュールを組み込み、 インターフェー

スを監視する方法がとられています。

しかし、監視のためのアプリケーションも必要となり、 非常に高価なものとなります。

また、インターネットから来るパケットについては、ルータでフィルタリング可能な製

品もあります。

また、IP Spoofing と類似している DNS Spoofing では DNS のエントリが書き換えら

れ、 Web クライアントは全く別のサーバを参照するようになります。

本物の Web サイトは全くの無傷であるにも関わらず、 たとえば www.ipa-sec.com

が DNS で関連付けられている 172.16.0.1 という IP アドレスが 攻撃者が用意した

10.1.1.1 という IP アドレスに書き換えられてしまう(またはセッションを奪われる)というこ

とになります。これは、DNS の設定を行うことでほとんど対応可能です。

まとめ

• ルータを監視する • ルータを通過していない場合は LAN上からの可能性

5.5 パスワード解析

パスワードを盗まれた場合、 特に管理者のパスワードを盗まれた場合は大変なこ

とになります。root や Administrator など管理者のアカウントでは、 システム内で大抵

のことが行えます。

ユーザ名さえ判れば、パスワードが解析されるのは時間の問題です。

辞書に無い文字列を使用していたとしても、ブルートフォースアタックでは時間さえ

あれば必ず見つかります。

重要なことは、解析者に対して時間を与えないということです。つまり、パスワードは

頻繁に変更するという基礎的なことの実践が重要になってくるのです。 しかし、ユー

ザはお願いしてもなかなか変更してくれない場合もあります。 このときは、システム

側で強制的に有効期限を設定し変更を促す方法があります。

もし、"password"といったパスワード文字列やユーザ名と同一のパスワード文字列

を使用していた場合、解析する時間は短くて済みます。 このとき解析する側は、辞書

攻撃を行えば良いのです。

低でも辞書攻撃による解析は避けなければならないことです。

辞書攻撃を避けるためには、ユーザに対してお願いする必要があります。 しかし、

これもなかなか浸透しません。この場合、定期的に管理者が解析すれば良いのです。

管理者が定期的に解析し、解析できたユーザには変更させるという地道な作業が必

要なのです。

まとめ

• 定期的なパスワード変更 • 類推されにくいパスワード文字列 • 有効期限の設定 • 管理者による定期的な検査 • パスワード情報が漏れた場合は全てのユーザパスワードをリセット

5.6 盗聴

ネットワークの盗聴は、確実にパスワードなどの情報が漏れてしまいます。

これを防ぐためには、平文で通信を行うサービスを停止させることが必要です。 た

とえばtelnetの代わりにsshを、POP3の代わりにAPOPを使用します。これによって、

データが暗号化され盗聴されにくくなります。 ただし、APOP に関してはメールの本文

は暗号化されません。 そして、メールを送信するときに使用する SMTP においても、

メールの本文は平文で流されます。

もし、本社と営業所といった社内のサーバ同士で遠隔地にあるサイトであれば常に

1 対 1 で通信を行うことが多いでしょう。 この場合は VPN を使用しデータの暗号化を

行う方法があります。 これによって途中の経路で盗聴されないようにすることができ

ます。

しかし、不特定のサイトと通信を行う場合は全てのサイトに対して VPN を設定する

ことは不可能です。 この場合は、メールを送信するユーザが個別に PGP などを使用

してメール本文を暗号化するしか方法はありません。

盗聴が も行われる環境は LAN 内においてでしょう。 ユーザが自由に盗聴できる

環境と言えます。

この場合の対策は、ネットワークをスイッチング環境にするといった方法があります。

そして、ユーザが使用できるポートを固定します。これによって、物理的にネットワーク

を変更しなければ盗聴が難しくなります。

現在実験が進められている次世代の TCP/IP である IPv6 では、 プロトコルの仕様

において暗号化が定められているため、IPv6 までの間は暫定措置をとるしかないでし

ょう。

まとめ

• telnetや POP3など平文を使用するものを停止 • sshや APOPへ移行 • 遠隔地とは VPNで接続 • 個別に PGPで対応 • LAN内の盗聴はスイッチング環境へ移行 • アカウント情報が漏れた場合はアカウントのリセット

5.7 DoS

IP Spoofing より更に難しいものが DoS です。

この発見と対策は非常に難しく、被害に遭うサイトも少なくありません。

まず、プログラムの問題を利用した DoS に関しては対処されたバージョンに入れ替

えることや、使用しないサービスであれば停止するという方法で解決します。たとえば、

UDP Storm においては echo サービスの問題点を利用したものです。 この対応は、

echo サービスを inetd.conf から削除し停止することと、 ルータのポートを塞ぐという方

法で対応可能です。しかし、その他の DoS に対しては手法が様々なため一律な効果

が得られる対策はありません。

管理者に求められることは、 たとえばネットワークインターフェースの状態を常に

監視するといったことです。 これは netstat コマンドで状態を確認することができま

す。

まとめ

• 不要なサービスを起動しない • 不要なポート塞ぐ • ネットワークインターフェースの状態を監視する

5.8 リモートコントロール,バックドア,トロイの木馬

リモートコントロール,バックドア,トロイの木馬の 3 種類は、 相互に深い関係があり

ます。

文献によっては、これらはトロイの木馬の範疇で取り扱うものもありますが、 明確

な切り分けは難いものです。

これら 3 種類はサイトのサーバだけでなくクライアントにも仕掛けられる可能性があ

ります。特に、クライアントに仕掛けられるときには、Web の閲覧やメールに添付され

たファイルに混入している場合などがあります。ここをきっかけにユーザ情報が漏れ

たり、 遠隔地から操作されるといった問題が発生します。

これらの検出には、ウィルスの検査ツールを使用することができます。 ウィルスの

検査ツールには、これら 3 種類を検出できるものが多いため、 導入時にウィルスだけ

ではなく、これら 3 種類のモジュールも検出できる製品を選択することが必要です。さ

らには、Web の閲覧に関しては、Web クライアントの設定を義務付けることや、 Proxy

で排除する製品の導入、メールの添付ファイルでもメールサーバで検出する製品の

導入などがあります。

また、リモートコントロールのモジュールが使用するポートをルータで全て塞ぐ方法

も有効です。このとき、外部から内部に対してだけでなく、内部から外部に対するパケ

ットもフィルタリングする必要があります。

なぜなら、バックドアのモジュールには自律的に取得した情報を発信するものもある

ためです。

もし 1 つでも発見した場合は該当モジュールを削除するだけでなく、 他にも仕掛け

られている可能性を考え、システムを再インストールすべきです。

このとき重要なことは、必要なデータを以外は全て再設定するということです。 バ

ックアップツールを使用しテープ装置などにバックアップとして保存した場合、 これら

のモジュールも一緒にバックアップされる可能性があるためです。

まとめ

• ウィルスの検査ツールを導入 • 発見した場合はシステムを再インストール

5.9 Web Page 改竄

Web Page が改竄されるときの原因はいくつかあります。

中でも多い例が、アカウント情報が漏れたものと、セキュリティホールを突いてコマ

ンドを実行したものです。

たとえば、Windows を使用していた場合、ポート 137.138.139 を開放していたばかり

に、 アカウント情報が漏れ、デフォルト共有と呼ばれる共有から Web の文書が改竄さ

れるといった例が過去のバージョンでありました。

Windows 2000 となった現在では、これらの手法は異なってきていますが、 基本的

にアカウント情報とセキュリティホールを突いたものが中心となっています。

また、DNS のエントリを改竄し、攻撃者のサーバに DNS の情報を向けてしまうとい

う手法や、ドメイン管理者を装いドメイン情報書き換えるという手法もあります。

まとめ

• ソフトウェアのバージョンを常に最新にする • Web以外のサービスにも気を配る • httpdの権限や HTML文書の権限を確認する

5.10 スクリプト

スクリプトによる問題はこれまでとはやや異なっています。 提供されているコンポ

ーネントやスクリプトであれば、 新版を入手することによって対応可能です。

しかし、CGI スクリプトなどでは比較的簡単に書けるということと、入門書が揃ってい

ることから、プログラミングに詳しくない方でも作成できてしまいます。 このため、例外

処理などを見落としがちです。

スクリプトを書くときは、あらゆるデータが渡されるということを念頭に、 慎重に作

成,テストを行うようにしてください。 また、実行時の権限も、必要 小限度、できるこ

とならば CGI 用のユーザ権限で動作させるようにしてください。

まとめ

• 慎重に作成 • ユーザ権限を限定

セキュアな環境を維持するために

冒頭に述べたことの繰り返しになりますが、 セキュアなサイトを作成するには、ま

ず攻撃の内容を知るから始まります。 攻撃によって対策が異なるためです。そして、

対策後は常にサイトの状態をチェックしセキュリティ情報を収拾しなければなりません。

たとえば、セキュリティホールが新たに発見された場合、 既に何処かで攻撃が行わ

れたと考え対策をとるのです。

セキュアな環境を維持するためには、この 3 つを繰り返すことが必要なのです。

付録

• 主要セキュリティ情報サイト • 関連ソフトウェア • 参考文献

セキュリティ情報主要サイト

セキュアな環境を構築し維持するためには、セキュリティ情報の収集が必要です。

以下に主要サイトを紹介します。

CERT http://www.cert.org/

JPCERT/CC http://www.jpcert.or.jp/

CIAC http://www.ciac.org/ciac/

ISS http://www.iss.net/

Security Focus http://www.securityfocus.com/

NT Bugtraq http://www.ntbugtraq.com/

関連ソフトウェア

OS ごとのセキュリティ情報や、 各ソフトウェアの 新バージョンは以下の URL を参照

してください。

FreeBSD http://www.jp.freebsd.org/

Red Hat Linux http://www.redhat.com/

マイクロソフト

http://www.microsoft.com/japan/ BIND

http://www.isc.org/ sendmail

http://www.sendmail.org/ qpopper

ftp://ftp.qualcomm.com/eudora/servers/unix/popper/ wu-ftpd

http://www.wu-ftpd.org/ OpenSSL

http://www.openssl.org/ OpenSSH

http://www.openssh.com/ Apache

http://www.apache.org/ Apache-SSL

http://www.apache-ssl.org/

参考文献

本書作成にあたり、以下の文献を参考にさせて頂きました。

HACKING EXPOSED Second Editon Joel Scambray, Stuart McClure, George Kurtz著 Osborne/McGraw-Hill

Maximum Security: A Hacker's Guide to Protecting Your Internet Site & Network Anonymous著 Sams

Linux版クラッカー迎撃完全ガイド (Maximum Linux Security) Anonymous著/トップスタジオ訳 ソフトバンク

Building Internet Firewalls (2nd Edition) D. Brent Chapman, Simon Cooper, Elizabeth D. Zwicky著 O'Reilly & Associates Inc.

ルータ&パケットフィルタリング―闇の手からサイトを守る!!あなたのサイト、大丈夫です

か? 村嶋修一著 情報管理

PC�UNIXサーバのためのクラッカー撃退計画―Driving the Crackers Out! まえだひさこ著 翔泳社

ハッキング防衛対策ガイドブック (HACK PROOFING Your NETWORK) Ryan Russel & Stace Cunningham 他著/ホンヤク訳 ビー・エヌ・エヌ

Windows 2000セキュリティ Black Book Ian MacLean著/金子卓也監修/トップスタジオ訳 インプレス