攻撃 - みる会図書館


検索対象: UNIX MAGAZINE 2000年8月号
27件見つかりました。

1. UNIX MAGAZINE 2000年8月号

いつでも使えるインターネット 「私の言算機 ( サイト ) には盜む価値のある 1 帯長はないから・・ と言ってセキュリティ対策を講しない人がいます。こういう人は、 おそらく則記のようなイメージをもっているのだと思います。 皆さんの言 1 算機を攻撃するのは、このような SF 的な侵入者で はありません。 99.999... パーセントは Script Kiddie と呼 ばれる輩です。 Script Kiddie とは、、お手軽に " 侵入できる計算機を探し求 める者たちです。彼らの目的は、なんらかの情報を得ようとした 、なるべくお手 り、狙いをつけた企業に侵入することではなく、 軽に " 侵入し、、なるべくお手軽に " 管理名権限を奪うことです。 そして、侵入した言算機から別の計算機へ侵入し、それを限りな く繰り返します。「なぜ ? 」と訊いてはいけません。「そんなことし て何か楽しいのやろ」と考えても無駄です。そういうものだと思っ てください。 Script Kiddie は、計算機に侵入するために、いくつかのセ キュリティ・ホールを攻撃するプログラムを使用します。これ らはひろく知られたセキュリティ・ホールで、たいていの場合は CERT/CC からすでに報告されています。さらにいえば、報告 されてから半年以 - はを茴したものを攻撃する場合がはとんどです。 ー殳には知られていないセキュリティ・ホールか攻撃されるこ ともありますが、ごくごく稀であり、そもそもそのような攻撃を するのは Script Kiddie ではありません。 Script Kiddie カイ屯用する攻撃プログラムは、アンダーグラウ ンド・サイトからダウンロードしたものです。自分で作ることもあ るかもしれませんが、これもめったにありません。多くの Script Kiddie は、攻撃プログラムがセキュリティ・ホールに対して何を するのかを理解していません。おそらくは、使い方も十分には理 解していないでしよう ( 丘の攻撃フログラムの多くは、 Script Kiddie 対策として、そのままでは動かないように書かれていま す。ただし、伺属のドキュメントを読めば、どこを修正すれはよ いのかが分かるようにはなっています ) 。 Script Kiddie が 1 回の攻撃で対象にするセキュリティ・ホー ルの不頁は、通常は片手で数えられるほど、多くても両手で数え られる程度とごく少ないのか特徴てす。すべての不頁の攻撃に失 敗した場合は侵入をあきらめます。 こオけごけて終るのなら、、興未本位でやってみた " だけの、にわ かクラッカー " です。 Script Kiddie のもう 1 つの特徴は、攻撃 する計算機の数が尋常ではなく、たいていは佃佰 ~ 何千台の言算 機に次々と攻撃を f 廱トけることです。そして、、たまたま " セキュ リティ・ホールをふさいでいなかった計算機を探すのです。 Script Kiddie は、まず最初に攻撃する計算機のリストを作成 するプログラムを実行します。次に、そのリストにある計算機に 対して攻撃プログラムを実行します。この 2 つのプログラムは、 別々であることもあれは、 1 つのパッケージにまとめられている こともあります。リストの作成と攻撃は同時におこなわれるとは かぎらす、ある程度の日数をおいて実行されることもあります。 攻撃対象のリストを作成するガ去はいろいろありますが、たと えば、次のようなものか上如勺よく用いられるようです。 特定の範用の IP アドレス空川すべて たとえは、、このプロバイダのユーザーはセキュリティ対策が 甘そうだ " と見当をつけ、その ISP の管轄ードにある IP アドレ 56 スのプロック全体を攻撃することがあります。しかし実際の ところすべての IP アドレスに言 t 算機か割り当てられているわ けではないので、アクセスのタイムアウト待ちなどを考えると 攻撃の効率はあまりよくありません。 ・ DNS のゾーン中幻逶を利用 DNS のゾーンデータのなかには、サブドメイン名やホスト名、 IP アドレスなどの情報か書かれています。これを利用すれは効 率よく攻撃できます。 ・ IP スキャンツールを利用 特定の範用の IP アドレス空間本を効率的にスキャンし、接 続されている計算機を探し出すようなツールを利用してリスト を生成します。この種のツールのなかには、計算機 ( ルータも 含む ) て動いている OS の不頁やバージョンを孑則できる機能 をもつものもあります。たとえば、その後に攻撃するセキュリ ティ・ホールか特定の OS に依存するものである場合、この OS 擱印腰能を利用すれは、たいへん効率的な攻撃かて、きます。 ・ドメイン名のリストか引則 ドメイン名の前に www や ftp 、 ns 、 mail など、よく使われ るホスト名を j 助日してリストを作ることもあります。この場合、 ドメイン名のリストをもっていることがⅲ醍になりますが、各 地の NIC からダウンロードしたりにのような不正使用が原 因で、現在は非公開になっていることが多いようです ) 、アン ダーグラウンドで出回っているリストを入手したりします。す こし頑張れば ( ? ) 、サーチェンジンの本結果から生成するこ とも可能です。 Script Kiddie は特定のサイトを狙って攻撃しているわけでは ありません。困ったことに、現在このような Script Kiddie は 星の数ほど・・・・とはいわないまでも、とにかくかなりの人数がい るようです。その結果、インターネットに接続したその日から攻 撃を受けることもあります。サイトによっては、毎日のように攻 撃さその数があまりに多いので日常化しているところさえある そうです。 「 Script Kiddie の攻撃を防ぐ力法はないの ? 」 残念ながら、 Script Kiddie は手当たりしだいに攻撃してくる ので、インターネットに接続しているかぎり防ぐ方法はありませ ん。しかし、攻撃から守るのは簡単です。 Script Kiddie による 攻撃の大半は、一イ殳によく知られたセキュリティ・ホールの悪用を 試み、失敗すればすぐにあきらめるといった叫屯明快なものです。 そのため、 CERT / CC ゃべンダーから送られてくるセキュリティ のドキュメントに従って対策を講したり、ファイアウォール て攻撃を遮断するようにしておけば、被害を未然に防ぐことかて、き ます。 ところが、ある日、どこかの国の Script Kiddie が、たまた 、たまたま " 皆さんの言算機を攻 ま " 実行した攻撃プログラムが、 撃し、、たまたま " 未対策のセキュリティ・ホールへの攻撃に成功 することもあります。「自分だけは大丈夫」という油断は禁物てす。 UNIX MAGAZINE 2000.8

