PAMという語からカナダの某ブロンド女優を連想する人もいるかもしれないが、このサイトの読者ならLinuxセキュリティの基本的な要素であるPluggable Authentication Modulesだとわかるはずだ。本稿では、こちらのPAMのしくみを説明し、ちょっとした使用例を紹介する。 もしLinuxのアプリケーションごとに独自の認証ロジックを用意しないといけないとしたら、大変なことになっていたはずだ。すべてのアプリケーションに同じチェック機構が実装されていることを、どうすれば保証できただろうか。また、追加の制御機能はどのように実装できただろうか。 PAMは、こうした問題に対するシンプルな解決策だ。ユーザの認証を必要とするプログラムは、PAMのAPIを呼び出すだけでよい。あとは、PAMの設定ファイルに記述されたルールに従って、APIの向こう側が必要なチェックを行ってくれる。認証のメカニ

コマンドラインから電子メールを送信する必要に迫られたユーザはmail(1)コマンドに手を伸ばすかもしれないが、そうした場合は email というプログラムを選択しておくと、SSLを用いたSMTPサーバへのメール送信、複数ファイルの添付が可能なMIMEのサポート、アドレスブックによる送信先の管理、デジタル署名および暗号化の実施といった、より高度な機能を利用することができる。 確かにその他の選択肢としては、PerlやPHPから非常に複雑な構成の電子メールを送信するツールも存在してはいるが、cronジョブその他のアプリケーションから添付ファイルを1つ付けただけのメッセージを1件送信したいという場合に便利なのは、電子メールをコマンドラインから直接送信するという機能のはずである。 先の“email”というプログラムはこれが正式なプロジェクト名なのだが、本稿では混乱を避けるために“emailプログラム

設計・実装から運用，メソドロジまで，最新アンチパターンを徹底解説 先輩から教わったことのなかに多くの「やってはいけないこと」（アンチパターン）があるだろう。だが，その理由を問われると，うまく説明できないことがあるのではないだろうか。突き詰めて考えると，状況によっては「やっても構わない」こともあるし，技術の進化に伴い「やれるようになってきた」こともある。そこで設計，実装，テスト，運用，メソドロジの各分野について，取材を通じて浮かび上がった最新アンチパターンを徹底解説する。テーマごとに「どれくらいやってはいけないか」のレベルも表した。レベル３～レベル１の３段階あり，レベルの数字が大きいほど，やってはいけない度合いも大きい。 関連サイト： ■設計編 ■メソドロジ編 ■実装編 ■テスト編 ■運用編 ■サーバー運用編 ■データベース編 ■セキュリティ編 ■記録メディア編 ■方式設計編 ■内部統制編

Linuxシステムでのトラフィック解析に関してはntopやvnstatなどの本格的なプログラムを使えば済む話だが、状況によってはネットワーク上のホスト群で交換されるトラフィック量の基本情報だけを簡易的に把握できればいいという場合もあるだろう。そうした用途に適しているのが、バックグラウンドプロセスの1つとして実行されるパケットスニッファのDarkstatという小型プログラムである。その基本機能は、ネットワークの利用状況に関する統計情報を収集して、HTTP経由で表示するというものだ。 今回私は同プログラムの最新バージョン（darkstat-3.0.707.tar.bz2）をCentOS 5およびFedora 7システムにて試してみた。具体的なインストール操作としては「tar xvjf darkstat-3.0.707.tar.bz2」によるtarボールの展開をしてから、通常の手順に従って「./

これほど長い間、さまざまなIT管理者が同じ過ちを繰り返すのを見つづけてくると、その過ちに共通のパターンがあることに否応なく気づかされる。よく見る5つの過ちと、その避け方のヒントを以下に記しておく。 過ち#1：事後対応のみで、事前対策なし IT管理者が犯す最大の過ちは、責務の果たし方が事後対応的であることだ。つまり、問題が起こってから対応に慌てふためく人が多く、早くから潜在的問題に気づき、事前に解決策を用意しておく人は少ない。IT管理者に特有のことではないが、IT部門の管理者が予防的措置を怠るとなると、致命的な過ちになりうる。 たとえば、しっかりした予防意識を持っているIT管理者なら、事が起こってからその場でレスキュー計画をでっち上げたりせず、事前にちゃんと備えをしておくだろう。しかも、ハードウェア障害、自然災害、システム不調、その他、起こりうる危険の1つ1つに対応策を用意しておくに違いない

