システムをネットワークに繋ぐ前に少し準備と計画を行うだけで, システムとその中のデータを守るのに役立つでしょう.
/etc/fstab で nosuid オプションを使いましょう.
また, ユーザのホームパーティションや /var
では nodev や noexec を使おうと考えるかもしれません.
これらのオプションはプログラムの実行や,
キャラクタデバイス・ブロックデバイスの作成を禁止します.
これらはいずれにせよ必要無いはずです. /etc/exports でできる限り厳しいアクセス制限を行ってください.
これはワイルドカードを使わないこと,
root での書き込みアクセスを許可しないこと,
できる限り読み取り専用でエクスポートするということです.umask をできる限り厳しく設定してください.
umask の設定 をご覧ください. unlimited を認めるのではなく,
ファイルシステムに制限値を設定しましょう.
リソース制限を行う PAM モジュールと
/etc/pam.d/limits.conf を使って,
ユーザ別に制御することができます.
例えば, グループ users の制限は以下のようになります:
@users hard core 0
@users hard nproc 50
@users hard rss 5000
この設定は, コアファイルの作成を禁止し, プロセスの数を 50 に制限し, メモリの使用量をユーザ 1 人あたり 5MB に制限するものです.
/var/log/wtmp, /var/run/utmp ファイルには,
システムの全てのユーザのログイン記録が記録されています.
このファイルは絶対いじられないようにしなくてはなりません.
というのも, このファイルを使ってユーザ (あるいは侵入者である可能性がある人)
がいつ, どこからシステムに入ったのかを知ることができるからです.
このファイルのパーミッションは 644 にすべきです.
この設定は通常のシステム操作に影響を与えません.
/etc/passwd や
/etc/shadow の削除を含む攻撃の手段となってきました).
immutable ビットの情報については,
オンラインマニュアルの chattr(1) を参照してください.
システム上の SUID/SGID されたプログラムを全て見つけ, それらがどうなっているかを監視します. 侵入者の可能性を示すこれらのファイルの変化に注意してください. システム上の SUID/SGID されたプログラムを全て見つけるには 以下のコマンドを使います:
root# find / -type f \( -perm -04000 -o -perm -02000 \)
Debian ディストリビューションは,
SUID されたファイルが存在するかどうかを調べるジョブを毎晩実行します.
そして, これを昨晩の実行結果と比較します.
このログは /var/log/setuid* で参照できます.
怪しいプログラムは chmod を使って
SUID や SGID のパーミッションを取り除くことができます.
どうしても必要だと思った時にはパーミッションを戻すこともできます.
root# find / -perm -2 ! -type l -ls
/dev のいくつかのファイルやシンボリックリンク等を含めて,
誰でも書き込めるファイルがいくつかあります.
したがって, ! -type l を用いて,
先の find コマンドの結果からこれらを取り除いてください.
所有者のいないファイルも侵入者がシステムにアクセスした可能性を示します. 所有者がいないファイルや, どのグループにも属していないファイルは, 以下のコマンドで見つけることができます:
root# find / -nouser -o -nogroup -print
.rhosts ファイルを見つけることも,
システム管理者の日常業務の一部です.
このファイルをシステムに設置するのは許可すべきでないからです.
クラッカーがネットワーク全体にアクセスする可能性を得るためには,
安全でないアカウントが 1 つだけあれば良いということを忘れないでください.
システム上の全ての .rhosts
ファイルは以下のコマンドで見つけることができます:
root# find /home -name .rhosts -print
最後になりますが, システムファイルのパーミッションの変更は, しようとしていることを必ず理解してからにしてください. 何かを動かすための楽な方法だからといって, ファイルのパーミッションを変えてはいけません. パーミッションを変える前には, ファイルのパーミッションがそうなっている理由を必ず理解してください.
umask コマンドを使って,
システムのデフォルトのファイル生成モードを決めることができます.
umask 値は設定したいファイルモードの 8 進数での補数になります.
パーミッションに関する指定を何も行わずにファイルを生成すると,
パーミッションを与えるべきでない何者かに対して
読み書きのパーミッションを意図せずに与えてしまうかもしれません.
通常は umask 値の設定は 022, 027, 077
です. 077 は最も厳しい設定です. 通常は umask 値は
/etc/profile で設定され, システムの全ユーザに適用されます.
ファイル生成マスクは,
777 から希望の値を引き算することによって計算することができます.
言い換えると, umask 値が 777 であれば,
新しく生成されるファイルは誰に対しても
読み書きと実行のパーミッションを持ちません. マスクが
666 ならば, 新しく生成されるファイルのモードは 111 となります.
例えば, 以下のような行を設定できます:
# Set the user's default umask
umask 033
077 にしてください.
こうしておくと, chmod を使って明示的に変えない限り,
他のユーザの読み書きと実行は無効になります.
umask 値に 033 を設定した場合には, 新しく生成されるディレクトリのパーミッションは 744 になります.
この値は 777 から 033 を引いて得られたものです.
umask 値 033 を用いて新しく生成されるファイルはパーミッション 644 を持ちます.
Red Hat を使っており, Red Hat のユーザ ID, グループ ID の作成方法
(User Private Groups) に従う場合, umask には 002
だけ設定していれば十分です.
その理由は, デフォルトの設定で 1 グループに 1 ユーザしかいないためです.
システム管理を行うべきでないユーザやグループの権限では システムファイルを変更できないようにしておくのは重要なことです.
UNIX は ファイルとディレクトリのアクセス制御を 3 つの特性 (所有者, グループ, 全員)に分離しています. 常に一人だけを指す所有者, 任意の人数を指せるグループ, そしてそれ以外の全員です.
以下で UNIX のパーミッションを簡単に説明します:
所有権 (ownership) - あるノードやその親ノードのパーミッション設定をどのユーザ, グループが行うことができるのかを示します.
パーミッション(permissions) - ファイルに対して行うことができる アクセスの種類を決めるビット列. 組合せが同じでも, ディレクトリのパーミッションは ファイルのパーミッションとは意味が異なることがあります.
読み出し(read):
書き込み(write):
実行(execute):
ディレクトリに適用する場合,
「sticky ビット」の意味はファイルに適用する場合と異なります.
sticky ビットがディレクトリに設定されている場合に削除できるファイルは,
そのディレクトリへの書き込み権限があったとしても,
自分が所有しているファイルか
明示的に書き込み許可が与えられているファイルだけです.
このビットは /tmp のようなディレクトリのために用意されたものです.
このようなディレクトリは誰でも書き込みはできますが,
誰でも自由にファイル消去を認めるのは望ましくありません.
ディレクトリを詳細表示すると, sticky ビットは t で表されます.
これはファイルへの SUID パーミッションを示します. ユーザ ID 設定アクセスモードが所有者のパーミッションで設定されており, かつそのファイルが実行可能であれば, これを実行したプロセスは, プロセスを起動したユーザではなく, ファイルを所有しているユーザに基づいてシステムのリソースにアクセスできます. これは各種 'buffer overflow' 攻撃の原因となります.
グループのパーミッションで設定されていれば, このビットはファイルの「グループ ID 設定」状態を制御します. これは SUID と同じように動作しますが, ユーザではなくグループが影響を受ける点が異なります. このビットに効果を持たせるためには, やはりファイルは実行可能でなければいけません.
(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 されたシェルスクリプトはセキュリティに重大な危険を及ぼすので, カーネルはこれを無視します. そのシェルスクリプトがどれだけ安全だと思っていても, クラッカーに root のシェルを奪われてしまう可能性があります.
ローカルからの (そしてネットワークからの)
システムに対する攻撃を発見する別の良い方法は,
Tripwire, Aide, Osiris
のような, システムがいじられていないかどうかをチェックする
プログラムを実行することです.
これらは重要なバイナリや設定ファイル全てのチェックサムを取り,
参照値として正しいことが分かっている以前の値のデータベースと比較します.
したがって, これらのファイルの変更は全て知ることができます.
この手のプログラムをフロッピーディスクにインストールし, このフロッピーを物理的に書き込み禁止にしておくとよいでしょう. こうしておけば, 侵入者にはシステム整合性チェックプログラムや データベースを改竄することが不可能になります. いったんこの手のものを設定したら, これを通常のセキュリティ管理作業の一部として実行し, 何か変更がなされていないかチェックするとよいでしょう.
毎晩 フロッピーディスク上のチェックプログラムを実行し,
朝にその結果をメールで送るように crontab を設定することもできます.
設定は以下のようになります.
# set mailto
MAILTO=kevin
# run Tripwire
15 05 * * * root /usr/local/adm/tcheck/tripwire
整合性チェックプログラムは, いざとなってから気づくより前に侵入者を発見する天の配剤になり得ます. 一般的なシステムでは多くのファイルが変更されますので, クラッカーの動きや, 自分自身が行ったことに注意していなくてはなりませんから.
Tripwire のオープンソースなバージョンは
http://www.tripwiresecurity.comにあります. 無料です.
マニュアルとサポートは有料で入手することができます.
Aide は
http://www.cs.tut.fi/~rammer/aide.html にあります.
Osiris は
http://www.shmoo.com/osiris/
からどうぞ.
「トロイの木馬 (Trojan Horse)」はホメーロスのイーリアスに書かれている 有名な計略に由来する名前です. 基本的な考え方は, 便利そうなプログラムやバイナリを用意しておき, これを他人にダウンロードさせて root ユーザとして実行させるというものです. これによって, 相手が気づかないうちにシステムを悪用することができます. 手に入れたバイナリが仕事をしている (とても役立っているかもしれません) と思っている間に, このバイナリが同時にセキュリティも破ってしまうのです.
したがって, マシンにプログラムをインストールする時には注意が必要です. Red Hat は MD5 チェックサムと PGP 署名を施した RPM ファイルを提供し, ユーザが本物のパッケージを入手しているのかどうかを チェックできるようにしています. 他のディストリビューションにも同様の仕組みがあります. 素性が知れず, ソースも提供されていないバイナリを root 権限で実行してはいけません! 誰もが調査できるようなソースコードを公開する攻撃者はほとんどいません.
手間はかかるかもしれませんが, プログラムのソースコードはその正式の公開サイトから入手するべきです. プログラムを root 権限で実行するならば, あなたか, あなたが信頼している人がソースコードを見て, 検査すべきです.
現在用いられているセキュリティ機能のうち最も重要なもののひとつが
パスワードです. あなたとあなたのマシンのユーザの両方が,
パスワードを安全で推測しにくいものにしておくことが大事です.
最近の Linux ディストリビューションのほとんどには,
簡単に推測できるパスワードは設定できないようになっている
passwd プログラムが入っています. passwd
プログラムが最新のもので,
このような機能を持っているかどうか確かめておきましょう.
暗号化についての突っ込んだ議論は本書の範囲を越えてしまいますが, 入門程度ならば良いでしょう. 暗号化は大変便利ですし, たぶん今日では必須とさえ言えるでしょう. 非常に多くの種類のデータ暗号化の方法がありますが, それぞれが特徴を持っています.
ほとんどの UNIX(Linux も例外ではありません)は, DES (Data Encryption Standard)
と呼ばれる片方向の暗号化アルゴリズムを主に使ってパスワードを暗号化しています.
暗号化されたパスワードは(普通)/etc/passwd
か (少し一般的でないですが) /etc/shadow に保存されます.
ユーザがログインしようとすると, 入力したパスワードは再び暗号化され,
パスワードを格納しているファイルの該当項目と比較されます.
これらが一致すればパスワードは同じはずなので, ログインが許可されます.
DES は双方向の暗号化アルゴリズム
(正しいキーを与えれば, 暗号化も復号化もできる)なのですが,
ほとんどの UNIX が使っているのは DES の一種で片方向のアルゴリズムです.
つまり, /etc/passwd (または /etc/shadow)
の内容からパスワードを得るために暗号を解読することは不可能なはずです.
パスワードが十分にランダムでない場合, "Crack" や "John the Ripper" ( crack 章を参照)のような力任せの攻撃でもパスワードを推測できます. PAM モジュール (後述) を利用すれば, 別の暗号化ルーチン (MD5 など) を使用できます. Crack にも良い使い方があります. パスワードデータベースに対して定期的に Crack を実行し, 安全でないパスワードを見つけるのです. そして問題のあるユーザと話をして, パスワードを変えるように指導します.
良いパスワードの決め方に関する情報については http://consult.cern.ch/writeup/security/security_3.html を参照してください.
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/) をご覧ください.
訳注 (略語の意味):
暗号に関する詳しい情報は RSA cryptography FAQ に書かれています. これは http://www.rsa.com/rsalabs/newfaq/ から入手できます. このドキュメントには "Diffie-Hellman 法", "公開鍵暗号", "電子認証" といった用語に関する情報が載っています.
訳注: 日本語訳は http://www.rsa-japan.co.jp/faq/index.html にあります.
ユーザは各種セキュリティと暗号化プロトコルの違いや, これらの使い方についてよく質問してきます. このドキュメントは暗号化に関するものではないのですが, 各プロトコルの内容を簡単に説明し, 情報のありかを紹介しておくのも悪くないと思います.
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 Network, VPN) ができます. これは, 安全でないインターネットで接続された異なる複数のサイトを含んでいても, 実質的にプライベートなネットワークです」とのことです.
これは http://www.xs4all.nl/~freeswan/ で入手することができます. このドキュメントの執筆中にちょうどバージョン 1.0 になりました. 他の形式の暗号と同様に輸出が制限されているため, デフォルトではカーネルと共に配布されていません.
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 を見てください.
最近のバージョンの Red Hat Linux ディストリビューションでは, "PAM" と呼ばれる統一された認証方法が使われています. PAM を使うと, システムを動作させたままで 認証の方法や要件を変更することとローカルの認証方法をカプセル化することが 可能になります. バイナリは一切再コンパイルする必要がありません. PAM の設定は本書の範囲を越えますが, 必ず PAM のウェブサイトを見て, 詳しい情報を見ておいてください. http://www.kernel.org/pub/linux/libs/pam/index.html
PAM で可能になることをほんの少しだけ列挙します.
システムのインストールと設定を行う数時間の間に,
実際に攻撃を受ける前に多くの攻撃を予防しておくことができます.
例えば PAM を使うと, ホームディレクトリの
.rhosts ファイルの使用をシステム全体で無効にすることができます.
設定は /etc/pam.d/rlogin に以下のような行を追加します:
#
# Disable rsh/rlogin/rexec for users
#
login auth required pam_rhosts_auth.so no_rhosts
このソフトウェアの基本的な目的は, インターネットのような安全でないパケットネットワークを通る安全な (トラフィック解析, 偽メッセージ混入を含む盗聴に対して) サブネットワーク間接続を提供することです.
CIPE はデータをネットワークレベルで暗号化します. つまり, ネットワーク上のホスト間を転送されるパケットが暗号化されます. 暗号化エンジンはパケットを送受信するドライバの近くに配置されます.
CIPE は, 接続ごとにソケットレベルでデータを暗号化する SSH とは異なります. 異なるホスト上で実行されているプログラム間の論理的な接続が暗号化されます.
CIPE は仮想プライベートネットワーク (Virtual Private Network) を構築するために, トンネリングで使うことができます. 低レベルの暗号化には, アプリケーションソフトウェアを変更しなくても, VPN に接続している 2 つのネットワーク間で透過的に動作させることができるという利点があります.
CIPE のドキュメントからの要約です:
IPSEC 標準は, 暗号化された VPN を構築するため (他にもありますが) に使うことができるプロトコル群を定義しています. しかし, IPSEC はオプションがたくさんある比較的重くて複雑なプロトコル群で, プロトコル群の完全な実装はまだほとんど使われておらず, 一部の問題 (鍵管理など) はまだ完全には解決されていません. CIPE は比較的簡単なアプローチを取っており, CIPE においてパラメータ化できることの多く (実際に使う暗号化アルゴリズムの選択など)は, インストール時に選択したものに固定されます. これは柔軟さを制限しますが, 実装が簡単に (したがって, 効率的でデバッグもしやすく) なります.
詳しい情報は http://www.inka.de/~bigred/devel/cipe.html にあります.
他の暗号化と同様の輸出制限のため, CIPE はカーネルと一緒には配布されていません.
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 ほど使われているわけでもありません.
シャドウパスワードは, 暗号化されたパスワード情報を一般ユーザから隠す手法です.
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 にあります.
推測しにくいパスワードをつけることを 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 で入手できます.
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 は必ずしもファイルシステム全体で使う必要はありません. これもディレクトリツリーで使用することができます.
グラフィックディスプレイを安全にしておき, 攻撃者が入力したパスワードを奪ったり, 画面で見ているドキュメントや情報を読んだり, セキュリティホールを突いて 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
の項を参照のこと) を使うこともできます.
ssh には, ユーザが透過的に扱うことができる,
およびネットワーク上に暗号化されていないデータが流れない,
という 2 つの利点があります.
X のセキュリティについての詳しい情報については, オンラインマニュアルの
Xsecurity を参照してください. 安全な策としては,
コンソールにログインするときには xdm を使い,
リモートのサイトで X のプログラムを実行したいときは
ssh を使うことです.
SVGAlib を使うプログラムはビデオ関係のハードウェアを操作するため, 普通は root に setuid されます. これは非常に危険です. プログラムがクラッシュした場合, 普通はコンソールを元に戻すためマシンを再起動しなくてはならなくなってしまいます. このようなプログラムについては, 確実に信頼できること, あるいは少なくとも少しは信用できることを確かめてください. できれば, そもそも使わないのが良いでしょう.
Linux GGI プロジェクトは Linux のビデオインタフェースの問題について
ひとつの解を提案しようとする試みです.
GGI では Linux のカーネル内に少しビデオ関係のコードを入れ,
そうしてビデオへアクセスします.
つまり, GGI を使えばいつでもコンソールを正常な状態に戻すことができます.
また, secure attention key を使うことができ,
コンソールでトロイの木馬が入った
login プログラムを使われるのを防げます.
http://synergy.caltech.edu/~ggi/