« パンダのかわいい映像と思いきや | Main | 「よろしかったでしょうか」でよろしかったでしょうか? »
PowerBook G4 に Fedora Core 6 を入れて約一週間経ちました。この間、少しずつそのマシンを LAN サーバにすべく色々やりました。
この約一週間の間にやったことです。
次のことは今回はやらないことにしました。データのやりとりが暗号化されないからです。
次のことをやったら当初の予定クリアです。
金曜日に一日頑張ったんですけどできませんでした。道具が足りませんでした。
これらの中か幾つかピックアップしてみます。
以下の話の前提ですが、光回線のルータから内側は二つの LAN に分けています。これはルータが直接 LAN に参加するとルータのセキュリティが破られたときに LAN に侵入し放題になるからです。
そこでルータが参加する LAN には今構築中のサーバのみが参加します。そしてそのサーバは別なイーサネットの接続口を使って、もう一つの LAN にも参加します。そのもう一つの LAN が本当の LAN です。ここに普段使うマシンが参加します。その LAN をプライベートゾーン、ルータが参加する LAN をバッファーゾーンと僕は呼んでいます。
そして将来はドメインを取得してダイナミック DNS によって外部からアクセスできるようにします。その際に構築中のサーバへの外からのアクセスは SSH と STF のみにします。
取り付けたのは BUFFALO LPC-CB-CLGT です。このカードはギガビットイーサに対応しています。ビルトインのイーサネットへの口は 100Mbps ですからこれはバッファゾーン側にして、プライベートゾーン側は WAN を上回るスピードでないと WAN のスピードを活かしきれませんから 1Gbps でないとならなかったのです。
ギガビットの LAN カードは少ないながらも幾つかあります。どれも PPC の Fedora Core に取り付けた例は検索では見つかりませんでしたが Free BSD では対応が確認されているものが数個ありました。Free BSD で対応しているとしたらメーカー製の特別なデバイスドライバが要らないか、スペックが開発者に公開されているかのどちらかです。メーカー自身がサポートすることはなさそうなメーカですし。ということはどっちに転んでも Linux でも対応している公算が高いということです。
こうして I-O DATA ETG2-PCI と BUFFALO LPC-CB-CLGT に絞り込まれました。そしてそれぞれの仕様で Full-Duplex に対応していると明示してある BUFFALO LPC-CB-CLGT に決まりました。
もし一筋縄で使えないようだったら WAN 側に接触する LAN と保護された LAN との橋渡しにはなかなか使えるようになりません。だから Amazon で購入するときに少しお金を余分に払って一日で届くモードで買いました。そのときの在庫は一個だけでした。
金曜の夜に注文して土曜日の夕方には到着。箱から出して PowerBook G4 に取り付けたら当たり前のように認識されました。少し拍子抜けでした。PPC 版の Linux で最も苦労するのはハードウェア周りだと思っていたからです。
openssl を使って自分で証明局を作りました。それを使って web サーバ用、メールサーバ用、メール送信サーバ用の証明書を作りました。
ブラウザなどが暗号化された通信をするときに、サーバは証明書というものを持っています。これはそのサーバが本物であることを証明するものです。でもその証明書自体が偽物だったらしょうがないですよね。偽造された証明書を持って募金を街角で集めるようなものです。僕は街角の募金で証明書を見せられても信用しません。その証明書が信頼できるものであるとする根拠がないからです。つまり証明書には本物であるという証明が必要です。証明局というのはサーバの証明書が信頼できるものだと証明する機関のことです。その証明局も証明書を持っていています。それをブラウザは予め持っているのです。
サーバの証明書にはお墨付きを与えた証明局の情報が含まれています。ブラウザはその情報と自分が持っている証明局の証明書を付き合わせて、サーバの証明書が偽造されたものでないことを確認するのです。二つの全く異なる経路からの情報が合致すれば OK という考え方です。
今回は自分で作った証明局でサーバが本物であると証明するのですから、出来上がった証明書はオレオレ証明書です。「オレは本物だ。なぜならオレが本物だと言っているからだ。」という構造です。ですから一般には意味がありません。
なんでこんな無意味なものを作ったかというと、それは構築中のサーバに認証(ユーザ名とパスワード)も伴ってするアクセスを全て暗号化したいからです。その暗号化にはサーバの証明書が不可欠です。そして証明書には証明局が不可欠なのです。でも本当にブラウザに入っているような証明局に証明してもらうにはお金がかかります。自分と自分を信頼する人のみが使うネットワーク(プライベートゾーン)ですからお金を払ってする必要はありません。
それに少しだけ意味があります。それは僕が作った証明局に保証されたサーバであることを証明する証明書を持ったサーバでなければ、LAN 上に騙しで作られたサーバであると断定できるということです。
以前のサーバでは Courier-IMAP と qmail を使っていました。Courier-IMAP はなかなかよいのですが、受信箱でないフォルダは受信箱のサブフォルとして見えてしまいます。POP を使っているときや他の IMAP サーバでよくあるように受信箱と他のフォルダが並ばないのです。どうでもよいと言えばどうでもよいのですが、今後、仕事で IMAP サーバを構築するときにそれが嫌だと言うお客さんがいるかもしれないので別なものを試してみたくなりました。qmail は全く問題ないのですが、postfix も実際に使ってみたかったので乗り換えました。
今回の特徴は IMAP や SMTP をサポートしていないことです。もちろん dovecot や postfix 自体はサポートしていますが、IMAP や SMTP が使えるように設定しませんでした。もう一つの特徴は認証無しにメールを送信できないようにしたことです。
その代わり IMAPS と SMTPS-AUTH を設定しました。IMAPS は IMAP の暗号化版、SMTPS-AUTH は SMTP の暗号化版の SMTPS に認証による制約が付いたものです。どちらもユーザの認証が必要で、ユーザ名やパスワードが平文でネットワークを流れないように暗号化したというわけです。そして僕の場合、仕事でやり取りするメールの内容には守秘義務がある内容が多く含まれています。ですから内容も可能な限り暗号化される経路が望ましいのです。もちろんインターネット上をメールが飛び交うときは一般に暗号化されてないわけですが、そこは僕が制御できるものではないのでしかたがありません。
メールの内容を受信者以外からに対しては暗号化し、本当に僕が送ったものであることを保証するには PGP などを使う必要がありますが、これはサーバとは関係ないのでこの話の範囲外です。
これは黙っていても sshd が起動されればサポートされているのですが、デフォルトではパスワードによる認証になります。したがって推測や総当たりによるパスワード破りが可能です。ssh でパスワードが破られてログインされたらかなり危険です。
そこで openssl で個人を特定するためのパスフレーズ(パスワードみたいなもの)を確認するための秘密鍵のファイルと、そのパスフレーズを知っている人であることを秘密鍵を知らずに検証するための公開鍵の鍵ファイルを作成しておきます。ssh や sftp でログインするときはその秘密鍵ファイルを持っているマシンからパスフレーズを使ってチャレンジしないとログインできないようにしました。
先ほどの IMAPS や SMTPS-AUTH でも同じ危険があります。通信経路が暗号化されてサーバの正当性が証明されていたとしても、ユーザの正当性はパスワードに依存しています。パスワードが破られればおしまいです。このためポリシーから信用できないとしている WAN に接触している LAN に開かれたイーサネットのインターフェースからは接続できないようにしてあります。これに外部から接続したいときは ssh を利用してポートフォワードということをすればよいので WAN に接触している LAN からアクセスできる必要はないのです。
タイムサーバはマシンの時刻合わせをするときに正しい時刻を教えてくれるサーバです。Mac OS X でも time.asia.apple.com が標準のタイムサーバになっています。これに自前のサーバを用意しました。
時刻合わせは LAN を構築する上で重要です。ネットワーク絡みで何か問題が発生したときに複数のマシンのログを付き合わせて解析をする必要があるのですが、そのログの間で時刻がずれていると解析にとても苦労するからです。
これは今回のセットアップの目玉の一つです。
Thunderbird を僕も妻も使っていて十分学習させてあるのでジャンクメールはジャンクメールとほぼ確実に認識されるのですが、メールソフトを乗り換えたり、今までの設定を捨てて新たにセットアップしたときには精度が粗くなります。それに娘ちゃんが大きくなってメールを使い始めたときに自分でジャンクメールを制御できるかどうかも心配です。
娘ちゃんだけでなく妻や僕自身もうっかりミスが起きないとも限りません。セキュリティの最大の弱点は人だからです。Gmail のようにサーバ側で高精度な振り分けができればこういう弱点を補強することができます。とくにウィルスやマルウェアが付いているメール、フィッシングサイトへ誘導するメールへの対策は重要です。
更に、万が一ウィルスに感染したりマルウェアによってゾンビマシンになってしまった場合、その被害をメールによって外部に伝搬させないためにジャンクメールの送信も禁止すべきです。
SpamAssassin と ClamAV を使って postfix にフィルターを加えると、この送受信の双方でのジャンクメールのフィルタリングができるのです。
もちろん送信側はこれだけでは不十分です。何年も前から自前で SMTP エンジンを積んだウィルスやワームが出現しています。メールソフトに設定されている送信用のメールサーバにアクセスせずに自分でメールが送信できてしまうのです。これは iptables によるファイアーウォールで遮断しています。
Samba はいわゆる Windows の共有フォルダのためのものです。NFS は unix で昔からあるファイルの共有のためのものです。FTP はご存知ですよね。
これらには、SFTP や HTTPS 上の WebDAV にはない共通点があります。それは暗号化されていないというものです。特に NFS は認証すらありません。ですからこれらはかなり信頼ができる LAN でしか使ってはいけません。
もちろん LAN の利用者に攻撃者がいるとは普通思われません。特に家族のための LAN ですから家族が情報を盗み出したりすることもあまり考えられません。僕以外はそのスキルもありませんし。だからといって LAN が信用できるものと考えてはなりません。ウィルスに感染していたり、トロイの木馬によって外から操作されていたらどうでしょうか? どんなに LAN の利用者が信頼できる人であっても、そこに悪意のある第三者が紛れ込んでいることになります。
ですから他の防御が破られて LAN に悪意がある第三者が介入したも同然の状態になったとしても、パスワードや秘匿すべきデータが LAN を流れるときに暗号化されていれば安心なわけです。ですから暗号化されていないこれらの仕組みはサポートしないことにしました。
既に外から入ってくる方はルータからタイムサーバへの時刻の問い合わせを除いて全て遮断しています。内側のマシンから外への接続の応答やそれに関連したものは SMTP を除いて許しています。
しかし SMTP だけが遮断すべきポート(ネットワークの接続口)ではありません。万が一トロイの木馬に感染してもそのトロイの木馬が使用するポートが遮断されていれば直ちに問題にはなりませんし、スパイウェアがに感染しても、そのスパイウェアが使用するポートが遮断されていれば直ちに問題にはなりません。不必要なポートへの外部接続も遮断すべきです。
もし LAN の利用者が web の閲覧しかしないのであれば HTTP, HTTPS, FTP, RTSP などだけが許可されていれば十分でしょう。でもこれらはプロキシサーバを介すればよいので許可する必要はありません。iChat の場合はファイル転送などを使わずに純粋なチャットだけをするのであればプロキシサーバ経由でも十分です。
こういう LAN 利用者(主に自分)の利用形態を吟味し、本当に必要がある外部への接続だけを許可するようにするのがベストです。
ClamAV は直接はリアルタイムスキャンをサポートしていませんが、Linux などの一部の OS ではリアルタイムスキャンのエンジンに利用することができます。unix の一つである Mac OS X ではなく Linux を PowerBook G4 に導入した最大の理由はこれです。僕が試した範囲内で最も検出能力が高く、ウィルスやワームだけでなくスパイウェアにも対応するだけでなく、普通のウィルススキャナーが対応していないフィッシングにも対応している ClamAV を最大限に活かすことができるのです。
しかしながら SElinux という仕組みが運用されている Linux 上ではできないとの情報もあります。SElinux はプログラムやその実行者がアクセスできるリソースを細かく制御できる仕組みで、これによって Linux のセキュリティはかなり高まります。だからこれは諦めるかもしれません。
その SElinux ですが、Fedora Core 6 が用意している範囲では自分でポリシーを再構築するのが用意ではありません。準備されているポリシーのソースファイルが準備されていないのです。このせいで、ClamAV を利用した squid によるプロキシサーバの攻撃サイトフィルターがうまく構築できませんでした。squid が ClamAV の資源にアクセスできないのです。
ポリシーのソースファイルは Fedora Core 4 までしか提供されていません。ですから自分でポリシーを自由に制御するためには SElinux を Fedora Core 6 のパッケージで利用するのはやめて自分で構築しなければならないでしょう。
攻撃サイトフィルターも今回のセットアップの目玉の一つだったのですが、当面は諦めました。SElinux については後ほどじっくり研究するつもりだからです。攻撃サイトフィルターが整えば、CD-ROM や USB メモリなどの外部メディア、そしてノートパソコンが他の LAN に接続されたときに受信した内容以外は、かなりクリーンになります。
今のところ他の LAN にノートパソコンを繋ぐのは僕だけです。ですから僕にとっての脅威はお客さんやオフィスの LAN、そしてホテルや実家の LAN なのです。