IPCopは、IPCopをインストールしたコンピュータとネットワークを保護することを唯一の目的とした特化型Linuxディストリビューションだ。IPCopは「不正パケットはここから先は侵入禁止！」と誇り高く宣言している。今回SOHO LANにIPCop 1.4.16をインストールしてみたところ、その宣言通りのことが成し遂げられていることが分かった。 私のLANの構成は常時変動しているが、最小構成時にも少なくとも2台のコンピュータと1つの無線LANアクセスポイントがある。ルータは、ラップトップからインターネットにアクセスするためと、ケーブルで接続するのが面倒な場所に置いてあるHewlett-Packard製のネットワークプリンタにアクセスするために使用している。この基本構成に雑多なコンピュータを一時的に追加したり削除したりしている。 ここで私のLANの構成を述べたのは、IPCopの導入を検討す

Linuxユーティリティを組み合わせて使えば、ネットワーク上の誰がどの共有ファイルシステムを利用しているかがいつでもわかるので、システムのアップデート時には彼らにログオフを依頼することができる。 私の顧客の1人は、Visual Basic 6およびAccessベースの数多くの小型アプリケーションを直接Linux上で稼働させて、Sambaによるネットワーク共有を介して各Windows XPクライアントから利用できるようにしている。だが、そうしたアプリケーションやデータベースのアップデートが必要になるたびに、彼は新しいバイナリやAccessファイルをサーバにアップロードできるようにそのアプリケーションからのログオフをユーザに依頼することになる。しかし、彼の管理する中規模ネットワークにはそうしたアプリケーションを使用しているクライアントが100台ほど存在するため、たとえログオンしているのが1人だ

cles::blog 平常心是道 blogs: cles::blog NP_cles() « qmailをDomainKeysに対応させてみる :: とりあえず引っかかったみたい » 2006/12/24 qmailをSPFに対応させてみる  qmail  antispam 781 3へぇ DomainKeysに対応させたついでなので、SPFにも対応させてみました。 † SPFとは SPFはDNSにメールが送信される可能性があるサーバーをあらかじめリストアップしておき、リストにないサーバーからメールが送信されているものをspamとみなす技術です。基本的にはDNSだけの仕組みなのでDomainkeysよりはだいぶシンプルな仕組みになっています。 SPF/SenderIDとひとくくりにされていることが多く、これらは互換性もあるようですが、技術としては別のもののよう*1です。SenderIDにつ

高い壁を作るだけがセキュリティ対策ではない。攻撃者の心理を考え、彼らに選ばれないシステム作りも大きな効果が望めるのではないだろうか。本連載では視点を変え、攻撃者に選ばれないためにできる、ほんのちょっとした対策を取り上げる。（編集部） 対策をもう一歩進めるための新たな視点を持とう システムは動くだけではなく、セキュリティ対策がなされていなければいけないといわれ始めて久しい。セキュリティという言葉を聞くと、物理的なものだけではなく、ネットワークセキュリティを連想するほどの認知度も得ているのではないだろうか。 個人宅のネットワーク環境にもファイアウォール機能を搭載したルータがあり、PC1台1台にアンチウイルスソフトがインストールされている。いまとなっては珍しくなく、むしろ当たり前とも思えるようになった。 一方、ネットワークに存在する脅威というと、ウイルス、ワーム、ボット、サイトの改ざん、個人情報

適切に設定されたSSHサービスはサーバへのリモート接続を安全にしてくれるが、SSHサーバがマシン上で常に動いているということ自体がそもそも好ましくないという場合もあるかもしれない。SBD（Secure Back Door）を使うと、サーバへの暗号化した接続をオープンして、例えばSSHサービスの起動やウェブサーバの起動やマシンの再起動などといったオペレーティングシステムに対する任意のコマンドをリモートから実行することができるようになる。 SBDでは好きなポート番号を使用することができるが、ポート番号を指定しない場合のデフォルトは31415番ポートとなっている。通信には、SBDプロトコルを使用する。SBDプロトコルでは、データの改竄がないことと出所の信頼性を証明するために、ワンタイムパッド共通鍵とHMAC（keyed-hash message authentication code）を使用して

サーバ管理者の多くは、自分の運用するサーバに対して、第一にサービスが停止しないこと、そして第二に不正侵入されないことを願うだろう。特にここ数年は、不正侵入の事例が多く報告されていることから、いま一度サーバのセキュリティを見直し（再点検し）たいと思っている読者も中にはいると思う。 そうした場合、OSのリプレースから行い、セキュリティを考慮した設定を行うのが望ましい。しかし実際は、顧客などにサービスを提供したり基幹サーバとして24時間フル稼働している以上、そうやすやすと止めるわけにはいかないのが現実だ。もちろんサーバの冗長化を行っていればその問題はクリアされるが、ほとんどの場合、予算などの関係ですべてのサーバがそのような構成を取ることはできないだろう。 本連載では、現行動作しているUNIXサーバを対象に、稼働サービスの停止を最小限に抑えつつ、セキュリティを向上・維持するための一連の設定やツール