Google大暴走!?


Googleどうなってるんでしょう。
23時45分現在、何を検索しても「このサイトはコンピュータに損害を与える可能性があります。」という注釈が検索結果に付いていてリンク先にアクセスできない・・・

Googleで「google」を検索しても「このサイトはコンピュータに損害を与える可能性があります。」って書いてある (^_^;

最初は面白かったけど、どんどん腹が立ってくる。
だって調べたいのにどのページにもアクセスできない検索サイトって意味無いじゃ~ん

DovecotもPostgreSQLでアカウント管理


いよいよメールサーバー入れ替え実験も最終局面へ。
前回、PostfixがPostgreSQLで管理されたアカウント情報でメールを受信できるようになったので、残るはDovecotでもPostgreSQLで管理されたアカウント情報でPOP3/IMAP4を使ったメール受信とSMTP認証を可能にしてやる事にする。

Dovecotの設定サンプルにSQLを使った認証のものが用意されているのでコピーして使う
# cp /usr/local/etc/dovecot-sql-example.conf /usr/local/etc/dovecot-sql.conf
コピーしたファイルの編集内容は
driver = pgsql
connect = dbname=postfix user=postfix password=*******
default_pass_scheme = PLAIN
password_query = SELECT login_id AS user, password FROM virtual_maps WHERE login_id = '%u' AND status_flag = 1
user_query = SELECT '/var/mail/' || maildir AS home, 10000 AS uid, 10000 AS gid FROM virtual_maps WHERE login_id = '%u' AND status_flag = 1
といった感じ。

default_pass_scheme を PLAIN にしたのは理由がある。
通常はここをmd5などにしておいて、認証時に暗号化したパスワードでクライアントとサーバ間の通信をさせたいが、DB上のパスワードが暗号化されていると同じ暗号化方式の認証しか利用できなくなり汎用性が低くなる。
しかし、DB上のパスワードを平文で保存しておくことで通信時の暗号化方式に幅が出て、多くのクライアントと通信が可能になる。
パスワードの通信方法を制限したい場合はdovecot.confの認証メカニズム指定で制限をかける方が現実的だ。
また、Outlook ExpressはSMTP認証にLOGIN認証しか使えなかったりするのでcram-md5しか使えなくなると接続できない。
まぁ既に開発が終わってサポートも無くなるソフトなんで使わない方がいいのだが、古いWindowsは未だに現役だししょうがない。
Windowsメールになるとmd5を使った暗号化にも対応しているので、乗り換えが進むといいのだが。

続いて /usr/local/etc/dovecot.conf の編集を行う。
auth default {
 mechanisms = plain login cram-md5 apop
 passdb sql {
  # Path for SQL configuration file, see doc/dovecot-sql-example.conf
  args = /usr/local/etc/dovecot-sql.conf
 }
 userdb sql {
  # Path for SQL configuration file, see doc/dovecot-sql-example.conf
  args = /usr/local/etc/dovecot-sql.conf
 }
}
編集箇所を抜粋するとこんな感じ。

パスワードとユーザー情報の確認にSQLを使えるようにしたのと、認証メカニズムにcram-md5とapopを追加した。
cram-md5とapopはDBで管理するユーザーについてのみ有効なことに注意。
OSのユーザー情報のパスワードはhashで暗号化されている。hashは不可逆な暗号化方式なのでmd5で暗号化されたパスワードと比較が出来ないのでOSのアカウントで管理されているユーザーはPLAINかLOGIN認証でしか認証できない。
パスワードの安全性を考えるならメールアカウントはOSのアカウントと分離して管理し、パスワードを暗号化して送信させるか、POPやIMAPの通信自体をSSLで暗号化するのが良いだろう。

Dovecotを再起動し、POP3、IMAP4でメールが受信できることと、SubmissionポートでSMTP認証が使えることを確認できれば完了。

スパムメール


実運用に向けて実験を行っているが、アカウント管理などの正規ユーザーのアクセスに対する実験の目処が立ってきたので、そろそろとスパムメール対策など招かざる客の扱いについても調べ始めた。

Postfixの初期設定は中々良くできていて、不正中継に利用されるようなことは殆ど無い。
実際に不正中継のテストが出来るサイトを使ってテストを行ってみたが、全てのテストをパスしたので、この後間違った設定をしない限り自サイトが悪用されることは無いだろう。

次に問題になるのは自らが管理するドメイン宛に送られてくるメールで、受け取る必要のないスパムメールに対する対策である。
現在運用中のSendmailでは、悪質と思われるサイトからのアクセスを個別に接続拒否するようにしているが、まぁブラックリストのメンテが大変だったりする。

Postfixでのアクセス制御について調べてみると、接続時→HELOコマンド→MAIL FROMコマンド→RCPT TOコマンドと、それぞれの段階でチェックが実施できるようになっている。
ブラックリストを作ったり、正規表現を使ったパターン認識を行ったりと柔軟な設定が可能なようなので、うまく組み合わせをして対策を行っていくようにしたい。

で、対策を施すには敵を知ることも大事なので、今のアクセス状況を調べてみた。
それも、Postfixのテストを行っているサーバのアクセス状況を。
Postfixのテストを行っているサーバは、当サイトのドメインでもある jra.net のセカンダリメールサーバになっている。
通常のMTAであればプライマリサーバが正常に動作していればプライマリサーバへアクセスしてメールを送ってくるが、ちょっと賢いスパムメールの送信者はセカンダリサーバへ送ってくる事が多い。
理由はセカンダリサーバは中継を行うだけでアカウントが存在するかなどチェックを行わない(行えない)から高速にメールが送れるからだ。(他にも理由はいくつかあるがスパム送信を助長させてもしょうがないので詳しくは書かないことにする)

だから、プライマリサーバが正常稼働している時にセカンダリサーバにアクセスしてくる奴は、かなり高い確率でずる賢いスパム送信者だと見ていい。

実際に、ある一日のPostfixのログから接続情報を拾ってみた。
まず、1日の間に何回接続要求があったかというと 23,709回 の接続要求があった。結構多い・・・
サーバのリソースが無駄に消費されている事がよく分かる。

接続元のドメインを調べていくと、流石にOP25Bが普及している日本国内からの接続要求は少ない。
日本国内からの接続要求は固定IPが割り振られていると思われるホストからのアクセスが殆どなので、どちらかというとスパム送信を生業としている人達だろう。

ホスト別の接続回数を集計してみると面白い傾向が見られた。
まず、スパムを送信しているホストの数は15,000程あった。
その内、一つのホストから大量に送信しているのは、なんと2つしかない。
この2つのホストはスパムの送信を自ら行っている可能性が高い。
と言うのも、上位2サイトは100回ほど接続してきているのに対して、他のサイトは殆ど1~5回程度しか接続していない。
そして、どんなに接続回数が多くても30回を超えていない。
きれいに30回で止まっている。30回接続してきたホストの数は70程だった。
これは、かなり良くできたスパム送信のためのボットネットによる送信だと考えられる。

ボットネットはウイルス感染したパソコンを利用し、スパムの送信やDoS攻撃などを行うためのモノ。
ボットネットに対して動作の指示を送る指令者が特定しにくいことから、非常に厄介な存在だったりする。
以前、知り合いから最近パソコンが妙に遅くなったので見て欲しいと言われ見に行ったら、見事ボットウイルスに感染していてパソコンが勝手にスパムメールをせっせと送信していたという事があった。

接続元になっているホストはウイルス感染したパソコンである可能性が高いので、TLDを調べてどこの国が多いのか調べてみた。
まず、半数はDNSの逆引きが設定されなかったので不明となったが、ccTLDが分かった中では一位がブラジルだった。
TLDが判明したホストの約25%がブラジルでダントツのトップだ。
次のccTLDはタイで約7%、後は差が少ないがロシアも比較的多い方で新興国と言われる地域が多い印象。
パソコンやインターネットが普及してきて、比較的高性能なPCと高速なインターネット接続回線があることがウイルス感染を広めているのではないだろうか。

あと、ホスト数が多いのはヨーロッパ、イタリアやドイツが上位に入っている。
先進国ではセキュリティー対策がしっかりしているかと思ったが、案外とそうでもないようだ。

意外だったのは中国がとても少ないこと。
TelnetやSSHへのアタックのログを見ると圧倒的に中国からのアクセスが多いのに、スパムについては少なかった。
ただ、中国のISPは逆引きの設定をしていない所が多いので、不明リストに埋もれているだけかもしれないが...

とりあえずは面白い結果と共に、接続元のパターンが見えてきたので対策の参考にしよう。

Postfixのvirtual_mailboxをPostgreSQLで管理


いよいよPostfix導入実験の山場へと来た。
virtual_mailboxを使って、メールアカウントをOSのアカウントから分離して扱うための実験を始める。

まずは、PostgreSQLにvirtual_mailboxで使うテーブルを用意する。
今回用意するテーブルは2つ。
一つはvirtual_mailboxで扱うドメイン名のリスト。
もう一つはvirtual_mailboxで扱うメールアカウントの情報。

ドメイン名のリストは
CREATE TABLE virtual_domains (
record_id    serial    PRIMARY KEY,
domain       TEXT      NOT NULL,
status_flag  SMALLINT  DEFAULT 0,
note         TEXT
);
GRANT SELECT ON TABLE virtual_domains TO postfix;
と言った感じ。
基本的にエイリアス用に作ったテーブルと考え方は同じで、基本的にはドメイン名を格納するカラムがあればいい。

メールアカウントの情報は
CREATE TABLE virtual_maps (
record_id    serial    PRIMARY KEY,
login_id     TEXT      NOT NULL,
password     TEXT      NOT NULL,
address      TEXT      NOT NULL,
maildir      TEXT      NOT NULL,
status_flag  SMALLINT  DEFAULT 0,
note         TEXT
);
GRANT SELECT ON TABLE virtual_maps TO postfix;
と言う風になり、受信する時に使うログインIDとパスワードがあり、メールアドレスとスプール先のディレクトリ情報を格納している。

それぞれにテスト用のデータを入れてやる。
INSERT INTO virtual_domains (domain,status_flag) VALUES ('sample.com',1);
INSERT INTO virtual_maps (login_id,password,address,maildir,status_flag) VALUES ('vm0001','password','testmail@sample.com','vm/vm0001/',1);

続いて /etc/postfix/main.cf にvirtual_mailboxの設定を追記する。
virtual_transport = virtual
virtual_minimum_uid = 100
virtual_uid_maps = static:10000
virtual_gid_maps = static:10000
virtual_mailbox_base = /var/mail
virtual_mailbox_domains = pgsql:/etc/postfix/pgsql-virtual_domains.cf
virtual_mailbox_maps = pgsql:/etc/postfix/pgsql-virtual_maps.cf
virtual_mailbox_limit = 51200000
virtual_mailbox_lock = fcntl, dotlock
と言う感じで基本的にはデフォルト値のコピー。

virtual_mailbox_domains用のPostgreSQLの設定情報を用意する。
ファイルはmain.cf内に書いた /etc/postfix/pgsql-virtual_domains.cf で
hosts    = unix:/tmp
user     = postfix
password = *******
dbname   = postfix
 
select_field = domain
table        = virtual_domains
where_field  = domain
additional_conditions = and status_flag = 1

もう一つ、virtual_mailbox_maps用のPostgreSQLの設定情報を用意する。
ファイルはmain.cf内に書いた /etc/postfix/pgsql-virtual_maps.cf で
hosts    = unix:/tmp
user     = postfix
password = *******
dbname   = postfix
 
query = SELECT maildir || 'Maildir/' FROM virtual_maps WHERE address = '%s' AND status_flag = 1
となる。
virtual_mailbox_maps用のクエリーはこれまでと異なり、SELECT文を丸ごと記載する方法をとっている。
理由はSELECT結果の表記がちょっと複雑になっているため。

ここまで用意できたら /var/mail の所有権をmain.cfで書いたUIDとGIDに書き換えてPostfixを再起動する。
# chown 10000:10000 /var/mail
# /usr/sbin/postfix reload

後はメールを送ってみて /var/mail の中にスプールディレクトリが出来てメールが保存されていれば成功。

とりあえずメールは送れたので、次は受信できるようにしなければ。

MR検査に行ってきた


今日は待ちに待った(?)MR検査の日でした。
検査は13時からの予約だったので午前中はややのんびりと過ごしつつ、モータースポーツライセンスの更新に行ったりして時間をつぶす。

で、検査の時間に合わせて大学病院へ。
検査の方は診察と違って時間がハッキリ決まっているせいか、待ち時間もなくスムーズに受付を済ませて検査が始まる。

MRIの装置自体は思ったほど大きくない。まぁそれなりに大きい機械だけどイメージよりは小さい印象。そして、体が入っていく穴の大きさが結構小さい。もっとデッカイ穴に入っていくと思っていたので意外なほど小さく感じた。

まずは機械の動作音が大きいということで耳栓が渡される。
耳栓をしてMRIのベッド部分に寝ると器具で頭が固定される・・・窮屈な感じ。

検査技師の人が出て行くと検査が始まった。
確かにもの凄い動作音がしている。耳栓をしていても結構大きな音がする。
なんだか、今にも壊れてしまいそうな音がしているが、振動がある訳ではない。
頭を固定され身動きをすることも出来ず、じっと検査が終わるのを待ち続ける。
多分、検査自体は10~15分くらいだっただろうか。
ただ五月蠅いベッドに固定されているだけで終わってしまった。

結果については来週外来診察で聞くことになっているので、本日の検査は終了。
高価な装置での検査だけあって、今日の診察費用は総額19,400円、本人負担が5,820円と相成りました。

MR検査が決まって以来、ネットで色々MR検査に関する噂などを読んでいた。
面白そうな話も色々あって楽しかったが、実際の所はと言うと・・・

まず、金属類が体にあると検査が出来ないという話。
一説には強力な磁力で体が装置に張り付いてしまうとか、金属が発熱して火傷になるなどという愉快な噂話もあったりする。
確かに問診票や検査の案内には心臓ペースメーカーが埋め込まれていないかとか、血管を広げる金属メッシュが入っていないかとか、色々と確認事項があり金属に対して神経質な様子がうかがわれる。
ただ、虫歯の治療跡に被せる金属の蓋については何も触れられない・・・
実際の所は磁気が金属の影響を受けて、映像がピンぼけしたみたいになるというのが真相のようだが詳しくはよく分からない・・・
虫歯跡に被せた金属の蓋が沢山あるが、別に顎が引っ張られるとかいう感じもなかった。
(予約がいっぱいで、ゆっくり検査技師の人に聞くことも出来なかった・・・残念)
心臓ペースメーカーに関しては、磁力によって誤動作する恐れがあるようだ。

あと、検査室内にあった金属製の消火器が磁力でMRIに突き刺さったなどという噂話も目にした。
確かに検査着に着替える場所にあった金属製のゴミ箱には「検査室内への持ち込み厳禁」などと書かれていた。
が、着替えや手荷物を入れたロッカーの鍵は検査室内へ持って入り、壁のフックにぶら下げただけ。検査室内にも金属製のモノが全くない訳ではない。
まぁ鍵はステンレスっぽいので磁力に反応しないから問題ないのかもしれないが、噂話ほど強烈なモノではないのかも。

まぁ何とも不思議な体験をした一日だった。

次のページ →