2. UNIX MAGAZINE 2000年8月号

以上インターネットと通信できなかった ) を受けて話題に なりました。 このような攻撃を受けた場合は、サイト内のファイア ウォールだけでは手の打ちょうがなく、 ISP の協力がな けれは解決できません。 大量のバケットで通信を妨害する方法以外にも、ファイ アウォールを構成する計算機の OS やプログラムのバグを 悪用し、ファイアウォールを停止に追いやる攻撃も知られ ています。 描丘の自己増歹嵒ウイルスは、感染した言算機だけでな く、サイトのサーバーにも大きな景グをおよほすことがあ ります。個々のユーザーに注意を促すことも大切ですが、 すべてのユーザーがウイルス・チェッカーを使用し、しか もつねに最新のパターンファイルを適用しているとは思え ません。・は、侵入などの攻撃から系目織ネットワークを 守ることと同しくらいに、ウイルス対策の必要生も高くな るでしよう。 現在の多くのファイアウォールは、ウイルスをフィルタ リングする機能はもっていません。ューサーがダウンロー ドするファイルや、メールに添付されているファイルに寄 生しているウイルスを検知し、除去したり廃棄したいので あれは、専用の製品を別懾入してファイアウォールに組 み込む必要があります。 ウイルスと同様、 Java のアプレットや ActiveX コン トロールのなかに悪意あるコードが埋め込まれていること があります。そして、ファイアウォールはこれらのコード の流入を防ぐことはできません。 悪意あるデータを送り込む攻撃もあります。 CGI のセ キュリティ・ホールはその代表例です。 内部ネットワーク上で硬われているクライアント・プロ グラムか特定のデータに反芯し、セキュリティ上の問題を 惹き起こすこともあります。つまり、サーバー側になんら こ数年の攻撃手法をみると、魏重類の既知の攻撃が膨大な数 の計算機に対しておこなわれる傾向か顕著になってきたのが分か ります。 、不正侵入者 " と聞いて多くの人が思い描くイメージは、豊富な知 識をバックに、狙いを定めた攻撃先の言算機システムにさまざま UNIX MAGAZINE 2000.8 個人の常時接続環境を考える ( 2 ) Script Kiddie かの f 廱トけをしておき、クライアントがアクセスするのを じっと待つのです。アリ地獄のような攻撃ですが、実際に いくつかの手法が知られています。 攻撃のロは苦手 ファイアウォールは攻撃を櫞ロするための装置ではない ので、積極的に本鎹日しようとはしません。ファイアウォー ルか第当できるのは、、、拒否した " 通信に関するログだけ そのログを見て、攻撃かどうかを判断するのは管理者の 仕事です。 「はな、ファイアウォールのログって意味ないやんか」 管理者がログから攻撃を本鎹日できれば、攻撃元や攻撃の 不頁を調べるための有益な情報となります。したがって、 ログの言当求は無意味ではありません。特別な理由がなけれ は、残しておくことをお勧めします。「セキュリティ対策 は必要 ? 」の節で紹介した不正アクセス禁止法の第 5 条の 規定により、ファイアウォールの管理者にはログを言求す る ( 努力 ) 義務があるという解釈もできます。 積極的に攻撃を検出したいのであれは、 IDS (lntru- sion Detection System) という機器を導入します。た だし、 IDS はまだまた、発展途上の分野なので、あらゆる攻 撃に対応できるわけではありません。本当は攻撃ではない ものを攻撃だと言縣忍することもあります。現伏では、 IDS を導入しても気休め程度て終ってしまうかもしれません。 ☆ 今回は、ファイアウォールを導入・構築する際に必要な 基礎矢日識について説明しました。次回は、いくつかのルー タ製品を用いてファイアウォールを構築する例を紹介し ます。 ( しらさき・ひろお IIJ) な手段て侵入するといったものではないでしようか。映画のよう に、軍のネットワークに侵入したり、企業から情報を盗んでライ バル企業に売ったりするようなことを想像している人もいるかも ときどき、 しれません。 55

3. UNIX MAGAZINE 2000年8月号

