■レンタルサーバご利用参考資料
サーバご利用の参考にJF Project によるJF (Japanese FAQ)を掲載しています。
Linux JF(Japanese FAQ)Project.
JF は, Linux に関する解説文書・FAQ などを作成・収集・配布するプロジェクトです.
グリーンネット・トップページへ戻る
一覧に戻る
Linux Security HOWTO
Kevin Fenzi, kevin@tummy.com & Dave Wreski,
dave@linuxsecurity.com
v1.1.1, 17 March 2000
The Linux Japanese FAQ Project
31 March 2000
このドキュメントでは, Linux システムの管理者が遭遇するセキュリティ関連
事項についての一般的な解説を行います. このドキュメントでは, セキュリ
ティに対する一般的な考え方と, Linux システムを侵入者からより安全にする
方法の具体例を扱っています. また, セキュリティ関連の情報やプログラム
へのポインタも含まれています. 改善, 建設的な批判, 追加, 訂正は歓迎し
ます. フィードバックを著者両方に送ってください. その際にはサブジェク
トに「Security HOWTO」という文字列を入れてください.
______________________________________________________________________
目次
1. はじめに
1.1 このドキュメントの最新版について
1.2 フィードバック
1.3 免責事項
1.4 著作権表示
1.5 日本語訳について
2. 概要
2.1 なぜセキュリティが必要なのか
2.2 どの程度安全なら安全なのか?
2.3 何を守るのか?
2.4 セキュリティポリシーの作成
2.5 自分のサイトを安全にすることの意義
2.5.1 ホストのセキュリティ
2.5.2 ローカル・ネットワークのセキュリティ
2.5.3 隠蔽によるセキュリティ
2.6 本ドキュメントの構成
3. 物理的なセキュリティ
3.1 コンピュータへの施錠
3.2 BIOS のセキュリティ
3.3 ブートローダのセキュリティ
3.4 xlock と vlock
3.5 物理的な攻撃を受けたことの発見
4. ローカルのセキュリティ
4.1 新規アカウントの作成
4.2 root のセキュリティ
5. ファイルとファイルシステムのセキュリティ
5.1 umask の設定
5.2 ファイルのパーミッション
5.3 システム整合性のチェック
5.4 トロイの木馬
5.5 パスワードのセキュリティと暗号化
5.6 PGP 及び公開鍵暗号
5.7 SSL, S-HTTP, HTTPS, S/MIME
5.8 Linux における IPSEC の実装
5.9 ssh (Secure Shell) と stelnet
5.10 PAM - 交換可能な認証モジュール
5.11 暗号による IP のカプセル化 (Cryptographic IP Encapsulation, CIPE)
5.12 Kerberos
5.13 シャドウパスワード
5.14 "Crack" および "John the Ripper"
5.15 CFS (暗号化ファイルシステム)と TCFS (透過的暗号化ファイルシステム)
5.16 X11, SVGA, ディスプレイに関するセキュリティ
5.16.1 X11
5.16.2 SVGA
5.16.3 GGI (Generic Graphics Interface project)
6. カーネルのセキュリティ
6.1 バージョン 2.0 のカーネルのコンパイルオプション
6.2 バージョン 2.2 のカーネルのコンパイルオプション
6.3 カーネルデバイス
7. ネットワークのセキュリティ
7.1 パケット盗聴
7.2 システムサービスと tcp_wrappers
7.3 DNS 情報の確認
7.4 identd
7.5 SATAN, ISS その他のネットワーク探査プログラム
7.5.1 ポート探査を受けたことの検出
7.6 sendmail, qmail 等の MTA
7.7 サービス妨害攻撃
7.8 NFS (Network File System) のセキュリティ
7.9 NIS (Network Information service) (かつての YP)
7.10 防火壁(ファイアウォール)
7.11 IP Chains - Linux カーネル 2.2.x における防火壁の構築
7.12 仮想プライベートネットワーク(VPN, Virtual Private Network)
8. セキュリティの準備 (ネットワークに接続する前に)
8.1 マシン全体のバックアップの作成
8.2 適切なバックアップ計画の決定
8.3 RPM ファイルデータベースや Debian のファイルデータベースのバックアップ
8.4 システムログの監視
8.5 システム更新パッケージの適用
9. システムに侵入された場合や現在侵入されている場合の対応
9.1 セキュリティが破られている最中
9.2 既にセキュリティが破られてしまった場合
9.2.1 セキュリティの穴を塞ぐ
9.2.2 被害の見積り
9.2.3 バックアップ, バックアップ, バックアップ!
9.2.4 侵入者を突き止める
10. セキュリティ関係の情報源
10.1 FTP サイト
10.2 ウェブサイト
10.3 メーリングリスト
10.4 書籍
11. 用語解説
12. よくある質問
13. まとめ
14. 謝辞
______________________________________________________________________
1. はじめに
このドキュメントでは, Linux のセキュリティに関わる主な話題をいくつか扱
います. 一般的な考え方とネット上で生まれたリソースについて議論します.
他の HOWTO ドキュメントの多くとセキュリティの話題で重なる部分がありま
すが, こういったドキュメントは適当な場所で示します.
このドキュメントは, 最新の問題を扱うものでは「ありません」. 常に新し
い被害がたくさん起きています. このドキュメントは最新の情報をどこで見
れば良いのかを示し, そのような悪用をされないための一般的な方法を示しま
す.
1.1. このドキュメントの最新版について
このドキュメントの最新版は定期的に comp.os.linux.answers に投稿されま
す. また, 以下に示すような, ドキュメント関連の情報を集めているサイトに
も置かれるでしょう:
http://www.linuxdoc.org/
また, Linux のウェブページでも本ドキュメントを見つけることができるで
しょう.
http://metalab.unc.edu/mdw/linux.html
最後に, 本ドキュメントの最新版(各種形式があります)は
http://scrye.com/~kevin/lsh/
や
http://www.linuxsecurity.com/Security-HOWTO
または
http://www.tummy.com/security-howto
といったサイトで入手できます.
訳注: 和訳は http://www.linux.or.jp/JF/JFdocs/Security-HOWTO.html にあ
ります.
1.2. フィードバック
コメント, 誤りの報告, 追加情報, 批判などは以下のメールアドレスに送って
ください:
kevin@tummy.com
および
dave@linuxsecurity.com
注意: フィードバックは両方の著者に送ってください. また, Kevin が使っ
ているスパムフィルタを避けるため, サブジェクトには "Linux",
"security", "HOWTO" のいずれかを必ず入れてください.
訳注: 日本語訳に関する誤りの指摘や, フィードバックはしたいけれど英語は
苦手だという方は JF プロジェクト() までご連絡ください.
1.3. 免責事項
No liability for the contents of this document can be accepted. Use
the concepts, examples and other content at your own risk.
Additionally, this is an early version, possibly with many
inaccuracies or errors.
A number of the examples and descriptions use the RedHat(tm) package
layout and system setup. Your mileage may vary.
As far as we know, only programs that, under certain terms may be used
or evaluated for personal purposes will be described. Most of the
programs will be available, complete with source, under GNU
terms.
訳注: 日本語訳も挙げておきますが, これはあくまで参考です.
本ドキュメントの内容についての責任は一切持ちません. あなた自身の責任
で概念, 実行例, その他の内容を利用してください. また, 本ドキュメント
は書いたばかりのバージョンなので, おそらく不正確な部分や間違いがあると
思われます.
例および説明の多くは Red Hat (tm) パッケージに基づいています. 読者の
使用しているパッケージによって手順が変わることがあるでしょう.
筆者の知っている限りで, 個人目的で使用あるいは評価ができる使用条件のプ
ログラムについて解説します. ほとんどのプログラムは GNU
の条項に従い, 完全なソースコー
ド付きで配布されています.
1.4. 著作権表示
This document is copyrighted (c)1998-2000 Kevin Fenzi and Dave Wreski,
and distributed under the following terms:
o Linux HOWTO documents may be reproduced and distributed in whole or
in part, in any medium, physical or electronic, as long as this
copyright notice is retained on all copies. Commercial
redistribution is allowed and encouraged; however, the authors
would like to be notified of any such distributions.
o All translations, derivative works, or aggregate works
incorporating any Linux HOWTO documents must be covered under this
copyright notice. That is, you may not produce a derivative work
from a HOWTO and impose additional restrictions on its
distribution. Exceptions to these rules may be granted under
certain conditions; please contact the Linux HOWTO coordinator at
the address given below.
o If you have questions, please contact Tim Bynum, the Linux HOWTO
coordinator, at
tjbynum@metalab.unc.edu
訳注: 日本語訳も挙げておきますが, これはあくまで参考です.
Copyright (c)1998-2000 Kevin Fenzi and Dave Wreski
このドキュメントは Kevin Fenzi と Dave Wreski の著作物であり, 以下の条
項に基づいて配布されています:
o Linux HOWTO ドキュメントは, この著作権表示が全ての複製物に残されて
いる限り, 全体あるいは一部分を複製・配布すること, 任意の物理メディ
アや電子メディアで複製・配布することができます. 商業的な再配布は奨
励されていますが, このような配布を行う場合には著者らに連絡すること
を希望します.
o 翻訳, 派生物, Linux HOWTO ドキュメントのいずれかを集めた収集物全て
はこの著作権表示に従わなければなりません. つまり, HOWTO ドキュメン
トから派生したドキュメントを作り, これに制限を追加することはできま
せん. 特定の条件の下では, これらの規則には例外が認められます. 以
下にアドレスを示す Linux HOWTO の世話人と相談してください.
o 疑問点があれば, Linux HOWTO の世話人である Tim Bynum までご連絡くだ
さい. アドレスは以下に示します.
tjbynum@metalab.unc.edu
1.5. 日本語訳について
日本語訳は Linux Japanese FAQ Project が行いました (藤原輝嘉
(日本語訳), 長谷川靖 (校正), 関戸幸一 (校正, 訳
注), 菱川功 (校正, 訳注), 高城正平
(校正) 森本 淳
(v1.1.1 追従) ). 日本語訳に関する権利は
原文に準ずるものとします.
2. 概要
本ドキュメントでは, Linux システムをより安全にするための方法と, よく使
われるソフトウェアについて解説します. 具体的な内容に入る前に, 基本的な
概念について議論し, セキュリティの基礎を押えておくことにしましょう.
2.1. なぜセキュリティが必要なのか
常に変化し続ける, グローバルなデータ通信, 安価なインターネット接続, 速
いペースのソフトウェア開発の世界の中で, セキュリティはより重要になりつ
つあります. グローバルコンピューティングは本質的に危険なので, セキュ
リティは今や基本的な要件です. 例えばデータが A 地点から B 地点までイ
ンターネット上で送られる場合を考えると, データは経路の途中で他の地点を
通るので, 他人がデータを傍受や改竄さえしてしまう可能性があります. 同
じシステム上のユーザでさえ, あなたのデータを悪意を持って意図しないよう
なものに変えてしまうかもしれません. 「クラッカー」として知られる侵入
者に, システムのアクセス権を不正に得られてしまうかもしれません. ク
ラッカーはあなたになりすますために高度な知識を用い, あなたからデータを
盗んだり, あなたが自分自身のデータにアクセスできないようにしてしまいま
す. あなたが「ハッカー」と「クラッカー」の違いが分かっていないようで
あれば, Eric Raymond 氏の書かれた「ハッカーになる方法(How to Become A
Hacker)」をご覧ください. (http://www.netaxs.com/~esr/faqs/hacker-
howto.html で入手できます)
訳注: 「ハッカーになる方法 (How to Become A Hacker)」の日本語訳は
http://www.linux.or.jp/JF/JFdocs/hacker.txt または
http://www.post1.com/home/hiyori13/freeware/hacker.html で入手できま
す.
2.2. どの程度安全なら安全なのか?
最初に, 完全に安全なコンピュータシステムは存在しないことを覚えておいて
ください. できるのは, 何者かがシステムを悪用するのをより困難にするこ
とだけです. 普通の Linux のホームユーザならば, 偶然やってくるクラッ
カーを防ぐのはそれほど大変ではありません. とはいえ, Linux を重要な仕
事に使っている場合(銀行, 通信業者など)には, ずっと多くの作業が必要にな
るでしょう.
考慮に入れるべき別の要素として, セキュリティを高めれば高めるほど, セ
キュリティが邪魔になることが挙げられます. そこで, 目的に対して十分使
いやすくかつ安全なシステムとなるようバランスをとってやらなければなりま
せん. 例えば, あなたのシステムに電話回線で接続してくるユーザ全てに
コールバックモデムを使ってもらい, 彼らの家にコールバックするようにする
ことができます. これにより安全な運用をおこなえますが, ユーザが家にい
ないようなケースではログインが困難になってしまいます. Linux システム
をネットワークやインターネットに繋がない設定も可能ですが, これでは便利
さも損なわれてしまいます.
中〜大規模のサイトならば, サイトがどの程度のセキュリティを必要としてい
て, これをチェックするためどんな監査を行うのかというセキュリティポリ
シーを決めるべきです. 有名なセキュリティポリシーの例は
http://core.ring.gr.jp/pub/doc/rfc/rfc2196.txtです. これは最近改定さ
れており, 会社のセキュリティポリシーを作る際の良い枠組になります.
訳注: 日本語訳が http://www.ipa.go.jp/SECURITY/rfc/RFC2196-00JA.html
にあります.
2.3. 何を守るのか?
システムを安全にしようとする前に, まず, どの程度のレベルの脅威から自身
を守るのか, どの程度のリスクを冒すべきなのか (あるいは冒すべきでないの
か), 結果的にシステムはどの程度脆弱なままにするのかを決めなくてはなり
ません. 何を守るのか, なぜそれを守るのか, それにどんな価値があるのか,
データや他の財産に対しての責任は誰が負うのかを知るために, システムを解
析すべきです.
o リスクとは, 侵入者がシステムへのアクセスに成功する可能性です. 侵入
者はファイルの読み書きをしたり, 害をなすプログラムを実行できるで
しょうか? 重要なデータを消すことができるでしょうか? 重要な仕事の妨
害ができるでしょうか? 忘れてはならないのは, 誰かがあなたのアカウン
トやシステムへのアクセス権を手に入れてしまえば, その人はあなたにな
りきることができてしまうということです.
加えて, 安全でないアカウントがシステム上にひとつあれば, 結果的に
ネットワーク全体が悪用される可能性があります. .rhost ファイルを
使ったログインを許可しているユーザがいたり, tftp のような安全でない
サービスを使っている場合, 侵入者がこれらを利用して「ドアの中に足を
踏み入れる」危険を背負うことになります. いったん侵入者があなたや他
の誰かのシステムのアカウントを手に入れれば, それは他のシステムや他
のアカウントにアクセスするために利用されるかもしれません.
o 脅威は概して, 誰かがネットワークやコンピュータに許可なしにアクセス
しようとすることから生じます. 誰を信用してあなたのシステムにアクセ
スさせるのか, そしてその人がどのような脅威をもたらすのかを考えてお
かなければなりません.
侵入者にはいくつかのタイプがあります. その特徴を知っておくと, シス
テムを安全にするのに役立つでしょう.
o 好奇心 - このタイプの侵入者は基本的に, あなたがどんなシステムや
データを持っているのかを知ることに興味を持っています.
o 悪意 - このタイプの侵入者は, あなたのシステムをダウンさせたり,
ウェブページに落書きをするなど, 復旧に金や時間がかかることをしよ
うとします.
o 名声 - このタイプの侵入者は, 名声や悪名を得るためにシステムに侵
入しようとします. 自分の能力を宣伝するために, 名の通ったシステ
ムに侵入しようとします.
o 競争相手 - このタイプの侵入者は, あなたがシステム上にどんなデー
タを置いているのかに興味を持っています. この侵入者は, あなたが
金銭的あるいはそれ以外の方法で利益をもたらす何かを持っていると
思っているのでしょう.
o 借用 - このタイプの侵入者はあなたのシステムに作業場を作り, その
資源を自分のために使うことに興味を持っています. 彼らは普通は
チャットや IRC サーバ, ポルノアーカイブのサーバ, 果てには DNS
サーバまで実行します.
o 踏台 - このタイプの侵入者は, あなたのシステムを使って他のシステ
ムに侵入することしか考えていません. あなたのシステムの接続状態
が良かったり, 多数の内部システムに継っているゲートウェイならば,
このタイプの侵入者によく狙われるかもしれません.
o システムの脆弱さは, あなたのコンピュータが他のネットワークからどの
程度守られているかということや, 誰かが不正なアクセスをする潜在的な
可能性を示します.
何者かがシステムに侵入した場合, 何が問題となるのでしょうか? 当然な
がら, 家庭から PPP でダイアルアップ接続しているユーザの問題と, 会社
のマシンをインターネットや他の大規模ネットワークに繋いでいる人々の
問題は異なります.
失ったデータを復旧あるいは再び作成するのにどれくらいの時間が必要で
しょうか? ちゃんと初期投資をしておけば, 後で失ったデータを再作成す
るはめになったときにかかる時間は 10 分の 1 に節約できます. バック
アップの計画をチェックし, あとでデータの検証をしていますか?
2.4. セキュリティポリシーの作成
ユーザが容易に理解して守ることができる, 簡単で一般的な方針を決めましょ
う. この方針は大切なデータやユーザのプライバシーを守ってくれるでしょ
う. これに加えて考えるべきことは, 誰がシステムにアクセスできるのか (
自分の友人に自分のアカウントを使わせていいのでしょうか?), 誰がシステム
にソフトウェアをインストールすることができるのか, 誰がどのデータを所有
するのか, それから事故時の復旧やシステムの適切な使いかたについてです.
一般に受け入れられているセキュリティポリシーは次の言葉から始まります.
"許されていないことは禁止されている"
これは, あるサービスをユーザに対して認めていない場合, 許可を出すまでは
ユーザはそのサービスを使うべきではないということです. 正規ユーザアカ
ウントに適用するポリシーを確認しましょう. 「えっと, パーミッションの
問題がわからないので, root で実行しよう」などと言うことは, 明らかなセ
キュリティホールになりますし, 今まで不正使用されたことのないセキュリ
ティホールにさえなるかもしれません.
rfc1244 は独自のネットワークセキュリティポリシーを作るための指針が書か
れたドキュメントです.
rfc1281 はセキュリティポリシーの例を示したドキュメントであり, 各ステッ
プの詳細な説明が付いています.
最後に, ftp://coast.cs.purdue.edu/pub/doc/policy にある COAST ポリシー
アーカイブを調べ, 実生活でのセキュリティポリシーがどのようなものかを見
ると良いでしょう.
2.5. 自分のサイトを安全にすることの意義
本ドキュメントでは, あなたが作ってきた貴重な財産 (ローカルマシン, デー
タ, ユーザ, ネットワーク, あなたの評判) を守るための方法を議論します.
侵入者があなたのユーザのデータを消してしまったら, あなたの評判はどうな
るでしょう? あなたのウェブページに落書きをされてしまったらどうなるで
しょう? また, あなたの会社の次の四半期の計画をばらされてしまったら?
ネットワークのインストールを考えているならば, 1 台のマシンをネットワー
クにつなぐ前に, 考慮すべき要素はたくさんあります.
あなたがダイアルアップ PPP アカウントを使っていたり, ごく小規模なサイ
トを運営している場合であっても, 侵入者があなたのシステムに興味を持たな
いとは限りません. 標的にされるのは, 大規模で有名なサイトだけではあり
ません. 多くの侵入者は規模に関係なくできるだけ多くのサイトを不正使用
しようとします. 加えて, 侵入者はあなたが接続する先のサイトにアクセス
するため, あなたのサイトのセキュリティホールを突くかもしれません.
侵入者は時間を持て余しており, あなたがどんなにシステムを隠蔽しても, 推
測するのではなく, 単に全ての可能性を試してしまいます. 侵入者があなた
のシステムに興味を持つ理由は他にもたくさんありますが, それについては後
で議論します.
2.5.1. ホストのセキュリティ
管理者が最も集中するセキュリティの分野は, おそらく個々のホストに基づく
部分でしょう. これは基本的に, 自分自身のシステムの安全を確保し, 自分
のネットワーク上の他のホストも同様であろうと期待することです. 良いパ
スワードを選び, LAN へのサービスを安全に行い, きちんとログを取り, セ
キュリティに問題があることが知られているプログラムのバージョンアップを
行うのは, ローカルのネットワーク管理者が責任を持って行うべきことです.
これは絶対に必要なことなのですが, ネットワークの規模が数台規模より大き
くなると実施が大変になってしまいます.
2.5.2. ローカル・ネットワークのセキュリティ
ネットワークのセキュリティは, 手元にあるホストのセキュリティと同じく必
要なことです. 何百, 何千, あるいはそれ以上のコンピュータが同じネット
ワークにある場合, そのそれぞれが安全であると信頼することはできません.
許可されたユーザしか自分のネットワーク資源にアクセスできないようにし,
防火壁を構築し, 強力な暗号を使用し, 「たちの悪い」マシンや安全でないマ
シンがネットワーク上に無いようにすることは, 全てネットワーク管理者の任
務です.
本ドキュメントではサイトを安全にするために使われる技術のいくつかについ
て議論し, 守るべきものを侵入者にアクセスさせないようにする方法をいくつ
か示します.
2.5.3. 隠蔽によるセキュリティ
議論すべきセキュリティのタイプの 1 つは「隠蔽によるセキュリティ」です.
これは例えば, セキュリティ的な弱点が知られているサービスを標準でない
ポートに移動させ, 攻撃者に存在がばれないようにして悪用を避けようとする
ものです. このようなものは心配しなくても攻撃者が見つけて悪用してくれ
ます. 隠蔽によるセキュリティは, セキュリティ的には全く無意味です. 単
に小規模なサイトや比較的無名なサイトであるからといって, 侵入者があなた
の持っているものに興味を持たないわけではありません. 次の章で, あなた
が守るものについて議論します.
2.6. 本ドキュメントの構成
本ドキュメントはいくつもの章に分かれています. 各章でセキュリティのお
おまかな話題を押さえます. 最初の話題は ``物理的なセキュリティ''で, マ
シンそのものを物理的にいじられないようにするための方法です. 第 2 の話
題は ``ローカルのセキュリティ''で, ローカルユーザがシステムを改竄する
のを防ぐ方法です. 3 番目の話題は ``ファイルとファイルシステムのセキュ
リティ'' で, ファイルシステムとファイルのパーミッションの設定の方法を
示します. 次の話題は ``パスワードのセキュリティと暗号化''で, マシンや
ネットワークをより安全にするための暗号の使い方を議論します. ``カーネ
ルのセキュリティ''では, マシンをより安全にするために設定あるいは意識す
べきカーネルオプションについて議論します. ``ネットワークのセキュリ
ティ''では, Linux システムを外部ネットワークからの攻撃に対してより安全
にする方法を解説します. ``セキュリティの準備''では, マシンをネット
ワークに繋ぐ前の準備のやりかたについて議論します. 次の``システムに侵
入された/されている場合の対応'' では, システムに侵入されつつあることや
侵入が最近に起こったことに気づいた場合にすべきことを議論します. ``セ
キュリティに関する情報源''では, セキュリティに関する基本的な情報源をい
くつか示し, Q & A の章である``よく聞かれる質問'' ではよく聞かれる質問
いくつかに対する回答を示します. 最後に ``最後に'' にて結びの言葉を述
べます.
本ドキュメントを読んで理解していただきたいポイントは主に 2 つあります.
o システムに注意を払いましょう. /var/log/messages 等のシステムログを
チェックし, システムを見張りましょう.
o 最新バージョンのソフトウェアをインストールし, セキュリティの警告が
出されればソフトウェアをアップグレードして, システムを常に最新の状
態にしましょう. 単純にこうするだけで, システムは劇的に安全になりま
す.
3. 物理的なセキュリティ
最初に考慮すべきセキュリティの層は, コンピュータシステムの物理的なセ
キュリティです. 誰がマシンへ直接触ることができるのか? 触ることができ
るべきなのか? また, 彼らがマシンをいじれないよう守れるのか? あるいは
守るべきなのか?
物理的なセキュリティがどの程度必要になるかは, 大抵の場合, 状況や予算に
よって決まります.
もしあなたがマシンを自分の家で使っているのならば, たぶん注意すべきこと
はあまりないでしょう (子供やうるさい親戚からマシンを守る必要はあるかも
しれませんが). 研究室ならば, かなり注意しなければならないでしょうが,
ユーザはそのマシンで仕事をできる必要があります. そのためには以下の各
章が参考になるでしょう. あなたがオフィスにいるならば, 終業後やあなた
が席を離れているときにマシンを安全にしておく必要があるかもしれません
し, その必要は無いかもしれません. 会社によっては, コンソールを放置す
ることはクビにされる程の規則違反です.
ドアの施錠やケーブル, 鍵付きのキャビネット, ビデオ監視装置等のわかりや
すい物理的な防御方法は全て良い考えなのですが, このドキュメントの守備範
囲ではありません :-)
3.1. コンピュータへの施錠
最近の PC ケースの多くには「鍵」が付いています. 普通はケースの前面に
鍵穴があり, 鍵を施錠か解除の位置にセットできるようになっています.
ケースの鍵によって, 何者かが PC を盗んだり, ケースを開けて直接ハード
ウェアをいじったり盗んだりすることを防ぐことができます. ケースによっ
ては, 他の誰かのフロッピーディスクや他の機器によるマシンの再起動を防ぐ
ことができます.
マザーボードのサポートやケースの作りによっては, ケースの鍵で色々なこと
ができます. 多くの PC ではケースを開けるためにはこれを壊さなくてはな
りません. また, 新しいキーボードやマウスを挿せないものもあります. 詳
しくはマザーボードやケースの説明書を読んでください. 通常, 鍵の質はと
ても低く, 攻撃者は偽造によって簡単に破ることができるのですが, それでも
鍵はとても便利な機能になり得ます.
マシンによっては(特に Sun SPARC や Macintosh), 背面にドングル(dongle)
が付いていて, これを通してケーブルを繋げば, ケーブルを切るかケースを壊
さなければ攻撃者はケーブルを繋ぐことができません. これらに単に南京錠
や連結錠を付けることで, マシンを盗もうとしている人への大きな抑止効果が
得られます.
3.2. BIOS のセキュリティ
BIOS はもっともハードウェアに近いレベルのソフトウェアで, x86 ベースの
ハードウェアの設定及び操作を行います. LILO 等のブートローダは, BIOS
にアクセスして Linux マシンをどうやってブートさせるか指示します.
Linux の他のプラットフォームでも同様のソフトウェアがあります (Mac や
新しい Sun の OpenFirmware, Sun の boot PROM 等). BIOS の設定で, 攻撃
者がマシンを再起動して Linux システムを操作するのを防ぐことができます.
多くの PC BIOS では起動パスワードの設定をすることができます. これはそ
んなに安全ではありません (BIOS はリセットすることができますし, ケース
を開けられるなら取り外すこともできるでしょう) が, 抑止効果は大きいで
しょう (時間かせぎにもなりますし, システムをいじった痕跡も残るからで
す). 同様に S/Linux (SPARC(tm)プロセッサのマシン用の Linux)では,
EEPROM を設定して起動パスワードをかけることができます. これで侵入者を
足止めできるかもしれません.
多くの x86 マシンの BIOS では, この他にも役立つセキュリティ設定を色々
指定できます. BIOS のマニュアルを調べるか, 次回のマシン起動時にチェッ
クしてみましょう. 例えば, フロッピーディスクでの起動を禁止できる BIOS
もありますし, 一部の設定にパスワードをかけることができる BIOS もありま
す.
注意: サーバマシンを管理していて, 起動パスワードを設定している場合, 人
がいないとマシンは起動しません. 停電などの時は, マシンの所に行ってパ
スワードを打ち込んでやる必要があることを覚えておきましょう. ;-(
3.3. ブートローダのセキュリティ
色々なブートローダにも起動パスワードを設定することができます. 例えば
LILO を使っている場合には, password と restricted の設定を調べてみま
しょう. password は起動時にパスワードを要求するようにします.
restricted の場合は, LILO プロンプトに対してオプション (single等) を
指定した場合だけ起動パスワードを要求するようになります.
lilo.conf のオンラインマニュアルより:
password=password
起動イメージごとのオプション `password=...' (下記参照) を
すべてのイメージに適用します.
restricted
起動イメージごとのオプション `restricted' (下記参照) を
すべてのイメージに適用します.
password=password
イメージをパスワードで保護します.
restricted
起動イメージにコマンドラインでパラメータを指定したとき
(例: single) だけパスワードを要求します.
パスワードを設定したら, これを忘れてはならないことに注意してください.
:-) また, 気合いの入った攻撃者に対しては, このようなパスワードは単なる
足止め程度にしかならないことも忘れてはいけません. この方法では誰かが
フロッピーディスクから起動してルートパーティションをマウントすることを
防ぐことはできません. ブートローダと組み合わせたセキュリティ手法を使
う場合には, コンピュータの BIOS でフロッピーディスクからの起動を無効に
することができますし, BIOS をパスワード保護することもできます.
LILO 以外のブートローダ(grub, silo, milo, linload 等)のセキュリティ関
連情報をご存知ならば, ぜひお知らせください.
注意: サーバマシンにパスワードを設定した場合, 人がいないとマシンは起動
しなくなります. 停電などの場合でも, マシンのところに行ってパスワード
を打ち込まなければならないことは覚えておきましょう. ;-(
3.4. xlock と vlock
頻繁にマシンから離れて出歩くならば, コンソールに「鍵」を掛け, 誰もマシ
ンをいじったり, 作業の様子を覗けないようにしておくと良いでしょう. こ
のようなプログラムとして, xlock と vlock の 2 つを紹介します.
xlock は X のディスプレイをロックします. X をサポートしている Linux
ディストリビューションならば, 普通 xlock はインストールされているで
しょう. オプションについてはオンラインマニュアルを参照してほしいので
すが, 大まかに説明すると, ロックしたいコンソール上の xterm から xlock
を起動すると, ディスプレイがロックされ, パスワードを入力しないと解除で
きなくなります.
vlock は Linux の仮想コンソールの一部あるいは全てをロックするための簡
単なプログラムです. 現在作業中のコンソールを 1 つだけロックすることも
できますし, 全てをロックすることもできます. 仮想コンソールを 1 つロッ
クしている場合, 他の人はコンソールを使うことができます. ですが, ロック
されている仮想端末はロックが解除されるまでは使うことができません.
vlock は Red Hat Linux には入っていますが, 入っていないディストリ
ビューションもあるかもしれません.
当然ながら, コンソールをロックすれば何者かにあなたの作業をいじられるの
を防ぐことはできますが, マシンを再起動されたりしてやりかけの作業が壊さ
れることは防げません. また, ネットワーク上の他のマシンからコンソール
をロックしたマシンにアクセスして問題を起こすことを防ぐこともできませ
ん.
さらに重要な点としては, 誰かが X ウィンドウシステムから完全に抜けて通
常の仮想コンソールのログインプロンプトに行くことや, X11 を起動した仮想
コンソールに行き X をサスペンドさせ, ユーザの権限を奪ってしまうことを
防げない点が挙げられます. ですから, 完全に xdm の制御下において使うこ
とだけを考えるのがよいでしょう.
3.5. 物理的な攻撃を受けたことの発見
まずは, マシンをいつ再起動したのか必ず記録するようにしましょう. Linux
は頑健で安定な OS ですから, あなたがマシンを再起動するのは OS のアップ
グレードやハードウェアの交換等の時だけでしょう. あなたが知らないうち
にマシンが再起動されていたら, これは侵入者に悪用されたことの印かもしれ
ません. 侵入者がマシンに物理的な攻撃をする手段の多くは, マシンを再起
動したり, 電源を切ったりしなければならないからです.
ケースやコンピュータ周辺をいじられた兆候が無いかどうかチェックしましょ
う. 侵入者は普通ログから痕跡を消しますが, これらを全てチェックし, 矛
盾が無いか調べるのも良いでしょう.
ログのデータを安全な場所 (きちんと守られたネットワーク内部の専用のログ
サーバ等) に置くのも良い考えです. あるマシンが悪用された場合には, ログ
データはほとんど役に立たなくなるからです. というのも, 侵入者は大抵ロ
グも書き換えてしまうからです.
syslog デーモンを設定して, ログを自動的に中央のログサーバに送るように
することもできますが, これは通常は暗号化されずに送られます. したがっ
て, 侵入者は転送されているデータを見ることができます. これにより, 公に
するつもりのないネットワーク関係の情報が洩れてしまうかもしれません.
データを送る際に暗号化することができる syslog デーモンもあります.
syslog のメッセージの偽造は容易である点にも注意してください. これを悪
用するためのプログラムも出回っています. syslog はローカルホストから出
されたと言っているネットワーク経由のログエントリであっても, 本当の送信
元を示すことなく受け付けてしまいます.
ログを調べる際には以下の点に注意します.
o ログが短かったり, 不完全ではないか
o ログに記録されている時間はおかしくないか
o ログのパーミッションや所有者はおかしくないか
o システムそのものや, サービスの再起動は記録されていないか
o 無くなっているログはないか
o おかしな場所から su やログインが行われていないか
システムログデータについては, この HOWTO 内の ``後の章''で説明します.
4. ローカルのセキュリティ
次にローカルユーザの攻撃に対するシステムのセキュリティについて考えま
す. そうです, ローカルのユーザに対してです.
ローカルユーザのアカウントの獲得は, 攻撃者が root のアカウントを破ろう
とする際に最初に考えることの一つです. ローカルに対するセキュリティが
甘ければ, 様々なバグやローカル向けのサービスのまずい設定を利用して, 一
般ユーザの権限から root ユーザの権限へ「アップグレード」することができ
るのです. ローカルに対するセキュリティが強固であれば, 侵入者が越えな
ければならないハードルはまだ残ることになります.
ローカルユーザは, たとえ身元を詐称していなくてもシステムに被害を与える
ことができます. 知らない人, 連絡先のわからない人にアカウントを与える
のは, 非常に危険なことです.
4.1. 新規アカウントの作成
アカウントを発行する際は, そのユーザが行う必要のある作業に対し, 必要最
小限のアカウントを与えていることに留意すべきです. 息子 (10 才) にアカ
ウントを与えるのならば, ワープロやお絵描きプログラムにはアクセスできる
けれど, 自分のものでないファイルを削除できないユーザにすべきでしょう.
他人に Linux マシンに対して合理的にアクセスをしてもらうための, 便利な
経験則があります.
o 必要最小限の権限しか与えないようにします
o いつ, どこからログインしたか, あるいはどこからログインすべきかに注
意を払います
o 使われていないアカウントは削除したかどうか確認します
o 全てのコンピュータとネットワークで同じユーザ ID を使うとよいでしょ
う. これにより, アカウントの管理, ログデータの解析が容易になりま
す.
o グループユーザ ID の作成は絶対に禁止すべきです. ユーザアカウントで
は責任の所在が明らかですが, グループアカウントではそうではないから
です.
セキュリティを破るときに使われるローカルユーザのアカウントの多くは, 何
ヵ月あるいは何年も使われていないものです. 誰も使っていないために, 理想
的な攻撃の道具になってしまうのです.
4.2. root のセキュリティ
あなたのマシンで最も欲しがられるアカウントは, root (ユーパーユーザ) の
アカウントです. このアカウントはマシン全体に対する権限を持ち, ネット
ワーク上の他のマシンに対する権限を持つこともあります. root のアカウン
トはできるだけ短時間の, 特定の作業だけで使用し, それ以外の時は一般ユー
ザとしてマシンを使用すべきです. root ユーザでログインしているとちょっ
としたミスでも問題を起こしかねません. root 権限を持っている時間は短け
れば短いほど安全です.
root 権限でマシンを壊してしまわないための仕掛けもいくつかあります.
o 複雑なコマンドを実行するとき, 特に globbing を使う(* や ? などのワ
イルドカードを使用する)場合は, 失敗しても悲惨な結果にならない方法を
最初にとりましょう. 例えば rm foo*.bak を実行したい場合は, まず
"ls foo*.bak" を実行し, 考えているファイルだけが消されるようになっ
ているか確認するのです. 危険なコマンドの代わりに echo が使えること
もあります.
o ユーザに対して rm コマンドのエイリアスを設定しておき, ファイルの削
除の際に確認を行うようにします.
o 特定の作業 1 つを行うためだけに root になりましょう. 自分が, どう
やって作業しようか考えているような状態だとしたら, root でやらなけれ
ばならないことがはっきりするまでは, 一般ユーザに戻りましょう.
o root ユーザのコマンドパスはとても重要です. コマンドパス (つまり
PATH 環境変数) はシェルがプログラムを探すディレクトリを指定します.
root ユーザ用のコマンドパスはできる限り制限すべきですし, 絶対に '.'
(これは「カレントディレクトリ」を意味します) を PATH の指定に入れて
はいけません. さらに, 書き込み可能なディレクトリを検索パスに入れて
はいけません. というのも, そうなっていると攻撃者が検索パス上のファ
イルを書き換えたり置き換えたりでき, あなたがそのコマンドを次に使っ
たときに root 権限で動作させることができるからです.
o root で rlogin/rsh/rexec コマンド群 (いわゆる r-ユーティリティ) を
使ってはいけません. これらのコマンドは色々な攻撃の対象となるので,
root のときに実行するのは実に危険です. root ユーザ用の .rhosts
ファイルは決して作ってはいけません.
o /etc/securetty には root がログインできる端末のリストが書かれていま
す. (Red Hat Linux の)デフォルトでは, これにはローカルの仮想端末
(vty) だけが設定されています. このファイルにそれ以外の端末を追加す
るときには, 細心の注意を払ってください. 必要がある時でも一般ユーザ
として (できれば ``ssh'' 等の暗号化チャネル経由で) リモートログイン
し, それから su することができるはずなので, 直接 root としてログイ
ンできる必要はありません.
o root での作業は, 必ずゆっくり, 慎重に行いましょう. 作業の結果は大
きな影響をもたらすかもしれません. コマンドを打ち込む前に, まず考え
ましょう!
どうしても誰か (できれば非常に信頼している人) に root 権限を与える必要
がある場合にも, これを補助するツールがあります. sudo を使えば, ユーザ
のパスワードを使って, 制限されたコマンド群を root の権限で使用させるこ
とができます. これにより, 例えば Linux マシンのリムーバブルメディアを
ユーザにイジェクトやマウントをさせるけれど, それ以外の root 権限は与え
ないようにすることができます. sudo は成功・失敗を含めて全ての sudo の
試みをログに取ることができるので, 誰が何のためにどのコマンドを使ったか
調査することができます. このため, sudo は多くのユーザが root 権限を持
つような環境でもうまく利用することができます. なぜなら, システムに対
して行われた変更を調べやすくしてくれるからです.
sudo を使って特定のユーザに特定目的のための特定の権限を与えることがで
きますが, sudo には欠点がいくつかあります. sudo は, サーバの再起動や
ユーザの新規追加など, 限られた作業の組に対してだけ使うべきです. シェ
ルエスケープができる任意のプログラムは, これを sudo を通して使ったユー
ザに root 権限を与えてしまいます. 例えば, 大部分のエディタがこれに該
当します. また, /bin/cat のように無害なプログラムであってもファイルの
上書きに使うことができるので, これを使って root 権限が破られることもあ
り得ます. sudo は権限を使わせるための手段と考えるべきであり, root
ユーザをより安全にするために置き換えるものと期待してはいけません.
5. ファイルとファイルシステムのセキュリティ
システムをネットワークに繋ぐ前に少し準備と計画を行うだけで, システムと
その中のデータを守るのに役立つでしょう.
o ユーザのホームディレクトリに SUID/SGID したプログラムを置いて実行さ
せる理由は全くありません. root 以外のユーザが書き込み可能なパー
ティションに対しては /etc/fstab で nosuid オプションを使いましょう.
また, ユーザのホームパーティションや /var では nodev や noexec を使
おうと考えるかもしれません. これらのオプションはプログラムの実行
や, キャラクタデバイス・ブロックデバイスの作成を禁止します. これら
はいずれにせよ必要無いはずです.
o NFS を用いてファイルシステムをエクスポートしている場合は必ず, アク
セスをできる限り厳しく設定してください. つまり /etc/exports ででき
る限り厳しいアクセス制限を行ってください. これはワイルドカードを使
わないこと, root での書き込みアクセスを許可しないこと, できる限り読
み取り専用でエクスポートするということです.
o ファイル作成の umask をできる限り厳しく設定してください. ``umask
の設定'' をご覧ください.
o NFS 等のネットワークファイルシステムを用いてファイルシステムをマウ
ントしているならば, 必ず /etc/exports で適切な制限を付けた設定にし
てください. 普通は `nodev', `nosuid', それから多分 `noexec' が望ま
しいでしょう.
o デフォルトの unlimited を認めるのではなく, ファイルシステムに制限値
を設定しましょう. リソース制限を行う PAM モジュールと
/etc/pam.d/limits.conf を使って, ユーザ別に制御することができます.
例えば, グループ users の制限は以下のようになります:
@users hard core 0
@users hard nproc 50
@users hard rss 5000
この設定は, コアファイルの作成を禁止し, プロセスの数を 50 に制限し, メ
モリの使用量をユーザ 1 人あたり 5MB に制限するものです.
o /var/log/wtmp, /var/run/utmp ファイルには, システムの全てのユーザの
ログイン記録が記録されています. このファイルは絶対いじられないよう
にしなくてはなりません. というのも, このファイルを使ってユーザ (あ
るいは侵入者である可能性がある人) がいつ, どこからシステムに入った
のかを知ることができるからです. このファイルのパーミッションは 644
にすべきです. この設定は通常のシステム操作に影響を与えません.
o immutable ビットを使うと, 守らなくてはならないファイルを事故で消し
たり上書きすることを防ぐことができます. このビットを使って, 誰かが
このファイルに対するシンボリックリンクを作成するのを防ぐこともでき
ます (こういったシンボリックリンクは今まで /etc/passwd や
/etc/shadow の削除を含む攻撃の手段となってきました). immutable
ビットの情報については, オンラインマニュアルの chattr(1) を参照して
ください.
o SUID, SGID されたファイルがシステムにあるとセキュリティにとっては潜
在的に危険なので, これらのファイルはきちんと監視していなければなり
ません. このようなプログラムは実行したユーザに特別な権限を与えるの
で, 安全でないプログラムが絶対にインストールされないようにする必要
があります. クラッカーが好んで使うトリックとして, root に SUID さ
れたプログラムをいじり, 元のセキュリティホールが塞がれても次回に使
える裏口として, SUID されたプログラムを残しておく方法があります.
システム上の SUID/SGID されたプログラムを全て見つけ, それらがどう
なっているかを監視します. 侵入者の可能性を示すこれらのファイルの変
化に注意してください. システム上の SUID/SGID されたプログラムを全
て見つけるには以下のコマンドを使います:
root# find / -type f \( -perm -04000 -o -perm -02000 \)
Debian ディストリビューションは, SUID されたファイルが存在するかどうか
を調べるジョブを毎晩実行します. そして, これを昨晩の実行結果と比較し
ます. このログは /var/log/setuid* で参照できます.
怪しいプログラムは chmod を使って SUID や SGID のパーミッションを取り
除くことができます. どうしても必要だと思った時にはパーミッションを戻
すこともできます.
o 全てのユーザーが書き込み可能なファイル(特にシステムファイル)は, ク
ラッカーがあなたのシステムにアクセスして, 修正することによりセキュ
リティホールとなりえます. さらに, 誰もが書き込めるディレクトリとい
うものも, クラッカーが自由にファイルの追加・削除ができるため危険で
す. システム上にあるこのようなファイルの位置を特定するには, 以下の
コマンドを使います:
root# find / -perm -2 ! -type l -ls
それから, どうしてこれらのファイルが書き込み可能になったのかを確かめて
ください. 普通に操作している場合でも, /dev のいくつかのファイルやシン
ボリックリンク等を含めて, 誰でも書き込めるファイルがいくつかあります.
したがって, ! -type l を用いて, 先の find コマンドの結果からこれらを取
り除いてください.
o
所有者のいないファイルも侵入者がシステムにアクセスした可能性を示し
ます. 所有者がいないファイルや, どのグループにも属していないファイ
ルは, 以下のコマンドで見つけることができます:
root# find / -nouser -o -nogroup -print
o .rhosts ファイルを見つけることも, システム管理者の日常業務の一部で
す. このファイルをシステムに設置するのは許可すべきでないからです.
クラッカーがネットワーク全体にアクセスする可能性を得るためには, 安
全でないアカウントが 1 つだけあれば良いということを忘れないでくださ
い. システム上の全ての .rhosts ファイルは以下のコマンドで見つける
ことができます:
root# find /home -name .rhosts -print
o
最後になりますが, システムファイルのパーミッションの変更は, しよう
としていることを必ず理解してからにしてください. 何かを動かすための
楽な方法だからといって, ファイルのパーミッションを変えてはいけませ
ん. パーミッションを変える前には, ファイルのパーミッションがそう
なっている理由を必ず理解してください.
5.1. umask の設定
umask コマンドを使って, システムのデフォルトのファイル生成モードを決め
ることができます. umask 値は設定したいファイルモードの 8 進数での補数
になります. パーミッションに関する指定を何も行わずにファイルを生成す
ると, パーミッションを与えるべきでない何者かに対して読み書きのパーミッ
ションを意図せずに与えてしまうかもしれません. 通常は umask 値の設定は
022, 027, 077 です. 077 は最も厳しい設定です. 通常は umask 値は
/etc/profile で設定され, システムの全ユーザに適用されます. ファイル生
成マスクは, 777 から希望の値を引き算することによって計算することができ
ます. 言い換えると, umask 値が 777 であれば, 新しく生成されるファイル
は誰に対しても読み書きと実行のパーミッションを持ちません. マスクが 666
ならば, 新しく生成されるファイルのモードは 111 となります. 例えば, 以
下のような行を設定できます:
# Set the user's default umask
umask 033
ただし, root ユーザの umask 値は必ず 077 にしてください. こうしておく
と, chmod を使って明示的に変えない限り, 他のユーザの読み書きと実行は無
効になります. umask 値に 033 を設定した場合には, 新しく生成されるディ
レクトリのパーミッションは 744 になります. この値は 777 から 033 を引
いて得られたものです. umask 値 033 を用いて新しく生成されるファイルは
パーミッション 644 を持ちます.
Red Hat を使っており, Red Hat のユーザ ID, グループ ID の作成方法
(User Private Groups) に従う場合, umask には 002 だけ設定していれば十
分です. その理由は, デフォルトの設定で 1 グループに 1 ユーザしかいな
いためです.
5.2. ファイルのパーミッション
システム管理を行うべきでないユーザやグループの権限ではシステムファイル
を変更できないようにしておくのは重要なことです.
UNIX は ファイルとディレクトリのアクセス制御を 3 つの特性 (所有者, グ
ループ, 全員)に分離しています. 常に一人だけを指す所有者, 任意の人数を
指せるグループ, そしてそれ以外の全員です.
以下で UNIX のパーミッションを簡単に説明します:
所有権 (ownership) - あるノードやその親ノードのパーミッション設定をど
のユーザ, グループが行うことができるのかを示します.
パーミッション(permissions) - ファイルに対して行うことができるアクセス
の種類を決めるビット列. 組合せが同じでも, ディレクトリのパーミッショ
ンはファイルのパーミッションとは意味が異なることがあります.
読み出し(read):
o ファイルの内容を見ることができる
o ディレクトリの内容を見ることができる
書き込み(write):
o ファイルの内容の追加, 修正ができる
o ディレクトリのファイルの消去やファイル移動ができる
実行(execute):
o バイナリのプログラムやシェルスクリプトを実行できる
o 読み出しのパーミッションと組み合わせて, ディレクトリ内を調べること
ができる
テキスト保存属性: (ディレクトリ用)
ディレクトリに適用する場合, 「sticky ビット」の意味はファイルに
適用する場合と異なります. sticky ビットがディレクトリに設定され
ている場合に削除できるファイルは, そのディレクトリへの書き込み権
限があったとしても, 自分が所有しているファイルか明示的に書き込み
許可が与えられているファイルだけです. このビットは /tmp のよう
なディレクトリのために用意されたものです. このようなディレクト
リは誰でも書き込みはできますが, 誰でも自由にファイル消去を認める
のは望ましくありません. ディレクトリを詳細表示すると, sticky
ビットは t で表されます.
SUID 属性: (ファイル用)
これはファイルへの SUID パーミッションを示します. ユーザ ID 設
定アクセスモードが所有者のパーミッションで設定されており, かつそ
のファイルが実行可能であれば, これを実行したプロセスは, プロセス
を起動したユーザではなく, ファイルを所有しているユーザに基づいて
システムのリソースにアクセスできます. これは各種 'buffer
overflow' 攻撃の原因となります.
SGID 属性: (ファイル用)
グループのパーミッションで設定されていれば, このビットはファイル
の「グループ ID 設定」状態を制御します. これは SUID と同じよう
に動作しますが, ユーザではなくグループが影響を受ける点が異なりま
す. このビットに効果を持たせるためには, やはりファイルは実行可
能でなければいけません.
SGID 属性: (ディレクトリ用)
(chmod g+s directory を行って) ディレクトリに SGID ビットを設定
した場合, このディレクトリに作られたファイルはディレクトリのグ
ループに設定されたグループを持ちます.
あなた - ファイルの所有者
グループ - あなたが所属するグループ
全員 - 所有者でもグループのメンバでもない, システム上の全員
ファイルの例:
-rw-r--r-- 1 kevin users 114 Aug 28 1997 .zlogin
1番目のビット - ディレクトリか? (no)
2番目のビット - 所有者が読み出せるか? (yes, ユーザ kevin が可能)
3番目のビット - 所有者が書き込めるか? (yes, ユーザ kevin が可能)
4番目のビット - 所有者が実行できるか? (no)
5番目のビット - グループは読み出せるか (yes, users グループが可能)
6番目のビット - グループは書き込めるか? (no)
7番目のビット - グループは実行できるか? (no)
8番目のビット - 誰でも読み出せるか? (yes, 誰でも可能)
9番目のビット - 誰でも書き込めるか? (no)
10番目のビット- 誰でも実行できるか? (no)
以下の行は, アクセス権の説明に必要な最小限のパーミッションを集めた例で
す. 実際には, ここに示した以上のパーミッションを与えることが必要かも
しれませんが, これらのファイルに関する最小限のパーミッションが意味する
ところは次のようなものです:
-r-------- 所有者に読み込みアクセスを許可します
--w------- 所有者にファイルの修正と削除を許可します
(そのファイルが入っているディレクトリの書き込みパーミッショ
ンを持つユーザは, ファイルの上書きや削除を行うことができます)
---x------ このプログラムの実行を許可します. シェルスクリプトの場合は
これだけでは足りず, さらに読み込みパーミッションが必要です.
---s------ 「実効ユーザ ID = 所有者」として実行を行います
-------s-- 「実効グループ ID = グループ」として実行を行います
-rw------T 「最終更新時刻」を更新しません. 通常はスワップファイルだけ
に使います.
---t------ 無意味です(以前 sticky ビットだったものです).
ディレクトリの例:
drwxr-xr-x 3 kevin users 512 Sep 19 13:47 .public_html/
1番目のビット - ディレクトリか? (yes, たくさんのファイルがある)
2番目のビット - 所有者は読み出せるか? (yes, ユーザ kevin が可能)
3番目のビット - 所有者は書き込めるか? (yes, ユーザ kevin が可能)
4番目のビット - 所有者は実行できるか? (yes, ユーザ kevin が可能)
5番目のビット - グループは読み出せるか?(yes, users グループが可能)
6番目のビット - グループは書き込めるか?(no)
7番目のビット - グループは実行できるか?(yes, users グループが可能)
8番目のビット - 誰でも読み出しできるか?(yes, 誰でも可能)
9番目のビット - 誰でも書き込めるか? (no)
10番目のビット- 誰でも実行できるか? (yes, 誰でも可能)
以下の行は, アクセス権の説明に必要な最小限のパーミッションを集めた例で
す. 示したもの以外にも多くのパーミッションが必要だと思うかもしれませ
んが, これはこれらのファイルに対する最小限のパーミッションで記述できる
はずです:
dr-------- 内容は表示できますが, ファイルの属性は読み出せません
d--x------ ディレクトリに入れ, 実行時に絶対パスの一部として使うことが
できます.
dr-x------ 所有者がファイル属性を読み出すことができます
d-wx------ カレントディレクトリでなくても, ファイルの生成/削除が行え
ます
d------x-t 書き込み許可があっても他人はファイルを消すことを禁止します.
/tmp で使われます.
d---s--s-- 無意味です.
システム設定ファイル (普通は /etc にあります) は通常, モードが 640
(-rw-r-----) で, root が所有者です. これはサイトにおけるセキュリティ
の要求にしたがって調整することができます. システムファイルはグループ
のメンバーないしは万人に書き込めるようにしていてはいけません. 一部の
ファイル (/etc/shadow 等) は root にしか読めない状態でなければなりませ
んし, 少なくとも /etc 内にあるディレクトリはその他のユーザがアクセスで
きてはいけません.
SUID されたシェルスクリプト
SUID されたシェルスクリプトはセキュリティに重大な危険を及ぼすの
で, カーネルはこれを無視します. そのシェルスクリプトがどれだけ安
全だと思っていても, クラッカーに root のシェルを奪われてしまう可
能性があります.
5.3. システム整合性のチェック
ローカルからの (そしてネットワークからの) システムに対する攻撃を発見す
る別の良い方法は, Tripwire, Aide, Osiris のような, システムがいじられ
ていないかどうかをチェックするプログラムを実行することです. これらは
重要なバイナリや設定ファイル全てのチェックサムを取り, 参照値として正し
いことが分かっている以前の値のデータベースと比較します. したがって,
これらのファイルの変更は全て知ることができます.
この手のプログラムをフロッピーディスクにインストールし, このフロッピー
を物理的に書き込み禁止にしておくとよいでしょう. こうしておけば, 侵入
者にはシステム整合性チェックプログラムやデータベースを改竄することが不
可能になります. いったんこの手のものを設定したら, これを通常のセキュ
リティ管理作業の一部として実行し, 何か変更がなされていないかチェックす
るとよいでしょう.
毎晩 フロッピーディスク上のチェックプログラムを実行し, 朝にその結果を
メールで送るように crontab を設定することもできます. 設定は以下のよう
になります.
# set mailto
MAILTO=kevin
# run Tripwire
15 05 * * * root /usr/local/adm/tcheck/tripwire
実行結果は午前 5 時 15 分にメールで送られます.
整合性チェックプログラムは, いざとなってから気づくより前に侵入者を発見
する天の配剤になり得ます. 一般的なシステムでは多くのファイルが変更さ
れますので, クラッカーの動きや, 自分自身が行ったことに注意していなくて
はなりませんから.
Tripwire のオープンソースなバージョンは
http://www.tripwiresecurity.comにあります. 無料です. マニュアルとサ
ポートは有料で入手することができます.
Aide は http://www.cs.tut.fi/~rammer/aide.html にあります.
Osiris は http://www.shmoo.com/osiris/ からどうぞ.
5.4. トロイの木馬
「トロイの木馬 (Trojan Horse)」はホメーロスのイーリアスに書かれている
有名な計略に由来する名前です. 基本的な考え方は, 便利そうなプログラムや
バイナリを用意しておき, これを他人にダウンロードさせて root ユーザとし
て実行させるというものです. これによって, 相手が気づかないうちにシス
テムを悪用することができます. 手に入れたバイナリが仕事をしている (と
ても役立っているかもしれません) と思っている間に, このバイナリが同時に
セキュリティも破ってしまうのです.
したがって, マシンにプログラムをインストールする時には注意が必要です.
Red Hat は MD5 チェックサムと PGP 署名を施した RPM ファイルを提供し,
ユーザが本物のパッケージを入手しているのかどうかをチェックできるように
しています. 他のディストリビューションにも同様の仕組みがあります. 素
性が知れず, ソースも提供されていないバイナリを root 権限で実行してはい
けません! 誰もが調査できるようなソースコードを公開する攻撃者はほとん
どいません.
手間はかかるかもしれませんが, プログラムのソースコードはその正式の公開
サイトから入手するべきです. プログラムを root 権限で実行するならば,
あなたか, あなたが信頼している人がソースコードを見て, 検査すべきです.
5.5. パスワードのセキュリティと暗号化
現在用いられているセキュリティ機能のうち最も重要なもののひとつがパス
ワードです. あなたとあなたのマシンのユーザの両方が, パスワードを安全で
推測しにくいものにしておくことが大事です. 最近の Linux ディストリ
ビューションのほとんどには, 簡単に推測できるパスワードは設定できないよ
うになっている passwd プログラムが入っています. passwd プログラムが最
新のもので, このような機能を持っているかどうか確かめておきましょう.
暗号化についての突っ込んだ議論は本書の範囲を越えてしまいますが, 入門程
度ならば良いでしょう. 暗号化は大変便利ですし, たぶん今日では必須とさえ
言えるでしょう. 非常に多くの種類のデータ暗号化の方法がありますが, そ
れぞれが特徴を持っています.
ほとんどの UNIX(Linux も例外ではありません)は, DES (Data Encryption
Standard) と呼ばれる片方向の暗号化アルゴリズムを主に使ってパスワードを
暗号化しています. 暗号化されたパスワードは(普通)/etc/passwd か (少し
一般的でないですが) /etc/shadow に保存されます. ユーザがログインしよ
うとすると, 入力したパスワードは再び暗号化され, パスワードを格納してい
るファイルの該当項目と比較されます. これらが一致すればパスワードは同
じはずなので, ログインが許可されます. DES は双方向の暗号化アルゴリズ
ム (正しいキーを与えれば, 暗号化も復号化もできる)なのですが, ほとんど
の UNIX が使っているのは DES の一種で片方向のアルゴリズムです. つま
り, /etc/passwd (または /etc/shadow) の内容からパスワードを得るために
暗号を解読することは不可能なはずです.
パスワードが十分にランダムでない場合, "Crack" や "John the Ripper"
(``'' 章を参照)のような力任せの攻撃でもパスワードを推測できます. PAM
モジュール (後述) を利用すれば, 別の暗号化ルーチン (MD5 など) を使用で
きます. Crack にも良い使い方があります. パスワードデータベースに対し
て定期的に Crack を実行し, 安全でないパスワードを見つけるのです. そし
て問題のあるユーザと話をして, パスワードを変えるように指導します.
良いパスワードの決め方に関する情報については
http://consult.cern.ch/writeup/security/security_3.html を参照してくだ
さい.
5.6. PGP 及び公開鍵暗号
PGP 等に使われている公開鍵暗号は, ある鍵を暗号化に使い, 別の鍵を復号化
に使う暗号です. 従来の暗号は, 暗号化と復号化に同じ鍵を使っていました.
この鍵は通信の両側が知っていなければならず, 何らかの安全な方法で相手に
送らなければなりませんでした.
暗号に使った鍵を安全に転送する必要性を無くすため, 公開鍵暗号では 2 つ
の別々の鍵(公開鍵と秘密鍵)を用います. 各自が持っている公開鍵は誰でも
使うことができ, 暗号化はこれを使って行います. 一方, 各自は自分の秘密
鍵を持っており, 正しい公開鍵を使って暗号化されたメッセージはこれを使っ
て復号化します.
公開鍵を使う暗号にも秘密鍵を使う暗号にも利点はあります. これらの違い
については, このセクションの最後に示す the RSA Cryptography FAQ
に説明があります.
PGP (Pretty Good Privacy) は Linux でちゃんとサポートされています.
バージョン 2.62 と 5.0 の動作が確認されています. PGP への入門や使い方
については, PGP FAQ を見ると良いでしょう.
http://www.pgp.com/service/export/faq/55faq.cgi
必ず, あなたの国で利用できるバージョンを使ってください. これはアメリ
カ合衆国政府による輸出制限のためであり, 強力な暗号を電子的に国外へ転送
することが禁止されているからです.
現在は輸出の管理は EAR(Export Administration Regulations)が行っていま
す. もはや ITAR (訳注: International Traffic in Arms Regulations の略
称) では管理されていません.
Linux での PGP の設定に関するステップバイステップのガイドも
http://mercury.chem.pitt.edu/~angel/LinuxFocus/English/November1997/article7.html
にあります. これは PGP の国際バージョン用に書かれたものですが, アメリ
カ合衆国バージョンにも簡単に適用できます. 最新バージョンの Linux の一
部ではパッチが必要になることがあります. このパッチは
ftp://metalab.unc.edu/pub/Linux/apps/crypto で入手できます.
PGP をオープンソースでフリーに実装し直そうとしているプロジェクトがあり
ます. GnuPG は PGP に置き換えることができる, 既に完成しているフリーな
プログラムです. GnuPG は IDEA も RSA も使っていないので, 制限無しに使
用することができます. GnuPG は OpenPGP にほぼ準拠しています. 詳しく
は GNU Privacy Guard の WWW ページ (http://www.gnupg.org/) をご覧くだ
さい.
訳注 (略語の意味):
o IDEA: International Data Encryption Algorithm の略. 128 ビットの秘
密鍵を用いた暗号アルゴリズムで, スイスの Ascom-Tech 社が特許権を
持っています.
o RSA: 公開鍵を用いた暗号化, 電子署名に使われているアルゴリズムで, 名
称は 3 人の開発者(Rivest, Shamir, Adleman)の頭文字からとられていま
す. 米国では 1983 年に特許の認可を受けています.
暗号に関する詳しい情報は RSA cryptography FAQ に書かれています. これ
は http://www.rsa.com/rsalabs/newfaq/ から入手できます. このドキュメ
ントには "Diffie-Hellman 法", "公開鍵暗号", "電子認証" といった用語に
関する情報が載っています.
訳注: 日本語訳は http://www.rsa-japan.co.jp/faq/index.html にあります.
5.7. SSL, S-HTTP, HTTPS, S/MIME
ユーザは各種セキュリティと暗号化プロトコルの違いや, これらの使い方につ
いてよく質問してきます. このドキュメントは暗号化に関するものではない
のですが, 各プロトコルの内容を簡単に説明し, 情報のありかを紹介しておく
のも悪くないと思います.
o SSL: - SSL (あるいは Secure Sockets Layer)は Netscape が開発した暗
号化手法で, インターネット上でセキュリティを提供します. SSL はいく
つかの異なる暗号化プロトコルとクライアントとサーバの認証手法を提供
します. SSL はトランスポート層を操作し, データの安全な暗号化チャネ
ルを生成するので, 各種データをシームレスに暗号化することができます.
SSL は Communicator で安全なサイトに行き, 安全なオンラインドキュメ
ントにアクセスした時に見られます. 他のたくさんの Netscape
Communicator のデータ暗号化と同様に, これは Communicator を使った安
全な通信の基本部分として用意されています. 詳しい情報は
http://www.consensus.com/security/ssl-talk-faq.html にあります.
Netscape の他のセキュリティ機構の実装と, これらのプロトコルの手引き
については, http://home.netscape.com/info/security-doc.html で入手
できます.
o S-HTTP: - S-HTTP はインターネット上での安全なサービスを提供する別の
プロトコルです. このプロトコルは, 機密性 (confidentiality), 認証
(authentication), 完全性 (integrity), 否認防止性 [ 他の誰かと間違う
ことがあり得ないこと] を与えるために設計されており, また, 各トラン
ザクションにおける通信相手とのオプションのネゴシエーションを通じて,
複数の鍵管理機構と暗号化アルゴリズムをサポートします. S-HTTP は,
これを実装している特定のソフトウェアでしか使えません. また, それぞ
れのメッセージを独立に暗号化します. [ RSA Cryptography FAQ の 138
ページより]
o S/MIME: - S/MIME (すなわち Secure Multipurpose Internet Mail
Extension)は, 暗号化電子メールやその他の種類のインターネット上の
メッセージで使われる暗号化の標準です. これは RSA が開発したオープン
な標準なので, Linux 用のものもたぶん近いうちに登場するでしょう.
S/MIME に関する詳しい情報は
http://home.netscape.com/assist/security/smime/overview.html にあり
ます.
5.8. Linux における IPSEC の実装
CIPE や他の形式のデータ暗号化とともに, Linux 用の IPSEC の実装も複数個
あります. IPSEC は IETF が作った規格で, 暗号化された安全な通信経路を
IP ネットワークレベルで作り, また認証, 完全性, アクセス制御, 機密性も
提供します. IPSEC の情報とインターネットドラフトは
http://www.ietf.org/html.charters/ipsec-charter.html にあります. 鍵管
理を含めて他のプロトコルへのリンク, IPSEC のメーリングリストやアーカイ
ブもあります.
University of Arizona で開発された x-kernel Linux という実装は, オブ
ジェクトベースのフレームワークを使って x-kernel と呼ばれるネットワーク
プロトコルを実装しています. これは
http://www.cs.arizona.edu/xkernel/hpcc-blue/linux.html にあります. 大
雑把に言うと, x-kernel はカーネルレベルでのメッセージパッシングの手法
であり, これにより実装が容易になっています.
これとは別のフリーに利用できる IPSEC の実装は Linux FreeS/WAN IPSEC で
す. その WWW ページを引用すると
「これらのサービスを用いると, 信頼できないネットワーク上に安
全なトンネルを構築することができます. 信頼できないネット
ワークを通るデータは全て IPSEC ゲートウェイマシンにより暗号
化され, その反対の端のゲートウェイによって復号化されます.
これにより仮想プライベートネットワーク (Virtual Private Net-
work, VPN) ができます. これは, 安全でないインターネットで接
続された異なる複数のサイトを含んでいても, 実質的にプライベー
トなネットワークです」
とのことです.
これは http://www.xs4all.nl/~freeswan/ で入手することができます. この
ドキュメントの執筆中にちょうどバージョン 1.0 になりました. 他の形式の
暗号と同様に輸出が制限されているため, デフォルトではカーネルと共に配布
されていません.
5.9. ssh (Secure Shell) と stelnet
ssh と stelnet は, リモートのシステムにログインし, 暗号化された接続を
行うためのプログラム群です.
openssh は rlogin, rsh, rcp の安全な代用品として使われるプログラム群で
す. ssh は 2 つのホスト間の通信とユーザ認証を公開鍵暗号を使って暗号化
します. ssh を使うと安全にリモートホストにログインしたり, ホスト間で
データを安全にコピーしたりすることができ, 割り込み攻撃(セッションのハ
イジャック)や DNS 詐称を防ぐことができます. ssh は接続上でデータ圧縮
も行い, ホスト間での安全な X11 の通信も行います.
いまでは, ssh には何種類かの実装があります. Data Fellows 社によるオリ
ジナルの商用の実装は The ssh home page http://www.datafellows.com にあ
ります.
The excellent Openssh の素晴らしい実装は Data Fellows の ssh の初期の
バージョンを元にしつつ, 特許に関わる部分や占有物が入らなくなるように完
全に作り直されました. フリーで, BSD ライセンスの元にあります.
http://www.openssh.com にあります.
"psst..." という名前の, ssh を一から再実装しようというオープンソースな
プロジェクトもあります. 詳しくは http://www.net.lut.ac.uk/psst/ をご
覧ください.
ssh を Windows PC から Linux の ssh サーバに対して使うこともできます.
Windows 用のクライアントの実装はいくつかあります. その 1 つは
http://guardian.htu.tuwien.ac.at/therapy/ssh/ ですし, DataFellows によ
る商用の実装も http://www.datafellows.com にあります.
SSLeay は Netscape の Secure Sockets Layer プロトコルのフリーの実装で
す. これには Secure telnet, Apache 用のモジュール, いくつかのデータ
ベース等のアプリケーションがいくつか含まれており, DES, IDEA, Blowfish
等のアルゴリズムもいくつか含まれています.
このライブラリを使って, telnet 接続上のデータを暗号化する telnet の安
全な代替プログラムが作られました. SSH と異なり, stelnet は Netscape
が開発した SSL (Secure Sockets Layer) プロトコルを使います. Secure
telnet と Secure FTP は SSLeay FAQ からたどって見つけることができます.
この FAQ は http://www.psy.uq.oz.au/~ftp/Crypto/ にあります.
訳注: 日本語訳が
http://www.infoscience.co.jp/technical/crypto/ssleay_jp.html にありま
す.
SRP は別の安全な telnet/ftp の実装です. その WWW ページを引用すると
「SRP プロジェクトは世界中でフリーに利用できる安全なインター
ネットソフトウェアを開発しています. 完全に安全な telnet と
ftp の配布を始めとして, 我々は弱いネットワーク認証を, セキュ
リティのためにユーザインタフェースを犠牲にしない強力なものに
置き換えたいと考えています. セキュリティがオプションなんて
とんでもない! セキュリティはデフォルトでなければなりませ
ん」
とのことです.
詳しい情報については http://srp.stanford.edu/srp を見てください.
5.10. PAM - 交換可能な認証モジュール
最近のバージョンの Red Hat Linux ディストリビューションでは, "PAM" と
呼ばれる統一された認証方法が使われています. PAM を使うと, システムを
動作させたままで認証の方法や要件を変更することとローカルの認証方法をカ
プセル化することが可能になります. バイナリは一切再コンパイルする必要が
ありません. PAM の設定は本書の範囲を越えますが, 必ず PAM のウェブサイ
トを見て, 詳しい情報を見ておいてください.
http://www.kernel.org/pub/linux/libs/pam/index.html
PAM で可能になることをほんの少しだけ列挙します.
o パスワードに DES 以外の暗号を用いる. (力任せの解読が難しくなります)
o サービス妨害攻撃を実行できなくするため, 全てのユーザに対してリソー
ス (プロセス数, メモリの大きさ等) の制限を加える.
o システムを動作させたまま, シャドウパスワード(後述)を利用可能にする.
o 特定のユーザについて, 特定の回数のみ, 特定の場所からログインを許可
する.
システムのインストールと設定を行う数時間の間に, 実際に攻撃を受ける前に
多くの攻撃を予防しておくことができます. 例えば PAM を使うと, ホーム
ディレクトリの .rhosts ファイルの使用をシステム全体で無効にすることが
できます. 設定は /etc/pam.d/rlogin に以下のような行を追加します:
#
# Disable rsh/rlogin/rexec for users
#
login auth required pam_rhosts_auth.so no_rhosts
5.11. 暗号による IP のカプセル化 (Cryptographic IP Encapsulation,
CIPE)
このソフトウェアの基本的な目的は, インターネットのような安全でないパ
ケットネットワークを通る安全な (トラフィック解析, 偽メッセージ混入を含
む盗聴に対して) サブネットワーク間接続を提供することです.
CIPE はデータをネットワークレベルで暗号化します. つまり, ネットワーク
上のホスト間を転送されるパケットが暗号化されます. 暗号化エンジンはパ
ケットを送受信するドライバの近くに配置されます.
CIPE は, 接続ごとにソケットレベルでデータを暗号化する SSH とは異なりま
す. 異なるホスト上で実行されているプログラム間の論理的な接続が暗号化
されます.
CIPE は仮想プライベートネットワーク (Virtual Private Network) を構築す
るために, トンネリングで使うことができます. 低レベルの暗号化には, アプ
リケーションソフトウェアを変更しなくても, VPN に接続している 2 つの
ネットワーク間で透過的に動作させることができるという利点があります.
CIPE のドキュメントからの要約です:
IPSEC 標準は, 暗号化された VPN を構築するため (他にもありま
すが) に使うことができるプロトコル群を定義しています. しか
し, IPSEC はオプションがたくさんある比較的重くて複雑なプロト
コル群で, プロトコル群の完全な実装はまだほとんど使われておら
ず, 一部の問題 (鍵管理など) はまだ完全には解決されていませ
ん. CIPE は比較的簡単なアプローチを取っており, CIPE におい
てパラメータ化できることの多く (実際に使う暗号化アルゴリズム
の選択など)は, インストール時に選択したものに固定されます.
これは柔軟さを制限しますが, 実装が簡単に (したがって, 効率的
でデバッグもしやすく) なります.
詳しい情報は http://www.inka.de/~bigred/devel/cipe.html にあります.
他の暗号化と同様の輸出制限のため, CIPE はカーネルと一緒には配布されて
いません.
5.12. Kerberos
Kerberos は MIT の Athena Project で開発された認証システムです. ユー
ザがログインした時, Kerberos は(パスワードを用いて)ユーザを認証し,
ネットワーク上に分散している他のサーバやホストに対してユーザの身分を証
明するための方法を提供します.
それから, この認証情報は rlogin のようなプログラムが使い, ユーザがパス
ワード無しで他のホストにログインすることを許可するために使います
(.rhosts ファイルの代わり). この認証方法をメールシステムで使えば, メー
ルが正しい宛先に配達されたことの保証や, 送信者が自分が名乗っている通り
のユーザであることの保証が行えます.
Kerberos およびこれに付属しているプログラムは, あるユーザが, 自分を他
のユーザであるとシステムに思わせる「詐称」を実質的に不可能にします.
Kerberos のインストールは残念ながらシステムに深く立ち入ったものになる
ので, 基本的なプログラムをたくさん修正したり入れ換えたりしなければなり
ません.
Kerberos に関する詳しい情報は the kerberos FAQ にあり, コードは
http://nii.isi.edu/info/kerberos/ にあります.
[参考: Stein, Jennifer G., Clifford Neuman, and Jeffrey L. Schiller.
"Kerberos: An Authentication Service for Open Network Systems." USENIX
Conference Proceedings, Dallas, Texas, Winter 1998.]
Kerberos はホストのセキュリティ向上のために取るべき最初のステップでは
ありません. Kerberos は非常に複雑ですし, 例えば SSH ほど使われている
わけでもありません.
5.13. シャドウパスワード
シャドウパスワードは, 暗号化されたパスワード情報を一般ユーザから隠す手
法です. Red Hat と Debian の両方とも, 最近のバージョンではデフォルト
でシャドウパスワードを使うようになっていますが, ほかのシステムでは, 暗
号化されたパスワードは普通, 誰でも読める /etc/passwd に格納されていま
す. したがって, 誰でもパスワード推測プログラムを実行してパスワードを
見つけようと試みることができます. 一方シャドウパスワードでは, この情
報は特権ユーザしか読めない /etc/shadow ファイルに格納されます. シャド
ウパスワードを利用するためには, パスワード情報へアクセスする必要がある
ユーティリティを全てシャドウパスワード対応に再コンパイルする必要があり
ます. (先述の) PAM を使っていれば, シャドウモジュールを使用するだけで
よく, 実行ファイルを再コンパイルする必要はありません. 必要ならば
Shadow-Password HOWTO を参照して詳しい情報を調べてください. このド
キュメントは http://linuxdoc.org/HOWTO/Shadow-Password-HOWTO.html にあ
ります. このドキュメントは現在は多少古くなっていますし, PAM をサポート
しているディストリビューションではたぶん不要でしょう.
訳注: 和訳は http://www.linux.or.jp/JF/JFdocs/Shadow-Password-
HOWTO.html にあります.
5.14. "Crack" および "John the Ripper"
推測しにくいパスワードをつけることを passwd プログラムにおいて強制する
ことができない場合は, パスワードをクラッキングするプログラムを実行し,
ユーザのパスワードが安全かどうか確認するとよいでしょう.
パスワードクラックのプログラムは, 単純な考えに基づいて動作します. つ
まり, 辞書に載っている単語とこれらの単語の変化形を順に試すのです. そ
れぞれを暗号化し, 暗号化されたパスワード文字列と比べます. これらが一
致すれば, パスワードがわかります.
このようなプログラムはたくさんありますが, その中でも "Crack" と "John
the Ripper" (http://www.false.com/security/john/index.html) の 2 つが
有名です. これらは CPU パワーを大量に消費しますが, 予めこれを実行して
おくことで, 攻撃者がこれらのツールを使って侵入することができるかどうか
知ることができ, 脆弱なパスワードを使っているユーザに注意することができ
ます. 攻撃者はパスワードファイル (UNIX では /etc/passwd) を入手するた
めに, まず他のセキュリティホールを突かなければなりませんが, それは読者
の皆さんが考えているよりもありふれているものであることは知っておいてく
ださい.
最も弱いホストの強さが全体のセキュリティの強さになってしまいます. で
すから, ネットワーク上に Windows マシンがある場合には L0phtCrack を調
べるべきだということは言及しておく価値があるでしょう. これは Crack の
Windows 用の実装です. これは http://www.l0pht.com で入手できます.
5.15. CFS (暗号化ファイルシステム)と TCFS (透過的暗号化ファイルシステ
ム)
CFS はディレクトリツリー全体を暗号化する手法で, このツリーに暗号化され
たファイルを置くことができます. これはローカルマシン上で NFS サーバを
動作させます. RPM は http://www.zedz.net/redhat/ で入手可能であり, 動
作に関する情報は ftp://ftp.research.att.com/dist/mab/ で得られます.
TCFS は CFS を改良したもので, ファイルシステムとの統合をより進めたもの
です. したがって, ユーザは透過的に暗号化ファイルシステムを利用するこ
とができます. 詳しい情報は http://edu-gw.dia.unisa.it/tcfs/ で得られ
ます.
TCFS は必ずしもファイルシステム全体で使う必要はありません. これもディ
レクトリツリーで使用することができます.
5.16. X11, SVGA, ディスプレイに関するセキュリティ
5.16.1. X11
グラフィックディスプレイを安全にしておき, 攻撃者が入力したパスワードを
奪ったり, 画面で見ているドキュメントや情報を読んだり, セキュリティホー
ルを突いて root 権限を奪ったりできないようにしておくことは重要です. X
アプリケーションをネットワーク越しにリモートで動作させることも, リモー
トのシステムとのやりとりを全部盗聴されてしまう危険を伴うことがありま
す.
X にはアクセス制御機構がいくつもあります. その中で最も簡単なものはホ
ストに基づくものです. xhost コマンドを用いれば, ディスプレイへのアク
セスが許可されるホストを指定できます. しかし, この機構は非常に危険で
す. マシンにアクセスできる人は, xhost + を実行し, 容易に侵入すること
ができます. もし, 信頼できないホストからのアクセスを許可しなければな
らない場合には, そのホストにログインしているユーザは誰でもディスプレイ
に不正アクセスすることができます.
ログインのために xdm (X ディスプレイマネージャ) を使っている場合, ずっ
と良いアクセス方法である MIT-MAGIC-COOKIE-1 を使いましょう. この機構
は 128ビット長の「クッキー」を生成して, ユーザのホームディレクトリの
.Xauthority ファイルに格納します. リモートのマシンにディスプレイへの
アクセスを許可するには, xauth コマンドと .Xauthority ファイル内の情報
を使って, その接続だけを許可するようにします. Remote-X-Apps mini-
howto をご覧ください. これは http://linuxdoc.org/HOWTO/mini/Remote-X-
Apps.html で入手できます.
訳注: Remote-X-Apps の和訳 があります.
X の接続を安全に行うために ssh (前述の ``'' の項を参照のこと) を使うこ
ともできます. ssh には, ユーザが透過的に扱うことができる, およびネッ
トワーク上に暗号化されていないデータが流れない, という 2 つの利点があ
ります.
X のセキュリティについての詳しい情報については, オンラインマニュアルの
Xsecurity を参照してください. 安全な策としては, コンソールにログインす
るときには xdm を使い, リモートのサイトで X のプログラムを実行したいと
きは ssh を使うことです.
5.16.2. SVGA
SVGAlib を使うプログラムはビデオ関係のハードウェアを操作するため, 普通
は root に setuid されます. これは非常に危険です. プログラムがクラッ
シュした場合, 普通はコンソールを元に戻すためマシンを再起動しなくてはな
らなくなってしまいます. このようなプログラムについては, 確実に信頼で
きること, あるいは少なくとも少しは信用できることを確かめてください.
できれば, そもそも使わないのが良いでしょう.
5.16.3. GGI (Generic Graphics Interface project)
Linux GGI プロジェクトは Linux のビデオインタフェースの問題についてひ
とつの解を提案しようとする試みです. GGI では Linux のカーネル内に少し
ビデオ関係のコードを入れ, そうしてビデオへアクセスします. つまり, GGI
を使えばいつでもコンソールを正常な状態に戻すことができます. また,
secure attention key を使うことができ, コンソールでトロイの木馬が入っ
た login プログラムを使われるのを防げます.
http://synergy.caltech.edu/~ggi/
6. カーネルのセキュリティ
ここではセキュリティに関連するカーネル設定オプションの説明と, それらの
動作や使い方に関する説明を行います.
カーネルはコンピュータのネットワークを制御するので, カーネルをこの上な
く安全にしておくことと, カーネルそのものが破られないようにすることは重
要です. 最近出現したネットワーク攻撃のいくつかを防ぐために, カーネルの
バージョンは最新に保つようにすべきです. 新しいカーネルは
またはお使いのディストリビューションのベンダか
ら入手できます.
本家の Linux カーネル用にひとつに統合された暗号化パッチを提供している
国際的なグループもあります. このパッチは, 各種暗号サブシステムや輸出
制限のために本家のカーネルに含まれていない機能を提供します. 詳しい情報
についてはグループの WWW ページ http://www.kerneli.org をご覧ください.
6.1. バージョン 2.0 のカーネルのコンパイルオプション
2.0.x カーネルでは以下のオプションが該当します. カーネルを設定する際
にこれらのオプションを確認することになるでしょう. ここに挙げたコメン
トの多くは ./linux/Documentation/Configure.help から取っています. こ
のコメントは, カーネルのコンパイル時にmake config の Help 機能で参照で
きるドキュメントと同じものです.
o Network Firewalls (CONFIG_FIREWALL)
このオプションは Linux マシンでファイアウォールを構築する際や IP マ
スカレードを行う際に有効にすべきです. 単に普通のクライアントマシン
にするつもりならば no と設定するのが安全でしょう.
o IP: forwarding/gatewaying (CONFIG_IP_FORWARD)
IP forwarding を有効にすると, Linux マシンは本質的にルータになりま
す. このマシンがネットワークに繋がっていると, あるネットワークから
別のネットワークにデータを転送しているかもしれず, これを起さないた
めに設置されている防火壁をたぶん壊しています. 通常のダイアルアップ
ユーザはこれを無効にしたいと思うでしょうし, 他のユーザはこれを行う
ことのセキュリティ的な意味を良く考えるべきです. 防火壁のマシンはこ
れを有効にし, 防火壁のソフトウェアと組み合わせて使おうと考えるで
しょう.
IP forwarding は以下のコマンドで動的に有効にすることができます:
root# echo 1 > /proc/sys/net/ipv4/ip_forward
また次のコマンドで無効にすることができます:
root# echo 0 > /proc/sys/net/ipv4/ip_forward
/proc にあるファイルは「仮想的」なファイルであり, 表示されるファイルの
大きさは, そこから出てくるデータの量を反映していないことは覚えておいて
ください.
o IP: syn cookies (CONFIG_SYN_COOKIES)
「SYN 攻撃」はサービス妨害(DoS)攻撃のひとつです. マシンのリソース
を全て喰い潰してしまい, リブートするはめに追い込みます. このオプ
ションを有効にしておかない理由は普通は考えられません. 2.2.x 系の
カーネルでは, この設定オプションは単に syn cookie を許可するだけで,
有効にはしません. これを有効にするには以下のコマンドを実行する必要
があります:
root# echo 1 > /proc/sys/net/ipv4/tcp_syncookies
o IP: Firewalling (CONFIG_IP_FIREWALL)
このオプションが必要になるのは, マシンを防火壁として設定する時や,
IP マスカレードを行う時に PPP のダイアルアップインタフェース経由で
何者かがダイアルアップマシンに入ってくるのを防ぎたい時です.
o IP: firewall packet logging (CONFIG_IP_FIREWALL_VERBOSE)
このオプションを使うと, 送信者, 受信者, ポート等の防火壁が受け取っ
たパケットに関する情報が記録されます.
o IP: Drop source routed frames (CONFIG_IP_NOSR)
このオプションは有効にすべきです. 始点で経路設定されたフレーム
(source routed frames) は, 終点までの全体のパスをパケット内に持って
います. つまり, パケットが通るルータはパケットを検査する必要がな
く, 単に転送すればよいということです. これは危険であるかもしれない
データをシステムに入れる可能性を持ちます.
o IP: masquerading (CONFIG_IP_MASQUERADE)
Linux マシンが防火壁として動作している場合, そのローカルネットワー
クのコンピュータのひとつが外部に接続しようとすると, Linux マシンは
そのホストの「仮面を被る」ことができます. つまり, Linux マシンは
ローカルネットワーク内のマシンが想定している終点アドレスへトラ
フィックを転送しますが, このトラフィックが防火壁のマシンから来たよ
うに見せかけます. 詳しい情報については
http://www.indyramp.com/masq をご覧ください.
o IP: ICMP masquerading (CONFIG_IP_MASQUERADE_ICMP)
前のオプションは TCP トラフィックと UDP トラフィックのマスカレー
ディングしか行いませんが, このオプションは ICMP のマスカレーディン
グも行うようにします.
o IP: transparent proxy support (CONFIG_IP_TRANSPARENT_PROXY)
このオプションは, Linux マシンの防火壁の透過的リダイレクト機能を有
効にします. つまり, ローカルネットワークが始点であり, かつ終点がリ
モートホストであるような任意のネットワークトラフィックがローカルの
サーバ (いわゆる「透過的プロキシサーバ」) にリダイレクトされます.
これにより, ローカルのコンピュータにリモート側と通信していると思わ
せながら, 実際にはローカルのプロキシと接続した状態にします. 詳しく
は IP-Masquerading HOWTO と http://www.indyramp.com/masq をご覧くだ
さい.
o IP: always defragment (CONFIG_IP_ALWAYS_DEFRAG)
普通はこのオプションは無効になっていますが, 防火壁や IP マスカレー
ドを行うホストを構築する場合には, このオプションを有効にしたくなる
はずです. あるホストから別のホストまでデータが送られる時, データは
必ずしも単独のデータパケットだけで送られるわけではなく, 複数個のパ
ケットに分割されます. このやり方の問題点は, ポート番号は最初のパ
ケットにしか格納されていないことです. つまり, 何者かが入っていない
はずの情報をその接続の残りのパケットに入れることが可能なのです. こ
のオプションは, teardrop 攻撃に対するパッチを当てていない内部ホスト
に対する teardrop 攻撃も防ぐことができるはずです.
o Packet Signatures (CONFIG_NCPFS_PACKET_SIGNING)
このオプションは 2.2.x 系列のカーネルで利用可能なオプションで, セ
キュリティを強固にするために NCP パケットに署名をするようにします.
通常は無効にしておいて構いませんが, 必要ならばどうぞ.
o IP: Firewall packet netlink device (CONFIG_IP_FIREWALL_NETLINK)
これは実に便利なオプションで, ユーザ空間プログラムのパケットの先頭
の 128 バイトを解析し, 正当さに基づいてそのパケットを許すか拒否する
かを決めるようにできます.
6.2. バージョン 2.2 のカーネルのコンパイルオプション
2.2.x カーネルでも多くのオプションは同じですが, 新しいオプションもいく
つか開発されています. ここに挙げたコメントの多くは
./linux/Documentation/Configure.help から取っています. このコメント
は, カーネルのコンパイル時に make config の Help 機能で参照できるド
キュメントと同じものです. 以下では新しく追加されたオプションだけを示
します. 必要な他のオプションについては, 2.0 用の説明を参照してくださ
い. 2.2 カーネルにおける最大の変更点は, IP firewalling のコードです.
2.2 カーネルからは, IP firewalling を行うには, ipchains を使うようにな
りました. 2.0 カーネルで使われていた ipfwadm は使いません.
o Socket Filtering (CONFIG_FILTER)
大抵の人にとっては, このオプションに no を設定しておくのが安全です.
このオプションを使うと, ユーザ空間のフィルタを任意のソケットに接続
して, パケットを受け取るか拒否するかを決めることができます. どうし
ても必要, かつフィルタのようなプログラムを組めないのなら, このオプ
ションには no を設定すべきです. 本 HOWTO の執筆時点では, TCP を除く
全てのプロトコルがサポートされています.
o Port Forwarding ポート転送 (Port Forwarding) は IP マスカレードへの
追加機能であり, 指定されたポートにおける一部のパケットについて, 防
火壁の外部から内部への転送を許可します. このオプションが役立つの
は, 例えば WWW サーバを防火壁の中や IP マスカレードを行うホストの後
ろで実行し, これを外の世界からアクセスできるようにしたい場合です.
外部のクライアントが防火壁の 80 番ポートにリクエストを送ると, 防火
壁はこのリクエストを WWW サーバに転送します. WWW サーバはリクエス
トを処理し, その結果を防火壁経由で元のクライアントに送ります. クラ
イアントにとっては, 防火壁のマシンで WWW サーバが動いているように見
えます. この機能は, 防火壁の後ろに全く同じ構成の WWW サーバが複数
ある場合に負荷調整 (load balancing) を行うためにも使えます.
この機能に関する情報は
http://www.monmouth.demon.co.uk/ipsubs/portforwarding.html にありま
す (WWW を見るには, インターネットに接続しており, かつ lynx や
Netscape のようなプログラムが使えるマシンが必要です). 一般的な情報
については ftp://ftp.compsoc.net/users/steve/ipportfw/linux21/ をご
覧ください.
o Socket Filtering (CONFIG_FILTER) このオプションを使うと, ユーザ空間
プログラムは任意のソケットにフィルタを付けることができ, 特定の種類
のデータをソケット経由で取得する際に許可するか拒否するかをカーネル
に指示することができます. Linux のソケットフィルタリングは, 現在
TCP を除く全ての種類のソケットで動作します. 詳しくはテキストファイ
ル ./linux/Documentation/networking/filter.txt をご覧ください.
訳注: カーネルのソースに含まれているテキストファイルのことです.
o IP: Masquerading カーネル 2.2 の IP マスカレードは改良されています.
特殊なプロトコルのマスカレーディング等のサポートが追加されています.
詳しくは IP Chains HOWTO をご覧ください.
6.3. カーネルデバイス
Linux には, セキュリティの向上にも使えるブロックデバイスやキャラクタデ
バイスがいくつかあります.
/dev/random と /dev/urandom という, いつでもランダムなデータを取り出せ
る 2 つのデバイスがカーネルに用意されています.
/dev/random と /dev/urandom はどちらも安全であり, PGP の鍵や ssh の
チャレンジ文字列の生成や, ランダムな数字を必要とする他のアプリケーショ
ンで利用できるはずです. これらを入力として数の初期シーケンスを与えて
も, 攻撃者が次の数を予測することは不可能なはずです. これらの入力から
得た数字があらゆる意味において言葉通りランダムであることを保証するた
め, 大変な努力が行われてきました.
2 つのデバイスの唯一の違いは, /dev/random はランダムなバイト列を全て使
う点と, 計算を行うためのユーザの待ち時間がより長い点です. 一部のシス
テムでは, ユーザが生成したエントロピーがシステムに入るのを待つ長い間,
ブロックされてしまうことに注意してください. したがって, /dev/random
を使う前には気を付ける必要があります. (これの利用の最良の場面はおそら
く, 機密キー入力情報を生成する時で, ユーザに「はい, もう十分です」と表
示するまでキーボードを繰り返し叩いてもらう場合です)
/dev/random は非常に高品質のエントロピーを持ち, 割り込み間の時間等の測
定値から生成しています. このデバイスは十分なビット数のランダムデータが
利用可能になるまでブロックします.
/dev/urandom も同様ですが, エントロピーの保持量が少なくなると, 現在保
持している値の暗号学的に強いハッシュ値を返します. これは /dev/random
ほど安全ではありませんが, ほとんどの目的に対してはこれで十分です.
このデバイスは以下のようにして読み出すことができます:
root# head -c 6 /dev/urandom | mmencode
root# head -c 6 /dev/urandom | mimencode
これはコンソールに 8 つのランダムな文字を出力します. パスワード生成な
どによいでしょう. mimeencode は metamail パッケージに入っています.
アルゴリズムの説明については, /usr/src/linux/drivers/char/random.c を
参照してください.
これについて筆者(Dave)に教えてくださった, Theodore Y. Ts'o さん, Jon
Lewis さん他の Linux-kernel ML の皆さんに感謝します.
7. ネットワークのセキュリティ
ネットワークに接続する時間が長ければ長いほど, ネットワークのセキュリ
ティが重要になってきます. ネットワークのセキュリティを破ることは, 物
理的あるいはローカルのセキュリティを破るよりも簡単なことが多く, よりあ
りふれたことです.
ネットワークのセキュリティ確保を支援するための良いツールはたくさんあ
り, これらの多くは Linux の各ディストリビューションにも付属しています.
7.1. パケット盗聴
侵入者がネットワーク上でより多くのシステムのアクセス権を得るためによく
使う方法の一つが, 既に悪用しているホスト上でパケット盗聴プログラムを使
うことです. この「盗聴プログラム」は, イーサネット上のパケットストリー
ムの passwd, login, su のようなものを監視し, その後のトラフィックをロ
グに残します. このようにして, 侵入者は破ろうとさえとしていないシステム
のパスワードも得てしまいます. 平文の(暗号化されていない)パスワードは,
このような攻撃に対して非常に脆弱です.
例: ホスト A は既に破られています. 攻撃者はパケット盗聴プログラムをイ
ンストールします. ホスト C からホスト B への管理者のログインを拾い出し
ます. まず管理者が B にログインするときに, 個人のパスワードを入手しま
す. それから, 管理者は何か問題を処理するために su を実行します. このと
きに, ホスト B の root のパスワードが入手できます. 後で, 管理者が誰か
を他のサイトのホスト Z に telnet させます. こうして, 攻撃者はホスト Z
の password/login を入手することができます.
今日では, 攻撃者はこの攻撃を行うためにシステムを破る必要などありませ
ん. ノートパソコン等を建物に持ち込み, ネットワークに繋いでしまえばよ
いのです.
この攻撃を防ぐには, ssh 等のパスワード認証を暗号化します. POP の場合に
は APOP 等を使うことで, この攻撃を防ぐことができます. (通常の POP は,
パスワードを暗号化せずにネットワーク上に流すので, この攻撃に対して非常
に脆弱です. )
7.2. システムサービスと tcp_wrappers
どんなネットワークであれ, Linux システムを接続する前にまず確認すべきこ
とは, どのサービスを提供するかです. 提供する必要が無いサービスは無効に
するべきであり, そうすることで 心配の種を一つ減らすことができ, 攻撃者
がセキュリティホールを探す余地も一つ減ります.
Linux でサービスを無効にするための方法は色々あります. /etc/inetd.conf
ファイルを見れば, inetd 経由で提供されているサービスを確認することがで
きます. 必要の無いサービスは, コメントアウトして(行の先頭に # を挿入し
ます), inetd のプロセスに SIGHUP を送ることで無効にすることができます.
/etc/services ファイル内のサービスを削除 (またはコメントアウト) する方
法もあります. これによりローカルのクライアントもサービスを見つけられ
なくなります (例えば ftp の項を削除し, そのマシンからリモートサイトへ
ftp すると, "unknown service" というエラーになるでしょう). しかし,
サービスの削除に伴うトラブルに見合うだけの価値はないでしょう. という
のも, /etc/services からサービスを削除してもセキュリティが向上するわけ
ではないからです. /etc/services で ftp の項目をコメントアウトしていて
も, ローカルのユーザが ftp を使いたければ, FTP の一般的なポート番号を
使うクライアントを用意すればちゃんと動作するのですから.
有効なまま残しておくとよいサービスには以下のようなものがあります:
o ftp
o telnet (or ssh)
o mail, such as pop-3 or imap
o identd
特定のパッケージを使わないことが分かっているならば, そのパッケージを全
部削除する方法もあります. Red Hat ディストリビューションでは, rpm -e
パッケージ名 というコマンドがパッケージ全体を削除するコマンドです.
Debian の場合は, dpkg --remove コマンドで同様のことが実行できます.
加えて, rsh/rlogin/rcp ユーティリティ(/etc/inetd.conf から login
(rlogin が使用), shell(rcp が使用), exec (rsh が使用)の項目を含む)が
/etc/inetd.conf から起動されるのを無効にしたいと思うことでしょう. これ
らのプロトコルは非常に危険ですし, 過去にも攻撃を受ける原因となってきま
した.
/etc/rc.d/rc[0-9].d (Red Hat の場合. Debian では /etc/rc[0-9].d) ディ
レクトリをチェックし, 不要なサーバが起動されていないかどうか確認しま
しょう. こういったディレクトリ中のファイルは実際には /etc/rc.d/init.d
ディレクトリ (Red Hat の場合. Debian では /etc/init.d) 中のファイルへ
のシンボリックリンクです. init.d ディレクトリ中のファイルの名前を変更
すると, そのファイルに対するシンボリックリンクを無効にすることができま
す. 特定のランレベルのサービスだけを無効にしたい場合は, そのサービス
に対応するシンボリックリンクの大文字 'S' を小文字の 's' に名称変更して
ください. これは以下のように行います:
root# cd /etc/rc6.d
root# mv S45dhcpd s45dhcpd
BSD スタイルの rc ファイルのシステムの場合には, 不要なプログラムは
/etc/rc* から探します.
ほとんどの Linux ディストリビューションには, 全ての TCP サービスを
「ラッピング(包む)」する tcp_wrappers が付いています.
tcp_wrapper(tcpd)は, inetd が実際のサーバの代わりに呼び出します. tcpd
はサービスを要求したホストをチェックし, サーバの起動かアクセス拒否を行
います. /etc/hosts.allow ファイルを作り, そのマシンのサービスを受ける
必要があるマシンだけを指定しましょう.
家からダイアルアップ接続しているユーザは, 全てを拒否する設定をお勧めし
ます. tcpd はサービスへのアクセス失敗を記録することもできるので, 攻撃
を受けた際には警告を受けることができます. 新しいサービスを追加する際
には, それが TCP ベースのものなら, 必ず tcp_wrappers を使う設定にすべ
きです. 例えば通常のダイアルアップユーザは外部からの接続を禁止するこ
とができますが, その状態でもメールの取得やインターネットへのネットワー
ク接続はできます. これを行うには, /etc/hosts.allow に以下の設定を追加
してください:
ALL: 127
また, 当然ながら /etc/hosts.deny も関係あります.
ALL: ALL
これにより, 外部からあなたのマシンへの接続は全て禁止されますが, 内部か
らインターネット上のサーバへの接続は許されます.
tcp_wrappers が守れるのは inetd から実行するサービスだけであり, 他を選
択する余地はほとんどないことを覚えておいてください. サービスは他にも
たくさん実行されているかもしれません. netstat -ta を実行すれば, お使
いのマシンで行われているサービスを全て表示することができます.
7.3. DNS 情報の確認
自分のネットワーク上の全てのホストに関して最新の DNS 情報を保つことは,
セキュリティの向上に繋がります. 許可されていないホストがネットワークに
繋がれた際には, そのホストが DNS エントリを持たないことから識別するこ
とができます. サービスの多くは正しい DNS エントリを持たないマシンから
の接続を受け付けないように設定することができます.
7.4. identd
identd は一般的に inetd の代わりとなる小さなプログラムです. identd は
どのユーザがどの TCP サービスを受けているかを常に監視し, 要求に応じて
この結果を報告します.
多くの人は identd の有益さを誤解しており, identd を無効にしたり, 外部
サイトからの identd へのリクエストをブロックしたりしています. identd
はリモートサイトを助けるためにあるのではありません. リモートの identd
から得たデータが正しいかどうかを知る術はありません. identd のリクエス
トは認証を行いません.
それでは, どうして identd を使うのでしょうか? それは読者の皆さんを助け
てくれるからであり, 追跡調査の際のデータになるからです. identd が悪用
されていなければ, リモートサイトに TCP サービスを受けたユーザ名やユー
ザID を知らせることができます. リモートサイトの管理者が戻ってきて彼ら
のサイトが攻撃されていると言ってきた場合, 簡単にそのユーザに対して行動
を起こすことができます. もし identd が動いていなければ, 大量のログを調
べ, その時に誰がいたのか調べなければなりませんが, そのユーザを突き止め
ることは一般にとても時間がかかる作業です.
ほとんどのディストリビューションに付属している identd は一般に思われて
いるよりも細かい設定が可能です. 特定のユーザについて identd を無効にす
ることができますし(.noident ファイルを作ります), identd リクエストのロ
グを全て残すこともできますし(この設定をお勧めします), ユーザ名の代わり
にユーザID や NO-USER を返すようにすることさえできます.
7.5. SATAN, ISS その他のネットワーク探査プログラム
マシンやネットワークのポートやサービスの探査を行うソフトウェアのパッ
ケージはいろいろあります. SATAN や ISS, SAINT, Nessus はこの種のパッ
ケージの中でも特に有名なものです. このソフトウェアは調査対象のマシン
(あるいはネットワーク上の全ての対象マシン) の接続可能なポート全てに接
続し, そのポートで提供されているサービスについて調べようとします. こ
の情報に基づいて, サーバに対する特定の攻撃に対してマシンが脆弱であるか
どうか調べることができます.
SATAN(Security Administrator's Tool for Analyzing Networks)はウェブの
インタフェースを持つポート探査プログラムです. マシンあるいはネットワー
クに対して, light, medium, strong いずれかのチェックを行う設定ができま
す. SATAN を入手し, 自分のマシンやネットワークを検査し, 見つかった問題
を修正するとよいでしょう. 必ず, SATAN は metalab
か有名
FTP/ウェブサイトから入手しましょう. 過去に, トロイの木馬が仕込まれた
SATAN がネットワーク上で配布されたことがあるからです.
http://www.trouble.org/~zen/satan/satan.html. SATAN はしばらく更新され
ていないため, この後で説明する他のツールの方が役に立つかもしれません.
ISS (Internet Security Scanner) もポートを検査するプログラムです. ISS
は SATAN よりも動作が軽いので, 大規模ネットワークに向いているでしょう.
ただし, 得られる情報は SATAN の方が詳しいようです.
Abacus は, ホストベースのセキュリティと侵入者発見の機能を持つツールで
す. 詳しい情報については WWW 上のホームページを見てください.
http://www.psionic.com/abacus/
SAINT は SATAN の新しいバージョンです. SAINT はウェブベースであり,
SATAN よりも新しい検査がたくさん追加されています. 詳しくは
http://www.wwdsi.com/saint を見てください.
Nessus はフリーのセキュリティ検査プログラムです. これは GTK による使い
やすいグラフィカルインタフェースを持っています. また, 新しいポート探査
を設定するための素晴らしいプラグイン機構を備えています. 詳しい情報につ
いては http://www.nessus.org を見てください.
7.5.1. ポート探査を受けたことの検出
SATAN や ISS などの探査プログラムによる探査を受けたことを警告するため
に設計されたツールがいくつかあります. しかし, tcp_wrappers をうまく使
い, ログを定期的に見ていれば, このような探査があったことはわかります.
最低限の設定でも, SATAN は Red Hat の標準システムのログに痕跡を残しま
す.
「見えない」ポート探査もあります. TCP ACK ビットがセットされているパ
ケット(確立されている接続ではそうなっています)は多分, パケットフィルタ
リングを行う防火壁を通過するでしょう. 確立されているセッションを持たな
いポートから返される RST パケットは, そのポートが生きている証拠として
受け取ることができます. TCP wrappers はこれを検出できないと思います.
7.6. sendmail , qmail 等の MTA
ユーザに提供するサービスの中でも特に重要なものの 1 つは, メールサーバ
です. 残念ながら, これは攻撃に特に弱いものの 1 つでもあります. 単にそ
の理由は, やらなければならない仕事の数が多いことと, 一般に root ユーザ
の権限を必要とするからです.
sendmail を使う場合には特に, 必ず最新バージョンを使うことが重要です.
sendmail にはセキュリティの問題の長い長い歴史があります. いつも必ず最
新バージョンを動作させましょう. http://www.sendmail.org
メールを送信するだけなら sendmail を実行する必要はないことは知っておい
てください. 家庭ユーザであれば, sendmail を完全に使えなくしてしまい,
メールの送信には単にメールクライアントを使うということもできます.
sendmail の起動ファイルから "-bd" フラグを削除しても良いでしょう. これ
によりメール送信のリクエストが無効になります. 言い換えれば, 今までの起
動スクリプトではなく以下のコマンドを使って sendmail を実行すればよいと
いうことです:
# /usr/lib/sendmail -q15m
これにより sendmail は, 最初に送信したときにうまく配送できなかったメー
ルについて, 15 分ごとに送信キューをフラッシュします.
管理者の多くは sendmail を使わないで, 別のメール配送エージェントを使う
ようになっています. qmail への乗り換えを検討してもよいでしょう. qmail
は徹底的にセキュリティに注意して設計されています. qmail は高速かつ安
定, 安全です. qmail は http://www.qmail.org で入手することができます.
訳注: http://www.jp.qmail.org も参考になるでしょう.
qmail の対抗馬は "postfix" です. これは tcp_wrappers 等のセキュリティ
関連ツールの作者である Wietse Venema 氏が書かれたものです. 以前は
vmailer と呼ばれ, IBM の支援を受けていました. これも徹底的にセキュリ
ティに配慮して書かれたメール配送エージェントです. postfix に関する
もっと詳しい情報については http://www.postfix.org をご覧ください.
7.7. サービス妨害攻撃
「サービス妨害攻撃(Denial of Service attack, DoS attack)」は, リソース
を食い潰すことにより, 正当なリクエストに応じられないようにしたり, 正当
なユーザがマシンにアクセスできないようにする攻撃です.
サービス妨害攻撃は近年とても増えています. ここでは, 有名なものや最近の
ものをいくつか紹介します. 新しいものが常に現れるので, ここ示す例はほん
の一部に過ぎない点には注意してください. 最新の情報を知るには, Linux の
セキュリティ関連メーリングリストや bugtraq メーリングリストやこれらの
アーカイブを読みましょう.
o SYN Flooding - SYN flooding はネットワークでのサービス妨害攻撃です.
これは TCP 接続を確立する際の手順の「抜け穴」を利用するものです.
新しい Linux カーネル(2.0.30 以降)には, SYN flooding 攻撃によりユー
ザがマシンやサービスにアクセスできなくなることを防ぐための設定オプ
ションがあります. カーネルの適切な防御用オプションについては, ``
カーネルのセキュリティ'' の章を参照してください.
o Pentium の "F00F" バグ -これは最近見つかったもので, 特定のアセンブ
リコードを純正の Intel Pentium プロセッサに送ると, マシンがリブート
してしまうというものです. この影響は, 実行している OS に関係なく
Pentium プロセッサを積んでいる全てのマシンが受けます(互換 CPU や
Pentium Pro, Pentium II では問題ありません). Linux 2.0.32 以降には,
このバグに対する対処が入っているので, マシンが止まってしまうことは
ありません. カーネル 2.0.33 での対処はさらに改良されており, カーネ
ル 2.0.32 よりもお勧めできます. 現在 Pentium を使っているのなら,
カーネルのバージョンをすぐに上げましょう!
o Ping Flooding - Ping flooding は単純な力任せのサービス妨害攻撃です.
攻撃者は対象となるマシンに ICMP パケットの「洪水(flood)」を送りま
す. 攻撃する側のマシンが攻撃を受ける側のマシンより広いバンド幅を
持っていた場合, 攻撃を受けたマシンはネットワークに何も送れなくなっ
てしまいます. この攻撃の一種である "smurfing 攻撃" では, あるホスト
に対して, あなたのマシンの IP アドレスを返答先とした ICMP パケット
を送り, ばれないように洪水を送ります. "smurf" 攻撃に関する情報は
http://www.quadrunner.com/~chuegen/smurf.txt で詳しく調べることがで
きます.
ping flooding 攻撃を受けた場合は, tcpdump などのツールを使ってどこ
からパケットが来たのか(あるいは来たように見えるのか)を調べ, 読者の
皆さんが接続しているプロバイダにこのデータに基づいて相談しましょう.
ping flood 攻撃はルータのレベルや防火壁の利用で簡単に止めることがで
きます.
o Ping o' Death - Ping o' Death 攻撃は, ICMP ECHO REQUEST パケットを
格納するためのカーネルのデータ構造体よりも大きい ICMP ECHO REQUEST
パケットを送るものです. 巨大な(65,510 バイト) "ping" パケット 1 つ
を送っただけで多くのシステムがハングしたり, クラッシュすることさえ
あるため, この問題はそのまま "Ping o' Death" という名前を授けられま
した. この問題はずっと前に修正されているので, 現在は心配の必要は全
くありません.
o Teardrop / New Tear - ごく最近の攻撃で, Linux と Windows プラット
フォームの IP フラグメンテーションのバグを利用したものです. これに
対する修正はカーネルのバージョン 2.0.33 で行われており, この修正を
有効にするためにコンパイル時のオプションを選択する必要はありません.
見たところ, Linux は 'newtear' 攻撃は受け付けないようです.
ほとんどの攻撃に関するコードおよびそのコードの動作原理に関する突っ
込んだ説明は, http://www.rootshell.com の検索エンジンを使って調べる
ことができます.
7.8. NFS (Network File System) のセキュリティ
NFS は大変広く使われているファイル共有プロトコルです. nfsd と mountd
が動作しているサーバマシンは, カーネルに NFS ファイルシステムのサポー
トが組み込まれている他のマシン(NFS クライアント機能をサポートしていれ
ば Linux でなくても構いません)にファイルシステム全体を「エクスポート」
することができます. mountd は /etc/mtab に記録されているマウントされて
いるファイルシステムを監視しています. これらのファイルシステムは
showmount コマンドで表示することができます.
多くのサイトでは, ユーザのホームディレクトリを提供するために NFS を用
いており, LAN のどのマシンにログインした場合にも同じホームディレクトリ
を使うことができます.
ファイルシステムをエクスポートする時には, 少しだけセキュリティをかける
ことができます. nfsd にはリモートの root ユーザ(ユーザID = 0) を
nobody ユーザとして扱わせ, エクスポートしたファイル全体にはアクセスで
きないように設定できます. しかし, 個々のユーザは自分の(あるいは少なく
とも同じユーザ ID の)ファイルにはアクセスできるので, ローカルのスー
パーユーザはそのユーザとしてログインするか su を行えば, そのユーザの
ファイル全てにアクセスすることができます. つまり, この方法は読者の皆さ
んのリモートファイルシステムをマウントできる攻撃者に対してはちょっとし
た妨害にしかなりません.
NFS を使わなければならない場合は, 本当に必要なマシンだけにエクスポート
することを徹底しましょう. ルートディレクトリ以下全部をエクスポートする
ようなことは絶対に行ってはなりません. エクスポートの必要があるディレク
トリだけをエクスポートしましょう.
NFS に関する詳しい情報については NFS HOWTO を参照してください. これは
http://metalab.unc.edu/mdw/HOWTO/NFS-HOWTO.html にあります.
7.9. NIS (Network Information service) (かつての YP)
NIS (かつての YP) は, 多数のマシンに情報を配布するための仕組みです.
NIS マスタは情報テーブルを保持し, これを NIS マップファイルに変換しま
す. このマップはネットワーク上で得ることができるので, NIS クライアント
はログイン名, パスワード, ホームディレクトリ, シェルの情報(標準的な
/etc/passwd ファイルに書かれている全ての情報)を得ることができます. こ
れにより, パスワードを一度変えるだけで, NIS ドメイン上の全てのマシンで
新しい設定を有効にできます.
NIS は全く安全ではありません. そもそも安全にするつもりもなく, 手軽で便
利に使うことが目的でした. NIS ドメインの名前を推測できれば誰でも(ネッ
トワークのどこからでも)パスワードファイルのコピーを得ることができ,
"Crack" や "John the Ripper" 等を使ってパスワードを破ることができます.
また, なりすまし等の汚いトリックも色々可能です. NIS を使わなければなら
ない場合には, この危険性は知っておいてください.
NIS+ と呼ばれる NIS よりもずっと安全な代替策があります. 詳しくは NIS
HOWTO を参照してください: (http://metalab.unc.edu/mdw/HOWTO/NIS-
HOWTO.html).
7.10. 防火壁(ファイアウォール)
防火壁は, ローカルのネットワークに出入りできる情報を制御するための仕組
みです. 普通, 防火壁になるホストはインターネットとローカルの LAN に接
続され, あなたの LAN からインターネットへのアクセスは防火壁を通り抜け
るしかないようになっています. このように, 防火壁はインターネットと
LAN の行き来を制御します.
防火壁にはたくさんの種類があり, その設定方法もたくさんあります. Linux
はかなり良い防火壁になります. 防火壁のコードは 2.0 以降のカーネルに組
み込むことができます. カーネル 2.0 には ユーザ空間で動作する ipfwadm,
カーネル 2.2 には ipchains というツールを使って, 許可するネットワーク
トラフィックの種類をシステムの動作中に変更することができます. 特定の
ネットワークトラフィックのログを取ることもできます.
防火壁はネットワークを守るために大変便利かつ重要な技術です. ただし, 防
火壁があるからといって, その内部のマシンのセキュリティが不必要なわけで
は決してありません. これは極めて重大な誤りです. 防火壁と Linux につい
ての詳しい情報については, metalab の最新のアーカイブにある Firewall-
HOWTO がとても良い資料なので, これを参照してください
(http://metalab.unc.edu/mdw/HOWTO/Firewall-HOWTO.html).
更に IP-Masquerade mini-howto にも情報があります
(http://metalab.unc.edu/mdw/HOWTO/mini/IP-Masquerade.html).
ipfwadm (防火壁の設定を変更するためのツール) に関する詳しい情報は以下
のホームページにあります: http://www.xos.nl/linux/ipfwadm/
防火壁に関する経験をお持ちでないのに, 単なるセキュリティ方針だけでなく
防火壁そのものを設定する予定であれば, O'Reilly and Associates 社の書籍
「Firewalls」またはその他のオンラインドキュメントを必ず読んでください.
この書籍の詳しい情報については http://www.ora.com/ をご覧ください. 国
立標準技術研究所 (The National Institute of Standards and Technology)
も防火壁に関する素晴らしいドキュメントをまとめています. 日付は 1995
年となっていますが, 現在でも非常に役立ちます. これは
http://csrc.nist.gov/nistpubs/800-10/main.html にあります. ほかには:
o The Freefire Project -- フリーに利用できる防火壁用ツールのリストで
す. http://sites.inka.de/sites/lina/freefire-l/index_en.html にあり
ます.
o SunWorld Firewall Design -- O'Reilly の書籍の著者が書いたドキュメン
トであり, 各種の防火壁を簡単に紹介しています.
http://www.sunworld.com/swol-01-1996/swol-01-firewall.html にありま
す.
o Mason -- Linux 向けの防火壁自動構築ツールです. あなたがネットワー
クでやりたいことをやれば, それを学習する防火壁スクリプトです! 詳し
くは: http://www.pobox.com/~wstearns/mason/ をどうぞ.
7.11. IP Chains - Linux カーネル 2.2.x における防火壁の構築
Linux の IP Firewalling Chains はカーネル 2.0 の防火壁用のコードをカー
ネル 2.2 用に更新したものです. これは以前の実装よりもずっと多くの機能
を持っています. 以下に列挙します:
o より柔軟なパケット操作
o より複雑なアカウンティング
o 非常に細かい操作ができ, 簡単なポリシー変更
o フラグメントの明示的なブロックや拒否など
o 怪しいパケットの記録
o ICMP/TCP/UDP 以外のプロトコルの処理
現在, カーネル 2.0 で ipfwadm をお使いであれば, ipfwadm のコマンド形式
を ipchains で使える形式に変換するスクリプトがあります.
詳しくは IP Chains HOWTO をお読みください. これは
http://www.rustcorp.com/linux/ipchains/HOWTO.html にあります.
7.12. 仮想プライベートネットワーク(VPN, Virtual Private Network)
VPN は何らかの既存ネットワークの上に「仮想的な」ネットワークを確立する
手法です. この仮想ネットワークは, 暗号化されていたり, ネットワークに
加わっている何らかの既知の存在との間のトラフィックしか通さないように
なっていたりします. VPN は, 家で作業している人と会社の内部ネットワー
クをインターネット経由で接続するためにもよく使われます.
Linux の IP マスカレードを行う防火壁を使っており, かつ MS の PPTP
(Microsoft 製の VPN 接続のための製品) パケットを通過させる必要がある場
合には, これを行うためのカーネルパッチを使ってください. ip-masq-vpn を
ご覧ください.
Linux で利用できる VPN のソリューションはいくつかあります:
o vpnd. http://sunsite.auc.dk/vpnd/ をご覧ください.
o Free S/Wan. http://www.xs4all.nl/~freeswan/ をご覧ください.
o ssh を使って VPN を構築することができます. 詳しくは VPN mini-howto
をご覧ください.
o vps (virtual private server). http://www.strongcrypto.com をご覧く
ださい.
情報ポインタや詳しい情報については, IPSEC の章もご覧ください.
8. セキュリティの準備 (ネットワークに接続する前に)
さて, システムのチェックが終わり, 安全かつ使いやすいものになり, ネット
ワークに接続する準備ができました. ここでは, 実際に侵入された場合に備え
ての準備のためにすべきことをいくつか挙げます. これを行っておけば, 侵入
者をすぐに追い払い, システムを復旧, 稼働させることができます.
8.1. マシン全体のバックアップの作成
バックアップの方法や保存媒体についての議論は本ドキュメントの範囲外です
が, バックアップとセキュリティについて簡単に触れておきます:
1 つのパーティションに入っているデータが 650MB 以下であれば, CD-R に
データをコピーすると良いでしょう(改竄が困難ですし, きちんと保管すれば
長期間保存できます). テープなどの読み書き可能なメディアは, バックアッ
プが終わり次第書き込み禁止にし, 改竄できないようにすべきです. バック
アップはオンラインでアクセスできない場所に置きましょう. 良いバックアッ
プを作っておけば, 何かあった時にシステムをその時点に復旧させることがで
きます.
8.2. 適切なバックアップ計画の決定
6 本のテープを使い回すと管理が楽です. 4 本のテープを平日に使い, 残りの
2 本は 1 本ずつ金曜日に隔週で使います. 毎日インクリメンタルバックアッ
プを実行し, 金曜日のテープ(適切な方)にはフルバックアップを取ります.
特に重要な変更がシステムにあった場合や, 重要なデータを加えた場合には,
バックアップを行うのが適切でしょう.
8.3. RPM ファイルデータベースや Debian のファイルデータベースのバック
アップ
システムに侵入された時に RPM データベースを tripwire 代わりに使うこと
ができますが, これはデータベースが改竄されていないことが確実な場合だけ
です. ですから, RPM データベースをフロッピーディスクにコピーしておき,
コンピュータから取り出して保管しておきましょう. Debian ディストリ
ビューションについても同様です.
ファイル /var/lib/rpm/fileindex.rpm や /var/lib/rpm/packages.rpm は大
抵フロッピーディスク 1 枚には収まらないでしょう. ですが圧縮すれば別々
のフロッピーディスクに収めることができるはずです.
仮にシステムに侵入されてしまったときには, 次のコマンドを実行してシステ
ムの各ファイルを検査します:
root# rpm -Va
rpm のオンラインマニュアルを参照すれば, 出力を少なくするオプションに関
する説明があります. RPM のバイナリ自体が改竄されていないことも確認すべ
きである点は忘れないでください.
この方法を使う場合には, 新しい RPM パッケージを追加するごとに RPM デー
タベースのバックアップを取らなければなりません. この方法を使うかどうか
は利点と欠点を考え合わせて決めてください.
8.4. システムログの監視
syslog から得られる情報が改竄されないようにするのはとても重要です. ま
ず, /var/log を特定のユーザしか読み書きできないようにしておきましょう.
ログに出力されていること, 特に auth の項目には目を通しましょう. 例えば
ログイン失敗が続いていると, これは侵入の試みの痕跡かもしれません.
ログがどこにあるかは ディストリビューションによって異なります. Red Hat
のように "Linux Filesystem Standard" に準拠しているシステムであれば,
/var/log に messages ファイルや mail.log 等があるはずです.
自分が使っているディストリビューションがどこにログを出力しているのか
は, /etc/syslog.conf ファイルを見ればわかります. これは syslogd (シス
テムのログを取るためのデーモン)に, メッセージの出力の仕方を指示する
ファイルです.
ログが長くなり過ぎないようにし, 検査もしやすくするために, ログをロー
テートさせるスクリプトやデーモンを設定することもできます. 最近の Red
Hat ディストリビューションでは logrotate パッケージを調べてみましょう.
他のディストリビューションにも同様の仕組みがあるはずです.
ログファイルが改竄されてしまっても, いつ, どんな種類の改竄が行われたの
かを調べましょう. 長期間記録されていない項目はありませんか? (もしある
ならば)バックアップのテープで, 改竄されていないログをチェックすること
もできます.
侵入の痕跡を消すため, 侵入者は一般的にログファイルを改竄しますが, それ
でも思わぬところでチェックに引っかかることもあります. 入口を見つけよ
うとしていたり, root 権限を得るためプログラムを不正使用しようとしてい
る侵入者に気づくかもしれません. 侵入者がログを改竄するより前に, ログ
を見ましょう.
su によるユーザ変更やログインの試み等のユーザアカウント情報を含む auth
の項目は, 他のログから分離すべきでしょう.
可能ならば, 重要なデータのコピーを安全なシステムに送るように syslog を
設定しましょう. これにより, login/su/ftp 等の記録を消して侵入者が足跡
を消してしまうことを防げます. syslog.conf のオンラインマニュアルの @
オプションを参照してください.
高機能版の syslogd がいくつかあります. 例えば http://www.core-
sdi.com/ssyslog/ にある Secure Syslog をご覧ください. Secure Syslog を
使うと syslog のエントリを暗号化して誰も改竄できないようにします.
別の高機能 syslogd としては syslog-ng があります. これを用いるとログ
の記録をより柔軟に行うことができ, またリモートの syslog のストリームを
改竄できないようにします.
最後になりますが, 誰も読んでいないようなログは役に立ちません. 適当に間
隔を取ってログを読み, いつもはどんな感じであるのかを感覚的に知っておき
ましょう. そうしておけば, 異常があった場合にすぐに見つけることができま
す.
8.5. システム更新パッケージの適用
ほとんどのユーザは Linux を CD-ROM からインストールします. しかし, セ
キュリティのためのシステム修正は速いペースで行われているので, 新しい (
修正済みの)プログラムが常にリリースされています. マシンをネットワーク
に接続する前には, お使いのディストリビューションの FTP サイトをチェッ
クし, インストールに使った CD-ROM より新しいパッケージを全て手に入れま
しょう. これらのパッケージにはセキュリティ関連の重要な修正が入っている
ことが多いので, これをインストールするのは良い考えです.
9. システムに侵入された場合や現在侵入されている場合の対応
本ドキュメント(あるいは他の)のアドバイスに従っていて, システムへの侵入
を発見した場合にはどうすべきでしょうか? まず最初にすべきことは, 平静を
保つことです. あわてて行動すると, 侵入者にやられるよりも悲惨なことにな
るかもしれません.
9.1. セキュリティが破られている最中
セキュリティが破られている最中であることに気づくと, 緊張する仕事を強い
られることになるでしょう. あなたがどのように対処するかは, 重大な意味を
持ちうるからです.
それが物理的な攻撃であるのなら, あなたは家や会社, 研究室に何者か侵入し
たことに気づいたということなのでしょう. まずは, このことをその場所の責
任者に知らせるべきです. 研究室ならば, 誰かがケースを開けようとしていた
り, マシンをリブートしようとしているのを見つけたのかもしれません. この
場合には, あなたの権限と職務手順に基づいて, 相手を止めるか警備員に連絡
することになるでしょう.
ローカルのユーザがセキュリティを破ろうとしているのを見つけた場合には,
まずは本当にその本人なのかどうか確認しましょう. その人がログインしてき
ている元のサイトを調べましょう. そのサイトはその人が普段ログインしてく
るところですか? 違うのならば, 非ネットワーク的な手段で連絡を取りましょ
う. 例えば, その人のオフィスや家に電話したり直接赴いてから話をするので
す. その人が自分がやったことを認めたら, 何をしようとしていたのか説明さ
せたり, それをやめるように伝えます. 何もしていないとか, 全く身に覚えが
無いと言われた場合には, この事件は更に調査が必要でしょう. 告発を行う前
には, まず事件を調べて多くの情報を集めましょう.
ネットワークでの攻撃を見つけた場合には, まずは(可能ならば)ネットワーク
への接続を切り離します. モデム接続ならばモデムケーブルを抜き, イーサ
ネット接続ならばイーサネットケーブルを抜きましょう. これにより, より
大きな被害を防ぐことができますし, 相手側にも発見に気づかせず, ネット
ワークの問題だと思わせることができるかもしれません.
ネットワーク接続を切り離せない場合(忙しいサイトや, マシンを物理的に操
作できない場合)には, 次善の策として, tcp_wrappers や ipfwadm のような
ツールを使って侵入者のサイトからのアクセスを拒否しましょう.
侵入者と同じサイトのユーザを全て拒否することができない場合は, ユーザア
カウントをロックすべきです. ユーザアカウントをロックするのは容易でな
いことには注意してください. .rhosts ファイル, FTP でのアクセス, 裏口
になり得るホストには気を付けてください.
以上の処置(ネットワークの切断, 攻撃者のサイトからのアクセス拒否, アカ
ウントの停止)の後は, これらのユーザのプロセスを全て止め, ログアウトさ
せます.
攻撃者は戻ってこようとするでしょうから, その後しばらくは自分のサイトを
監視すべきです. おそらく, 別のアカウントや別のネットワークアドレスを
使ってくるでしょう.
9.2. 既にセキュリティが破られてしまった場合
既にシステムに侵入されてしまったことに気づいた場合や, 侵入に気づいて (
願わくば)侵入者をシステムから追い出した場合にはどうすればいいでしょう
か?
9.2.1. セキュリティの穴を塞ぐ
攻撃者がシステムに侵入した方法を調べることができたら, 今度はその穴を塞
がなければなりません. 例えば, そのユーザがログインする直前にいくつか
FTP のエントリがあったとします. その場合には FTP のサービスを停止し,
新しいバージョンのサーバが出ていないか, あるいはセキュリティ関係のメー
リングリストに修正方法が投稿されていないかを調べましょう.
全てのログファイルを調べ, セキュリティ関係のメーリングリストやウェブ
ページを調べ, 修正可能な新しい一般的な弱点が出ていないか調べます.
Caldela のセキュリティ修正は http://www.caldera.com/tech-ref/security/
にあります. Red Hat はまだセキュリティ修正とバグ修正を分離していません
が, ディストリビューションの訂正は http://www.redhat.com/errata にあり
ます.
Debian にはセキュリティのためのメーリングリストと WWW ページがありま
す. 詳しくは http://www.debian.org/security/ を見てください.
あるベンダがセキュリティ更新パッケージをリリースしていれば, ほぼ確実に
他の Linux ベンダもセキュリティ更新パッケージを出しているでしょう.
現在はセキュリティ監査を行うプロジェクトがあります. このプロジェクト
は, ユーザ空間で動作するユーティリティを組織的に全て検査して, セキュリ
ティ的な弱点やオーバーフローの可能性がある部分を探す作業を行っていま
す. このプロジェクトによるアナウンスを以下に引用します:
「我々は Linux 関連のソースコードの組織的な監査を行って
OpenBSD と同じくらい安全にしようとしています. 我々は既にいく
つかの問題を明らかにして (そして修正して)いますが, まだまだ
助力が必要です. このメーリングリストは誰でも投稿できますし,
セキュリティ関連の一般的な議論にも役立つリソースです. この
メーリングリストのアドレスは security-audit@fer-
ret.lmh.ox.ac.uk です. 購読するには security-audit-sub-
scribe@ferret.lmh.ox.ac.uk 宛に空メールを送ってください」
攻撃者を締め出さなければ, 彼らはまた戻ってくるでしょう. あなたのマシン
に戻ってくるだけでなく, 同じ LAN にある他のマシンにも来るかもしれませ
ん. 彼らがパケット盗聴プログラムを実行していたら, 大抵, 他のマシンにも
アクセスできるようになっていることでしょう.
9.2.2. 被害の見積り
まず被害の見積りを行います. 何が壊されたのでしょうか? Tripwire のよう
なシステムの完全性をチェックするプログラムを実行していれば, なにがやら
れたのか調べる助けとなるはずです. さもなくば, 重要なデータを全て個別
に確認しなければならないでしょう.
最近は Linux のシステムのインストールが簡単になったので, 設定ファイル
を保存しておいてからディスクをフォーマットし直し, 再インストール, ユー
ザのファイルと設定ファイルを書き戻すという手順を考えてみてもよいでしょ
う. こうすれば, 新しくてきれいなシステムであることを保証できます. 破
られたシステムからファイルのバックアップを行わなければならない場合は,
バイナリを書き戻す時には特に注意しましょう. 侵入者がトロイの木馬を置
いているかもしれないからです.
侵入者に root 権限を奪われた場合には, 再インストールも必須だと考えてく
ださい. 加えて, 証拠を残しておきたいと思うでしょうから, 予備のディスク
を金庫に保管しておくことも無駄ではないかもしれません.
その後は, どれだけ前にやられたのか, そして壊された成果はバックアップに
入っているのかどうかを心配しなければなりません. できるだけ新しいバック
アップを使いましょう.
9.2.3. バックアップ, バックアップ, バックアップ!
セキュリティの問題において, 定期的なバックアップは大変貴重なものです.
システムが破壊された場合, 必要なデータをバックアップから書き戻すことが
できます. もちろん攻撃者にとって価値のあるデータもありますから, 彼らは
データを破壊するだけでなく, 盗んでしまうかもしれません. それでも最低限
こちら側にデータだけは残ります.
改竄されたファイルをバックアップから書き戻す前には, 過去に亙って複数の
バックアップを必ず調べましょう. 侵入者がずっと前からファイルを壊して
いるかもしれないし, 壊されたファイルの正しいバックアップを取っているか
もしれません!
もちろん, バックアップにまつわるセキュリティの問題もたくさんあります.
バックアップは安全な場所に保管しましょう. 誰がバックアップに触れるのか
を知っておきましょう. (もし攻撃者がバックアップを手に入れてしまったら,
知らないうちにあなたの持つ全てのデータにアクセスされてしまいます. )
9.2.4. 侵入者を突き止める
さて, 侵入者を締め出して, システムを復旧させましたが, まだ全ては終わっ
ていません. 侵入者が捕まることはまずありませんが, 攻撃を受けたことは報
告しておくべきです.
あなたのシステムに攻撃を行った攻撃者のサイトの管理者の連絡先に, 攻撃を
受けたことを報告しましょう. この連絡先は whois コマンドか, InterNIC の
データベースで調べることができます. 適切なログのエントリと日時を相手
にメールで送りましょう. 他にもわかっている侵入者の特徴があれば, それ
も知らせましょう. メールを送った後に (気になるなら) 電話をすべきです.
その管理者があなたのサイトへの攻撃者に気づいたら, 今度はこの管理者が,
攻撃者がやってきているサイトの管理者に話ができるかもしれません.
腕の立つクラッカーは, クラックしたシステムを間にいくつか挟んで攻撃して
くることがよくあります. その経路には自分達がシステムを破られたことさえ
知らないサイトも(たくさん)あります. ですから, クラッカーの本拠地を追跡
して突き止めることは困難です. 話をした管理者が役に立たなくても, その辺
りの配慮をしてあげましょう.
また, 自分が所属しているセキュリティ関連団体(CERT
等)や, お使いの Linux システムのベンダにも報告
すべきです.
10. セキュリティ関係の情報源
UNIX 一般のセキュリティと Linux 特定のセキュリティのいずれについても,
良いサイトがたくさんあります. セキュリティに関するメーリングリストを 1
つ(あるいはそれ以上)購読し, セキュリティに関する修正を常に最新の状態に
しておくことが重要です. 以下に挙げるリストは量こそ少ないですが, とても
有益なものです.
10.1. FTP サイト
CERT は Computer Emergency Response Team の略です. CERT は最新の攻撃や
その対処についての警告を発行しています. 詳しくは cert.org を見てくださ
い.
ZEDZ (元は Replay と呼ばれていました) (http://www.zedz.net) にはセキュ
リティ関連プログラムの大きなアーカイブがあります. このサイトはアメリ
カ合衆国国内にはありませんので, アメリカの馬鹿げた暗号規制に従う必要は
ありません.
Matt Blaze 氏は CFS の作者であり, セキュリティの大家です. Matt 氏の
アーカイブが ftp://ftp.research.att.com/pub/mab
にあります.
tue.nl はオランダにある大きなセキュリティ関係 FTP サイトです.
ftp.win.tue.nl
10.2. ウェブサイト
o The Hacker FAQ はハッカーに関する FAQ です: The Hacker FAQ
o COAST アーカイブには UNIX のセキュリティ関連プログラムと情報がたく
さんあります: COAST
o SuSe によるセキュリティのページ: http://www.suse.de/security/
o Rootshell.com はシステムの問題を知るのに大変役立つサイトで, 現在は
クラッカーにも使われています: http://www.rootshell.com/
o BUGTRAQ はセキュリティに関する勧告を発行しています: BUGTRAQ
archives
o CERT (the Computer Emergency Response Team) は UNIX に対する一般的
な攻撃に関する勧告を発行しています: CERT のホームページ
訳注: 日本では JPCERT (コンピュータ緊急対応センター) が活動していま
す.
o Dan Farmer 氏は SATAN 等のセキュリティ関連ツールの作者です. 氏の
ホームページにはセキュリティに関する興味深い調査結果やセキュリティ
関連ツールがあります: Dan Farmers trouble.org
o The linux security WWW は Linux のセキュリティ情報を調べるのに便利
なサイトです: Linux Security WWW
o Infilsec には特定のプラットフォームのセキュリティ的な弱点を調べるこ
とができる検索エンジン(vulnerability engine)があります:
http://www.infilsec.com/vulnerabilities/
o CIAC は一般的な問題について定期的にセキュリティ bulitin を送ってく
れます: http://ciac.llnl.gov/cgi-bin/index/bulletins
o Linux Pluggable Authentication Modules(差し替え可能な認証モジュー
ル)の良い入門が http://www.kernel.org/pub/linux/libs/pam/ にありま
す.
o Debian プロジェクトにはセキュリティ関係の修正パッケージと情報を載せ
た WWW ページがあります (http://www.debian.org/security/).
o WWW Security FAQ: これは Lincoln Stein 氏が書かれた文書で, WWW のセ
キュリティに関する素晴らしい参考文献です.
http://www.w3.org/Security/Faq/www-security-faq.html をご覧くださ
い.
10.3. メーリングリスト
Bugtraq: Bugtraq を購読するには, listserv@netspace.org 宛に本文が
subscribe bugtraq
(メーリングリストのアーカイブについては, 前述のリンクを参照してくださ
い)
CIAC: majordomo@tholia.llnl.gov 宛に, 本文(サブジェクトではありません)
が
subscribe ciac-bulletin
Red Hat はたくさんのメーリングリストを運営していますが, その中でも特に
重要なのが redhat-announce メーリングリストです. セキュリティ (や, そ
の他) の修正パッケージに関する情報が出るとすぐにここに投稿されます.
Subject が
Subscribe
redhat-announce-list-request@redhat.com 宛に送ってください. より詳し
い情報や記事のアーカイブについては http://www.redhat.com/mailing-
lists/redhat-announce-list/ をご覧ください.
Debian プロジェクトもセキュリティ更新パッケージを扱うメーリングリスト
を運営しています. 詳しくは http://www.debian.org/security/ をご覧くだ
さい.
10.4. 書籍
セキュリティ関係の良書はたくさんあります. この章ではその一部を紹介しま
す. セキュリティ専門の本に加え, システム管理の本の多くでもセキュリティ
の話題を扱っています.
訳注: これらの本の和訳があればぜひお知らせください.
Building Internet Firewalls By D. Brent Chapman & Elizabeth D. Zwicky
1st Edition September 1995
ISBN: 1-56592-124-0
訳注: 和訳は
歌代和正監訳「ファイアウォールの構築 〜インターネットセキュリティ〜」
株式会社オライリージャパン, 1996
ISBN: 4-900900-03-6
紹介ページ: http://www.oreilly.co.jp/BOOK/firewall/
です.
Practical UNIX & Internet Security, 2nd Edition By Simson Garfinkel &
Gene Spafford
2nd Edition April 1996
ISBN: 1-56592-148-8
訳注: 和訳は
山口英監訳「UNIX & インターネットセキュリティ」
株式会社オライリージャパン, 1998
ISBN: 4-900900-38-9
紹介ページ: http://www.oreilly.co.jp/BOOK/puis/
です.
Computer Security Basics By Deborah Russell & G.T. Gangemi, Sr.
1st Edition July 1991
ISBN: 0-937175-71-4
Linux Network Administrator's Guide By Olaf Kirch
1st Edition January 1995
ISBN: 1-56592-087-2
PGP: Pretty Good Privacy By Simson Garfinkel
1st Edition December 1994
ISBN: 1-56592-098-8
訳注: 和訳は
山本和彦監訳「PGP 暗号メールと電子署名」
株式会社オライリージャパン, 1996
ISBN: 4-900900-02-8
です.
Computer Crime A Crimefighter's Handbook By David Icove, Karl Seger &
William VonStorch (Consulting Editor Eugene H. Spafford)
1st Edition August 1995
ISBN: 1-56592-086-4
Linux Security By John S. Flowers
New Riders;
ISBN: 0735700354
March 1999
Maximum Linux Security : A Hacker's Guide to Protecting Your Linux
Server and Network
Anonymous
Paperback - 829 pages
Sams;
ISBN: 0672313413
July 1999
訳注: 和訳は
トップスタジオ訳「Linux版 クラッカー迎撃完全ガイド」
株式会社インプレス, 2000
ISBN: 4844313606
です.
Intrusion Detection By Terry Escamilla
Paperback - 416 pages (September 1998)
John Wiley and Sons;
ISBN: 0471290009
Fighting Computer Crime
Donn Parker
Paperback - 526 pages (September 1998)
John Wiley and Sons;
ISBN: 0471163783
11. 用語解説
o 認証(authentication): 受け取ったデータが送られたものと同じかどうか
調べる過程や, データの送り主が本当に実際に本人であるかどうかを確認
すること.
o 要塞ホスト(bastion host):通常はインターネットに接続したり, 内部ネッ
トワークでユーザがアクセスする中心ホスト. 何も備えがないシステムは
攻撃に対して脆弱であるため, 高度に安全にしなければならない. この名
前は中世の城砦の外壁の高度な防御工事に由来する. 要塞の監督は守備の
要であり, 通常は頑丈な壁があり, 騎兵隊の詰所があり, 攻撃者を撃退す
るための油や熱湯を入れる桶がある.
o バッファオーバーフロー(buffer overflow): 通常のプログラムの書き方で
は, 「十分長いバッファ」を確保されず, バッファのオーバーフローの
チェックも行われないことがある. このようなバッファがオーバーフロー
すると, プログラム(デーモンや setuid されたプログラム)を動作中に他
の目的に悪用することが可能である. 一般的に, これはスタック上の関数
の戻り先を他の場所に上書きすることで行われる.
o サービス妨害攻撃(denial of service): サービス妨害攻撃は, 攻撃者が本
来の目的とは異なる使い方でコンピュータの資源を食い潰し, 通常のネッ
トワーク資源の利用を妨害する攻撃である.
o dual-homed host: 少なくとも 2 つのネットワークインタフェースを持つ,
汎用のコンピュータシステム.
o 防火壁(firewall): 保護されたネットワークとインターネット間, あるい
は異なるネットワーク同士の間のアクセスを制限するコンポーネントある
いはコンポーネントの集合.
o ホスト(host): ネットワークに接続されたコンピュータ
o IP 詐称(IP spoofing): IP 詐称は複数の要素からなる, 技術的に複雑な攻
撃である. 信頼関係に基づく計算機の利用をぺてんにかけ, あなたは本当
にあなたなのか? という疑心暗鬼に追い込むというセキュリティ攻撃とな
る. daemon9, route, infinity によって書かれた詳しいペーパーが
Phrack Magazine の 第 7 巻, 第 48 号にある.
o 否認防止性(non-repudiation): 送り主がデータを送ったことを後から否定
しようとしても, その送り主が実際にデータを送ったことをデータを受け
取った側が証明できるという性質.
o パケット(packet): インターネットにおける通信の基本単位.
o パケットフィルタリング(packet filtering:) ネットワークを出入りする
データの流れを選択的に制御すること. パケットフィルタは, 通常は外部
ネットワークとの間のルーティングの時に, パケットの通行を許可あるい
は禁止する(普通はインターネットと内部ネットワークの間). パケット
フィルタリングを行うためには, 許可または禁止するパケットの種類(特定
の IP あるいはポートで指定)を指定するルールを設定する必要がある.
o 境界ネットワーク(perimeter network): セキュリティの層を追加するため
に, 保護されたネットワークと外部ネットワークとの間に作るネットワー
ク. 境界ネットワークは非武装地帯(DMZ, demilitarized zone)と呼ばれる
こともある.
o 代理サーバ(proxy server): 内部クライアントに外部サーバへアクセスさ
せるためのプログラム. クライアントは代理サーバにアクセスし, 代理
サーバは, クライアントの許可したリクエストを実際のサーバに中継し,
その応答をクライアントに中継する.
o ユーパーユーザ(superuser): root の通称.
12. よくある質問
1. ドライバをカーネルに直接組み込むのと, モジュールとして作成するので
は, どちらが安全でしょうか?
回答: モジュールを用いたデバイスドライバのロード機能は無効にしてお
く方が良いという意見の人もいます. というのも, 侵入者がトロイの木馬
を仕込んだモジュールやシステムのセキュリティに影響を与えるモジュー
ルをロードするかもしれないからです.
しかし, モジュールを読み込むためには root にならなくてはなりません.
モジュールのオブジェクトファイルを書き換えることができるのも root
だけです. つまり, 侵入者がモジュールを組み込むためには, root 権限が
必要です. 逆に侵入者が root 権限を得てしまったら, モジュールをロー
ドするかどうかということよりも, もっと深刻な事態になります.
モジュールはあまり頻繁に使用しない特定デバイスを動的に読み込むため
の仕組みです. 例えばサーバマシンや防火壁などでは, こういうことはあ
まり起こりません. 従って, サーバとして動かすマシンでは, カーネルに
直接ドライバを組み込む方が良いでしょう. また, モジュールを使うと直
接カーネルに組み込む場合よりも動作が遅くなります.
2. リモートのマシンから root でログインできません.
回答: ``root のセキュリティ''の章を読みましょう. これはリモートの
ユーザが telnet で root としてログインしようとするのを防ぐため, わ
ざとそうしているのです. root として telnet でログインするのはセ
キュリティ的に非常に危険なことです. ルートのパスワードが平文のまま
(暗号化されずに) ネットワークに送出されてしまうでしょう. 侵入者に
なる可能性を持った人は常にあなたのそばにいて, パスワードを盗むため
のプログラムを自動的に動かしていることを忘れてはなりません.
3. Red Hat Linux 4.2, 5.x でシャドウパスワードを使うにはどうすれば良い
でしょう?
回答:
シャドウパスワードを有効にするには, root で pwconv を実行します.
/etc/shadow が存在し, アプリケーションがこれに対応していなければい
けません. Red Hat 4.2 以降をご利用なら, 他に変更することなく, PAM
モジュールが自動的に普通の /etc/passwd からシャドウパスワードへの移
行に追従してくれます.
背景説明: シャドウパスワードは, 標準の /etc/passwd ファイル以外の
ファイルにパスワードを格納する機構です. これにはいくつかの利点があ
ります. 最初の利点は, シャドウファイル /etc/shadow は誰でも読めなけ
ればならない /etc/passwd ファイルと異なり, root しか読み出せない点
です. 別の利点は, 管理者として, 他のユーザアカウントの状態を誰にも
知らせないまま, アカウントを有効または無効にできることです.
シャドウパスワードを使っていても, ユーザやグループ名の格納には
/etc/passwd ファイルが使われます. このファイルは, /bin/ls 等のプロ
グラムがディレクトリ表示の際にユーザ ID を適切なユーザ名に変換する
ために使います.
/etc/shadow ファイルには, ユーザ名とパスワードとアカウントの有効期
限などのアカウント情報だけが含まれています.
シャドウパスワードを有効にするためには, root になって pwconv コマン
ドを実行します. すると /etc/shadow ファイルが作られ, アプリケーショ
ンに使われるようになります. Red Hat 4.2 以降では, 通常の
/etc/passwd ファイルからシャドウパスワードへの変更への適合は PAM モ
ジュールが自動的に行います. 他の変更は全く必要ありません.
パスワードの安全を考えていれば, たぶんパスワードも最初から良いもの
を作ろうと思うでしょう. これを行うために PAM の一部である
`pam_cracklib' モジュールが利用できます. これはパスワードに対して
Crack ライブラリを適用し, パスワードクラッキングプログラムによって
簡単に推測されないかどうか調べることができます.
4. Apache の SSL 拡張はどうやって有効にするのですか?
回答:
a. バージョン 0.8.0 以降の SSLeay を
から入手します
b. これをコンパイル, テスト, そしてインストールします
c. Apache 1.2.5 のソースを入手します
ここ
から Apache SSLeay 拡張を入手します
d. これを Apache 1.2.5 のソースディレクトリで展開し, README に従っ
てパッチを当てます
e. 設定とコンパイルを行います
ZEDZ net から各種バイナリパッケージを入手することもできます. これ
はアメリカ国外にあります.
5. セキュリティを確保したままで, ユーザアカウントを処理するにはどうす
れば良いでしょう?
回答: Red Hat ディストリビューション, 特に Red Hat 5.0 には, ユーザ
アカウントの状態を変更するツールがたくさん入っています.
o シャドウパスワードと非シャドウパスワードを相互変換する pwconv と
unpwconv
o passwd ファイルと group ファイルの構成が正しいかどうか検査する
pwck と grpck
o ユーザアカウントの追加, 削除, 変更を行う useradd, usermod,
userdel. グループについて同様の作業を行うための groupadd,
gropumod, groupdel
o グループにパスワードを設定する gpasswd
これらのプログラムは全て「シャドウ対応」です. つまり, シャドウパス
ワードが有効であれば, /etc/shadow のパスワード情報を参照し, 有効で
なければこのファイルは参照しません.
詳しくは, それぞれのコマンドのオンラインマニュアルを参照してくださ
い.
6. Apache で特定の HTML をパスワードで保護するにはどうすればよいでしょ
うか?
http://www.apacheweek.org のことをご存じないでしょう?
ユーザ認証については, http://www.apacheweek.com/features/userauth
に情報がありますし, ウェブサーバに関するその他のヒントも
http://www.apache.org/docs/misc/security_tips.html にあります.
13. まとめ
セキュリティに関する警告が流れるメーリングリストを購読することと, 最新
のソフトウェアを使うことによって, セキュリティを大幅に向上させることが
できます. ログファイルに注意を払い, tripwire のようなプログラムを定期
的に実行すればもっと良いでしょう.
家庭のマシンを管理する分には, 十分なレベルのセキュリティも困難ではあり
ません. 仕事に使うマシンではかなり努力が必要でしょうが, Linux はかなり
安全なプラットフォームです. Linux の開発の特徴により, セキュリティ関連
の修正が商用の OS よりもずっと早いことが多々あり, このため Linux はセ
キュリティが必要な場合には理想的なプラットフォームになっています.
14. 謝辞
本ドキュメントの情報はいろいろな所から集めたものです. 直接・間接的に貢
献してくださった以下の方々に感謝します:
Rob Riggs さん rob@DevilsThumb.com
S. Coffin さん scoffin@netcom.com
Viktor Przebinda さん viktor@CRYSTAL.MATH.ou.edu
Roelof Osinga さん roelof@eboa.com
Kyle Hasselbacher さん kyle@carefree.quux.soltc.net
David S. Jackson さん dsj@dsj.net
Todd G. Ruskell さん ruskell@boulder.nist.gov
Rogier Wolff さん R.E.Wolff@BitWizard.nl
Antonomasia さん ant@notatla.demon.co.uk
Nic Bellamy さん sky@wibble.net
Eric Hanchrow さん offby1@blarg.net
Robert J. Berger さんrberger@ibd.com
Ulrich Alpers さん lurchi@cdrom.uni-stuttgart.de
David Noha さん dave@c-c-s.com
Pavel Epifanov さん epv@ibm.net
Joe Germuska さん joe@germuska.com
Franklin S. Werren さん fswerren@bagpipes.net
Paul Rusty Russell さん
Christine Gaunt さん
lin さん bhewitt@refmntutl01.afsc.noaa.gov
A. Steinmetz さん astmail@yahoo.com
森本 淳さん
Xiaotian Sun さん sunx@newton.me.berkeley.edu
Eric Hanchrow さん offby1@blarg.net
以下の方々はこの HOWTO を色々な言葉に翻訳してくださいました!
Linux の言葉を広める手伝いをしてくださる全ての方々に深く感謝します.
ポーランド語: Ziemek Borowski さん ziembor@FAQ-bot.ZiemBor.Waw.PL
日本語: 藤原輝嘉 fjwr@mtj.biglobe.ne.jp
インドネシア語: Tedi Heriyanto さん 22941219@students.ukdw.ac.id
韓国語: Bume Chang さん Boxcar0001@aol.com
スペイン語: Juan Carlos Fernandez さん piwiman@visionnetware.com
オランダ語: R. Ekkebus さん reggy@zeelandnet.nl
一覧に戻る
グリーンネット・トップページへ戻る
|