いつでも使えるインターネット れません。インターネットに接続しているかぎり、誰で 現在のインターネットでは、攻撃を受けるのは避けら 自分の期布から飛んでいって戻ってきません ) 。 払えば守ってくれる人 ( 会社 ) はありますが、そのお金は トを代わりに守ってくれる人もいません ( もちろんお金を 法律ですべて解決できるとは思えませんし、皆さんのサイ のを待っしかないのでしようか。しかし、現在のところは 律の整備に期待するか、あるいは誰かカ嘯になってくれる を守るのも大仕事です。このような不正行為を打阯する法 いって、手を替え品を替えて攻めてくる相手からシステム こんな攻撃を受けて喜ぶ人はますいないでしよう。かと ・運用妨害 ・メールの第三者中継 1 帯長交換の場としての利用 ・踏み台としての利用 ・ファイルの書奐え ・計算櫞の侵入 ・ファイルの覗き見 参照してください ) 。 かでも多いのは、次のような攻撃です ( 詳しくは 2 月号を のよりも、攻撃を受ける可能性カ蔀寉実に高くなります。な PPP ダイヤルアップなどにより間歇的に接続しているも 果として、インターネットに常日判妾続している計算機は、 ている計算機ならはどれでも ( どこでも ) いいのです。結 で攻撃しているのではなく、インターネットに常日判妾続し 「こいつ、 xxxx やからやつつけたろ」などと相手を選ん 当たる " 方式でおこなわれます。つまり、攻撃者の大半は りました。現在の攻撃の多くは、、、下手な鉄砲も鼬寸ちゃ コストの低下にともない、攻撃去も昔とは大きく変わ それを助ける、、イ叫リな " ツールも作られています。 の言算機への攻撃もそれはど難しくありません。さらに、 時間に膨大な数のパスワードを角財斤することができ、大量 処理能力か高く、ネットワークも高速です。そのため、短 攻撃に必喫なコストも下がっています。現在の言算機は 無科で入手できます。 ことに、それらの道具のほとんどは上交的簡単に、しかも 者と同しレベルの攻撃をおこなうことができます。困った 攻撃の仕組みをよく知らない初心者でも高度な技術をもっ るものもあります。そのようなプログラムを利用すれは、 36 も攻撃される可帽生があります。そこて大切なのは、攻撃 に対する防御を固めることです。そして、万一攻撃されて も、その被書を最小限にとどめるような対策を講じておき ましよう。 防御のための道具を使ってセキュリティ対策を講しる のはユーザーの責任ですが、自分で道具を作る必要はあり ません。これらは上如勺簡単に入手できます。あとは、自 分のネットワークに合わせてカスタマイズするだけです。 ほんのすこしの出費と手間を惜しまなければ、被書を受 ける可能性を大幅に減らせます。この出費と手間かセキュ リティ文です。そして、インターネットに接続するすべ ての計算機にはセキュリティ文が要です。 技術をうまく使おう 攻支術の高度化に対抗して、計算機やネットワークの セキュリティを高めるための技術も次々と開発され、い ろいろなツールが入手できるようになってきました。さら に、多くの人に使われることによってツールの完成度が高 まり、なかには OS の一部に含まれるようになったもの もあります。とりわけ、 OpenBSD は隅々までセキュリ ティに気を配って設計さオ、インストール直後から安全 な状態で漣用できるように作られています。こまでくる と、 OS そのものがセキュリティ・ツールといってもいい ほどです。 この特集では個々のツールの紹介はしませんが、イン ターネットには防御のための技術もツールも揃っていま す。フリーで配布されているイ甦リなツールもたくさんある ので、ありがたく利用させてもらうこともできます。もし かすると、いま皆さんカ硬っている OS にもこれらのツー ルがインストールされているかもしれません。 セキュリティ・ツールは使い方を間違えると意床がなく なるだけでなく、みすからセキュリティ・ホールを作って しまう場合もあります。面倒かもしれませんが、マニュア ルをよく読んだうえて利用してください。 重要なのはに使うことです。あとはやる気の間題で す。上手に使いこなしましよう。 昨年から今年の初めにかけて、テレピや新聞て不正アク セス禁止法 2 がどうしたこうしたと報しられていたのを憶 2 ーしに名称は坏正アクセス行 ) 禁 1 ト等に関する法律」で、 1999 年 8 月 に国会で成立し 2000 年 2 月 13 日から施行されています。 UNIX MAGAZINE 2000.8

4. UNIX MAGAZINE 2000年8月号

いつでも使えるインターネット からのアクセスを許可しない " と決めているときには、 の方法は使えません。 いさぎよくあきらめるのも 1 つの考え方ですが、モデム 経由でアクセスできるリモートアクセス・サーバーを運用 するガ去もあります。ところが、このリモートアクセス・ サーバーが思わぬ落し穴になることがあります。 リモートアクセス・サーバーから内部ネットワークへの アクセスは、インターネットからのアクセスと同じくらい 注意して扱わなけれはなりません。事実、インターネット 側ははは完璧に守っていたのに、リモートアクセス・サー バーか無防備だったため、そこから侵入されたというケー スも多いようです。 モデムボートの電話番号を知っていることを認証の手段 にしてはいけません。つまり、「この番号は、社員しか知 らないはすだから・・・・」と仮定してはいけないというこ とです。 通常は、モデムに接続したあとでユーサー言陸要求す るように設定します。しかし、これはインターネットに対 して TeInet のポートを開放しているのと同しか、はんの すこしマシという程隻です。 リモートアクセス・サーバーを内部ネットワークに設置 するのはたいへん危険です。そして、外部ネットワークに 設置するのも危険です。ほかのサイトへの攻撃の踏み台と して利用されるおそれがあるからです。 リモートアクセス・サーバーを設置する理想的なネット ワークは、内部ネットワークへのアクセスも、外部ネット ワークへのアクセスも制限されているところです。具イ勺 ・・第・第を第第載澱・・鋼・をを強・第第第載物を第第・第物鋼第・第第物・・第第一・鋼第物載・物第第第・第鋼・第第第第・第を第第を第物第 には、 DMZ が考えられます。ただし、公開サーバー用の ものとは別に、リモートアクセス専用の DMZ を新たに作 ります。公開サーバー用の DMZ は内部ネットワークへ のアクセスを禁止しますが、リモートアクセス用の DMZ は、 ( もちろん制限付きで ) 内部ネットワークへのアクセ スを許可する必要があるからです。 専用の DMZ を作る場所については、ファイアウォー ル算機に 4 番目のインターフェイスを追加するか、ある いはファイアウォールのなかにさらにファイアウォール を作り、そのさきを DMZ とする去もあります。 ファイアウォールの限界 ファイアウォールをうまく使いこなし、効果的なセキ ュリティ対策を実現するには、ファイアウォールででき ることだけでなく、できないことも知っておく必要があり ます。 防げない攻撃もある ファイアウォールを導入すると、比較的手軽に攻撃から 内部ネットワークを防御できます。しかし、何回も書いた ようにすべての攻撃がファイアウォールで遮析されるわけ ではありません。ファイアウォールで防げない可能陸のあ る攻撃としては、次のようなものが考えられます。 ・ DoS (Denial of Service : 運用妨害 ) ・ウイルス、ワーム 悪意ある Java アフレットや ActiveX コントロ 悪意あるメッセージ ・クライアント・プログラムのバグ ーノレ ファイアウォール七 防后いステム E 塩さ守に イ士を停滞記さ坂羣訒 . . を見乙いに→ カー中 54 らあ . ぐ 特定のサイトに大量のバケットを連続的に送り、そのサ イトとインターネットとのあいだの回線をバケットて溢れ させる攻撃があります。ファイアウォールがあれは、そ れらのバケットが内部ネットワークに入り込む前に遮析さ れます。そのため、内部ネットワークは攻撃から守れます が、正規の通信をおこなう隙間がないくらい : ンサットが 溢れているので、実質的にそのサイトはインターネットと 切り離された状態になってしまいます。 このタイプの攻撃は、今年の 2 月から 3 月頃、米国の いくっかの有名なサイトか攻撃さ大きな被害 ( 1 週間 UNIX MAGAZINE 2000.8

5. UNIX MAGAZINE 2000年8月号

いつでも使えるインター ネット 図 4 パターン 3 ォールがあるのにサー ー計算機に侵入されることがある のかと疑間に思う人もいるでしよう。 たしかに、ファイアウォールはセキュリティを高めて くれます。しかし、あらゆる攻撃を防いでくれるわけでは つ ありません。ファイアウォールは、あくまでもケえられた 規則にもとづいて通信を制御するだけです。したがって、 イ その規則で許可された ( あるいは明示的に禁止されていな い ) 範川内での攻撃は通り抜けてしまいます。そして、サ オ ーバー・プログラムにセキュリティ・ホールがあり、か っファイアウォールがその攻撃を防御するように明示的 に設定されていない場合、攻撃ははば間違いなく成功しま す。たとえそれが釗・の先のように小さな孔であっても、セ キュリティ上の弱点であることには違いありません。そ もそも、現在のようにプログラムを使って攻撃する日罸にに は、孔の大小は無関係です。たまたま孑しゞ空いていて、た 文献をみかけることがあります。この場合、インターネッ またまそれを衝く攻撃プログラムにアクセスされることも トと公開サーバーとのあいだの通信は、ファイアウォー あります。 ル言算機 -- ヒのフロキシーによって中継させたり、あるいは このため、サーバー側での設疋には細心の注意を払う必 NAT や NAPT を利用しているようです。 要があります。 Apache のように、安全だといわれている このような例は、、、構成が単純でお金がかからない " と プログラムを利用している場合でも、設定に間題があると いうメリットとともに紹介されていますが、たいへん危険 そこから侵入されることがあります (CGI についても同 なので避けたほうが難です。 様です ) 。 この構成では、サーバーへの侵入を許してしまった場 ファイアウォールを設引するときは、、、サー 合、内部ネットワークへのアクセスを止めることができま 機に侵入されることがある " という前提を忘れてはいけま せん。攻撃者の立場て考えると、たとえばサー 一言算機 せん。 上で root の権限を奪い、内部ネットワークに流れるパス サービスごとに異なる計算機を用意する ワードを盗み、それから内部の引・算機へログインする一 - 漣 の攻撃か容易におこなえます。 理想的には、彳難リの異なるサーバーは別々の言 fr. 算機上で 山も丘は、数万円も出せば IP バケットをフィルタリング 運用したほうがよいでしよう。たとえは、 Web と FTP 、 できるルータが買えます。きわめて大切なところなので、 DNS を運用するときは 3 台の言算機を用意します。しか へんにケチったりするのはやめるべきです。 し、お金やスペースといった点で実現できないことがある かもしれません。そのような場合でも、すくなくとも想 的には別々の言算機 - E て運用したほうがよいと憶えておき ましよう。 以下ではサーバーの構築と運用について、いくつかのポ こ数年、 DNS (named) のセキュリティ・ホールが イントを説明します。ただし、 こでは特定のサーバーや 悪用されて書を受けるケースが多発しています。その意 フログラムに関する説明はしません。 味でも、できるかぎり named は独立した計算機で運用 ファイアウォールがあっても侵入される ? したほうがいいと思います。どうしても無理なら chroot こまで、「サーノヾ一言算機に侵入されたときのことを を利用し、さらに一 - ューサー権限で動くように設定しま 考えて・・・・・・」と書いてきました。おそらく、ファイアウ す。このような設定は、 OpenBSD を参考にするとよい インら一ネリト 。。内トワ ~ り サーバーの運用 52 UNIX MAGAZINE 2000.8

6. UNIX MAGAZINE 2000年8月号

いつでも使えるインターネット バケット・フィルタリングとプロキシー ファイアウォールのおもな彳難リは、疑わしいアクセス や通信を拒否して内部ネットワークを攻撃から守ることで す。さきほども述べたように、このイ督目みはバケット・フィ ルタリングまたはプロキシーによって実現することができ ます。 このように複数窈尺肢がある場合には、山絲冬的に、 「で、どっちがええの ? 」 となるでしよう。 攻撃からの防御という点では、原工勺には知識と技術が あれはどちらでもかまいません。ただし、バケット・フィ ルタリングにもプロキシーにもそれぞれ防ぎにくい攻撃が あります。 両者を組み合わせて使えは、一方カ材く得手とする攻撃を 他方か防御してくれるので、より高度なセキュリテイか実 現できます。ただし、そのぶんコストがかかりますし、両 方あ川ますべての攻撃が防げるわけでもありません。 攻撃からの防御以外に ・ノヾフォーマンス ・言当求できるログの不鶤頁 などの点も考慮すべきでしよう。パフォーマンスについて は、一殳にバケット・フィルタリングのほうか有利です。 一方、プロキシーではさまざまなログを言求することがで きます。 山辭冬的な判断のポイントは、許容できるコストと要求す る機能とのバランスということになるでしよう。 UDP とファイアウォール ーイ殳論でいえは、ファイアウォールを介した UDP バケ ットの中継はあまりお勧めできません。というのも、 UDP では TCP のようにハンドシェイクやシーケンス番号が使 用されないため、 TCP と上交してバケットの偽造がきわ めて容易だからです。したがって、送信元アドレスを偽造 したバケットがファイアウォールの内側にたやすく入りこ むおそれがあります。山も丘は、 IP バケット 1 つだけで成 立するような攻撃がたくさんあるので、不用意にバケット 50 とはいっても、 を内部に流入させるのは避けるべきです。 「 UDP バケットは立入禁止 ! 」 と簡単には言いきれません。たとえは、マルチメディア系 のアプリケーションの多くは UDP を用いて通信します。 企業であれば、「そんなもん、仕事には関係ないやろ」の 言ですむかもしれませんが、家庭で常日妾続する場合は 状況が異なるはすです。蕕葉やビデオを楽しむためにイン ターネットに接続しているのに、これらのサービスが使え ないのでは、それこそ「意味なーいしゃーん」と言われそ アプリケーションによっては、フィルタ規則か書きやす くなるように使用する UDP ポートを固定したり、 TCP を使うオフションを用意しているものや、専用のフロキシ ・サーバーを提供しているものもあります。これらを利 用するのも 1 つのガ去でしよう。しかし、この種のサー ビスではサイト (URL) ごとにアクセス方法が異なる場合 も多いので、そのたびに設定を変更するのではたまりませ ん。そのうちに、どのオフションをどう設定したらよいの かと頭が昆乱してきて、しまいには「そこまでする価値が あるんかなあ」などといった根本的な疑間に悩まされるか もしれません。 現在、マルチメディア系アプリケーションの通信につい て RTSP (Real Time Streaming Protocol) というプ ロトコルて驃準化しようという動きもあります。今後 れが一ヨ麺勺になれは、一 E 記のような事態は改善されるかも しれません。 公開サーパーをどこに置くか Web や FTP 、 DNS など外部に対して公開するサー ーを運用する場合、各サーバーのセキュリティ対策は当 然として、どこに配置するかも慎重に考える必要がありま す。その言に応して、守るべき内部ネットワークの安全 性か変わるからです。 以下では、いくっかの典型的なパターンを紹介し、それ ぞれのポイントを説明します。 基本的な考え方 すべての場合について、サーバー計算機に侵入されたと いう前提で考えます。このとき、サーバー言 t 算機への侵入 が、内部ネットワークへの足掛かりとならないように言妬 するのカ本です。 ノ、 UNIX MAGAZINE 2000.8

7. UNIX MAGAZINE 2000年8月号

RFC ダイジェストー RFC2832 で定義されているのは、 RRP のプロトコル・ BCP. 、 P Ferguson 他 ( RFC2267 置換 ) ( 別称 BCP 38 ) デザインと、ドメイン名登録に必要な機能を提供するコマ IP バケットの始点アドレスを言′ : した DOS けーピス ンド君物 ) 田である。 不能 ) 攻撃を防ぐためのガ去として、ネットワークの境界 でのフィルタリングを提案している。ン則点での最良の RFC2860 Memorandum of Understanding Concern- ing the Technica ハ /Vork ofthelnternet Assigned Num ガ去 " として 2000 年 5 月に公開された。 RFC2267 を置 bers Authority き換えている。 BCP シリーズ (BCP 38 ) としても公開 IANA の業務に関する協定書 されている。 fo. 、 B. Carpenter 他 インターネットの普及により、そのユーザー数やユー 2000 年 3 月 1 日に IETF と ICANN (lnternet Cor- サー層は引瞿的に増大した。これはたいへん望ましいこと poration for Assigned Names and Numbers) のあ だが、その一方でネットワークを利用した悪意の攻撃によ いだで調印され、 3 月 10 日に ICANN で承認された る被害も増大している。なかでも、ネットワークを利用し 「 IANA の業務に関する協定書 (MOU 文書 ) 」を公開し て被害者のホスト / サイトでのサーピスを停止させる DOS ている。、、広報 " として 2000 年 6 月に公開された。 攻撃は、 ISP ( インターネットサーピス・プロバイ夘は この MoU は、 IETF と ICANN のあいだの合意事項 もとより、インターネットに接続されているすべての組織 を記した文書である。これまで IETF および IRTF を補 にとってきわめて有害であり、さまざまな刈策を駆使して 完してきた IANA の業務について述べている。 に E しなければならない。 DNS 関連 RFC2827 では、インターネットの接続点 (ISP のダ イヤルアップ・ポートなど ) から始点アドレスを偽造して RFC2845 Secret Key Transaction Authentication for 侵入してくる DoS 攻撃を仙 . E するために、ネットワーク DNS (TSIG) への流入トラフィックのフィルタリングを提案している。 TSIG : DNS 用の秘密鍵トランサクション認証 始点アドレスによるフィルタリングは、すべての DoS PS. 、 P. Vixie 他 ( RFC1035 更新 ) 攻撃を阻止するものではないが、すくなくとも始点アドレ 共有秘密鍵を用いたトランザクション認証である TSIG スを偽造した ( すなわち攻撃である可能性の高い ) バケッ を定義している。現在の状態は、、標準化への提唱 (Pro- トがインターネットに侵入することは防げる。 RFC2827 posed Standard)" である。 RFC1035 を更新する RFC では、ユーサーにインターネットへの接続点を提供する として 2000 年 5 月に公開された。 ISP は、自分の管工危囲内にあるアドレスプロック以外の DNS はインターネットの基幹システムであり、そのセ 始点アドレスをフィルタリングすることを推奨している。 キュリティの向 .- ヒを求める声は多い。たとえば、クライア ントからの重加勺更新に対する認証や再帰ネームサーバーか RFC2828 lnternet Security GIossary らの応答に対する認証が必要と考えられている。 インターネット・セキュリティ用語集 fo. 、 R. Shirey ( 別称 FYI 36 ) RFC2845 では、共有鍵および一方向ハッシュを用い てトランザクション・レベルの認証をおこなうプロトコル インターネットのセキュリティに関連する用語集であ である TSIG を定義している。 TSIG を用いることで E る。、、広報 " として 2000 年 5 月に公開された。 FYI シ 己の要求を充足・可能である。 リーズ (FYI 36 ) としても公開されている。 ー殳の用語集や辞書と同様に、用語力ワルファベット順 セキュリティ関連 に説明されている。セキュリティ関連の RFC などを参照 RFC2827 Network lngress Filtering: Defeating De- する際に利用するとよいだろう。 nial of Service Attacks which employ 旧 Source Ad- dress Spoofing RFC2831 Using Digest Authentication as a SASL ネットワーク入口フィルタリングコ P 始点アドレス淋 Mechanism を用いた DoS 攻撃への対応 ダイジェスト認証を用いた SASL 機構 一三ロ 139 UNIX MAGAZINE 2000.8

8. UNIX MAGAZINE 2000年8月号

・ OS 強固なシステムを作りやすい OS を選びます。とくに、 外部から特殊なバケットを受信するとシステムが停止し たり、再起動したりするような DoS (Denial of Ser- vice : 運用妨害 ) 攻撃に弱いものを選んではいけません。 OS として不安定なものも避けるべきです。攻撃によっ て異常な状態になったのか、自身のバグで異常状能に なったのかの区別がつかないからです。 とはいっても、不れな OS はできるかぎり避けたほ うか賢明です。管理者が、自分できちんと管理できる自 信のある OS を選びましよう。 ・サービス構成 サービスを提供する対象や内容を区別し、それぞれの組 合迂に適した構成にします。 たとえば、組織の外部に提供するサービスと内部に提供 するサービス ( サービスの提供対象が異なるもの ) は、 けして同し言算機十に構築してはいけません。管理者権 限 (root 特権 ) で実行されるサーバープロセスについ ては、そのような権限か不要なものに入れ替えたりしま す。 さらに、提供するサービスに不要なサーバープロセスは 停止し、可能であれは、里するファイルやプログラムも 削除します。 また、動作しているプロセスと LISTEN ( 接続要求待 ち ) 状態で開いているポートを定期的にチェックし、想 定していないプロセスやポートを発見したら警告を発す るようなプログラムを動かしておくとよいでしよう。こ こ数年、ひろく使われている攻撃プログラムのなかに は、攻撃に成功したときにネットワーク・サーバーを 仕込むようなものか数多く見受けられるからです。 セキュリティ・パッチ 要寒ホストで使用している OS やプログラムに対する セキュリティ・パッチは最優先て当てます。 . アカウント管理 本当に必要なアカウントのみ作成し、不要になったアカ ウントはただちに削除しましよう。 さらに、管理者の知らないアカウントカ鮓成されていな に守らなけ川まなりません。そのためには次のような頁 に注意し、厳格なセキュリティ対策を施します。 UNIX MAGAZINE 2000.8 個人の常時接続環境を考える ( 2 ) いかをつねに注意します。ここ数年、ひろく使われてい る攻撃プログラムには、攻撃に成功したときにアカウン トを作成するものがたくさんあるので、かならず定期的 にアカウントデータをチェックしてください。 テュアルホーム・ホスト 2 枚のネットワーク・カードを備え、それぞれを異なる 2 つのネットワークに接続した言算機が、、デュアルホーム・ ホスト (dual-homed host)" です。なかには、 3 枚のネッ トワーク・カードを備えているものもあります。 このような複数のネットワーク・デバイスをもつ算機 は、 IP フォワーディンク機能を用いてルータとして利用 することが多いのですが、この機能を停止して、ファイア ウォールとして使うこともできます。 現在市販されているようなファイアウォール製品がな かったころは、細織内のネットワークとインターネット とのあいだにこのような計算機を設置し、この引算機 - ヒで 発行するアカウントを制限してアクセスを制御していまし た。たとえは、内部からインターネット上の FTP サー バーにアクセスしたいときは、いったんデュアルホーム・ ホストにログインし、そこから ftp コマンドを実行してい たのです。すいぶん面倒に思えますが、私自身の経験から いうと、いまのようにインターネットに頻繁にアクセスす る必要もなかったのでとくに不岡は感しませんでした。 要寒ホストの場合と同様、デュアルホーム・ホストでも 厳格なセキュリティ対策を施します。 バケット・フィルタリング ルータに送られてきたバケットのうち、ある条件を満 たさないバケットを破棄したり、逆にある条件を満たすパ ケットを通過させたりする仕組みを、、バケット・フィルタ リング (packet filtering)" といいます。ここでいう、条 件 " には、次のようなものがあります。 始点 IP アドレス 始点ポート番号 終点 IP アドレス ・終点ポート番号 プロトコル (TCP 、 UDP 、 ・ ICMP の不頁 ICMP など ) 43

9. UNIX MAGAZINE 2000年8月号

連載 /UNIX Communication Notes—O 図 2 ファイアウォールのニ重化とトラフィック監視の インターネット 自社か構築しているネットワークにおいて社員がおこなう 電子メールの交換は基本的に企業活動の一部であり、電子 メールの監視も業務上必要な監査作業の一環と捉える企業 カえつつある。 同時に、社員に対してネットワークの和的利用を禁止す る企業も増えている。このような場合、和的なメールを交 換したければ、社員カ固々に ISP と契約して和的なメー ルポックスを用意することになる。 事実、私の周辺では、仕事上のメールアドレスのはかに、私 的な通信のためのメールアドレスをもつ人も多くなってきた。 ウイルス対策の一環として、組織外の Web サーバー へのアクセスについてもキャッシュ・サー (caching proxy server) を導入し、内部のユーザーに利用を強制 する手法もひろく使われている。これは、外部からダウン ロードされるすべてのファイルをいったんキャッシュ・サー の不正アクセスを検知する。この IDS は、不正アクセス バーに集め、そこでウイルスチェックをおこなって、間 の事実を効率的に本鎹ロするためのオ冓として普及し始めて 題のないファイルだけをユーサーに転送するような機構で いる。 ある。 電子メールの監視とウイルス文 ID S の積極的な利用 一方、後者の、、不注意による情報漏洩の防止 " という目 IDS は、これまで実効性カ礙問視されていたが、山も匠は 標は、業務にネットワークエ竟とコンピュータバ架ぐ匿 一定程度の効力のあるツールとして認められるようになっ し、利用者の不注意による情報の漏洩か現実的な問題とし てきた。 て認識され始めたことに対応している。対象となるのは、 ーイ殳に、 IDS には 2 つの方式がある。 とくに電子メールである。最近は、 Melissa や I LOVE 1 つは、既存の攻撃方法の特徴をまとめたデータベース YOU などの電子メールによってばらまかれるマクロウイ (signature database) を用意しておき、その攻撃パター ルスが登場し、さらに電子メールに添付されたファイルに ンに合致したアクセスを検出するガ去である。これは、現 ウイルスが含まれていることも多い。したがって、電子 在市販されている商用 IDS の多くに実装され、ある程度 メールの監視にはウイルス対策といった側面もある。 の実績を上げている。ネットワーク管理者からみると、既 具イ勺には、外部とのメールの交換を単一のメールサー 存の攻撃手法にもとづくアクセスの監視を自ヒできると ーに集約し、次のような対策をとっている糸励ゞ多い。 いう利点がある。ただし、攻撃の検こ能力はデータベース に言当求されている攻撃バターンの多寡に左右されるため、 ・送受信されるメールがウイルスを含んでいるかどうかを 定期的にデータベースを整備しなけれはならない。 検査づーる。 もう 1 つは、異常状態を検出する去である。点で ・送信されるメールの内容を検査する。 は、この手法にもとづいて実装された IDS はほとんどな これには、すべてのメールを言当求するガ去、間題となる い。これは、何をもって異常とみなすか、逆にいえは正常 キーワードを含むメールを抽出する方法などがある。 な状態の定義カしいことと、一 - 級に通信トラフィックの 電子メールの監視については、これまでフライノヾシー保 糸兤勺な角れこもとづく手法が多く、いまだに実効性カ 護とからめて論しられることが多かった。しかし山も匠は、 問視されているからである。 ファイアウォール 1 DMZ IDS ファイアウォール 2 サービスサー IDS 60 UNIX MAGAZINE 2000.8

10. UNIX MAGAZINE 2000年8月号

いつでも使えるインターネット さないもの、まったく通さないものといったように、 3 種 てなかなか理想どおりにはいきません。 類のルールを設定する場合などがあります。 ・どこが弱点か分からない あるいは、 1 つの関所をうまくすり抜けられたとして 弱点を自分でみつけるには、 OS やアプリケーション も内部の大切な部分までは被害がおよばないように、複数 についての幅広く深い知ゞ必喫です。しかも、セキュ の関所をうまく口して設置することもあります。たとえ リティ重力旬は変化カ暾しいため、毎日のように新しいセ ば、内部ネットワークと外部ネットワークとのあいだにも キュリティ情報を収集しなけれはなりません。さらに、 う 1 つのネットワークを用意し、外部から内部に入り込む すべての UNIX 、すべての Windows や Macintosh 、 には、いったんそのネットワークに侵入しなけれはならな すべてのアプリケーションのセキュリテイ事情に精通 いようにします。このように、侵入に必要なコストを上げ している人は ( たぶん ) いません。ですから、この事項 ておくと、攻撃はより難しくなります。また、いすれカー をクリアするのはたいへん難しいのです。 方の関所の設定を間違ってしまった場合のフェイルセーフ ・たくさんありすぎる にもなります。 毎日、セキュリティに関する新しいニュースがないか このような関所を設けるのは、もちろん、、外部の攻撃か と注意し、パッチをこまめに当てたりして、 1 台の計 ら内部ネットワークを守る " ためです。このように、外部 算機だけに愛を注げば安全が保てるかもしれません。し の攻撃から内部ネットワークを守ることを目的として設置 かし、 2 台、 3 台と増えてくるとそうはいきません。ま された関所やネットワーク全体力ワァイアウォールです。 して、それぞれの計算機に違う OS が入っている場合 には、「えーと、これはバージョン〇△だからこのパッ ファイアウォールの得失 チを当てて・・・・・・」などと考えるだけで混乱してしまい ファイアウォールを導入すると、サイトの内部と外部 ます。 とのあいだの通信を監視し、許可しない通信が入ってきた ・そもそも、なおす手ヾない り、出ていくのを防げるようになります。通信を制御する セキュリティ・ホールが発見されてから、それを修正 機能をうまく使えば、現在知られている多くの攻撃をファ するパッチがリリースされるまで多少の時間がかかりま イアウォールで遮断できます。さらに、重要な情報カ吶部 す。その間、使用を停止するなどの応急処置で対応する から漏洩することも防げます。 ことはできますが、どうしても止められないサービスも ところが、ファイアウォールの導入にはいくらかのコ あるはすです。つまり、その、、危険な期間 " をどのよう ストがかかります。お金はもちろん、運用・管理の手間、 に過ごすかカ墹題になります。 ューサーにとっての商さカ噸なわれるといったこともコ こうしてみると、ネットワークに接続されたすべての計 ストの一にです。 算機のそれぞれに安全対策を施すのは難しそうです。個々 ファイアウォールを設置すると、それまで自由におこ に対処するのか難しけれは、全部ひっくるめて袋のなかに なっていた通信が制限されるようになります。たとえば、 ぎゅぎゅっと詰めて、袋のロをきゅきゅきゅっと縛れは ーにのサービスが使えなくなったり、サービスを利用する いいのではないでしようか。つまり、インターネットなど ために特別な設定を j 助日するといった作業をおこなわなく の外部ネットワークと接続する箇所をまとめ、そこを通る てはなりません。製品によっては、数多くのサービスに対 通信を集中的に監視するわけです。そして、そこに関所の 応していたり、クライアント側の設定を変更しなくても使 ようなものを設けて、、、許可された通信 " は j 面茴を許可し、 える高機能なものもあります。しかし、これらは一殳に高 ツ・午可されない通信 " はそこで遮析すればいいでしようけ 価です。 ファイアウォールを導入するときは、このような得失を このような関所は、内部ネットワークと外部ネットワー 天利にかけ、バランスのとれたものを選びましよう。さら クとのあいだに 1 つだけとはかぎらす、いくつ設けてもか に、導入後に必要に応して変更できるように、柔軟に作る まいません。たとえば、通過 / 遮断のポリシーが異なる関 所を直列 2 段で設置し、 2 カ所とも通すもの、片方しか通 ことも大切です。 口一三 38 UNIX MAGAZINE 2000.8