maillog―見方、具体的なログの解釈の例など

Webサーバのログなら見るけど、メールサーバのログはほとんど見ない、という方は少なくないのではないでしょうか。ですが、トラブルやメールサーバの乗っ取りの疑いを調査するときなどログを見るのが碇石です。見方を知っておけば必ず役に立つ場面があるはずです。本記事では、Postfixが出力するログの見方、具体的なログの解釈の例など、maillogの見方をテーマに情報をまとめています。

目次

1. Postfixとmaillog

maillogとは、Postfixなどメールサーバがログ出力するログファイルの名前です。初めに少しPostixとmaillogとはどのようなものか触れておきます。

2. maillogのフォーマット

本記事では、CentOS7が出力する/var/log/maillogの例となります。他のディストリビューションでも基本的に変わらないと思います。

Aug 19 12:04:03 e-algorithm postfix/qmgr[2504]: 3ED5B4029F76: from=, size=7161, nrcpt=2 (queue active)

各項目は次のとおりに対応しています。

(日時)(ホスト名) postfix/プロセス名[プロセスID]: (キュー番号): 処理内容

3. maillogを見るために必要なPostfixのプロセスの知識とログの見方

Webサーバのログと比べると、maillogの見方は難しいといえると思います。とくにPostfixの場合、複数のプロセスが連携してメールの処理を行っているので、ログの意味を理解するには各プロセスの役割を知っている必要があります。Postfixの代表的なプロセスと、そのプロセスが出力するログについて簡単にまとめておきます。

postfixの内部構造とメールの流れ

3.1. masterプロセスのログの見方

システムに常駐しているPostfixのマスタープロセスです。以降で記載している大部分のプロセスを統括している重要なプロセスっです。ログに登場するのは起動/停止くらいです。

maillogのmasterプロセスのログ出力例)
Postfixの停止

Aug 19 15:02:59 e-algorithm postfix/master[2356]: terminating on signal 15

maillogのmasterプロセスのログ出力例)
Postfixの起動

Aug 19 15:03:00 e-algorithm postfix/master[2502]: daemon started -- version 2.10.1, configuration /etc/postfix

3.2. pickupプロセスのログの見方

システムに常駐し、maildropキューに新しいメールが入っているかを監視するプロセスです。入っていればcleanupプロセスに渡します。

maildropキューに入るのはPostfixが動作しているシステムのローカルユーザが配送を依頼したメールのみです。ですのでログにはuidとユーザ名が出力されます。

maillogのpickupプロセスのログ出力例)
maildropキューに入ったメールの配送処理の開始

Aug 17 16:11:23 e-algorithm postfix/pickup[7670]: AC0FF40D8B58: uid=48 from=

3.3. smtpdプロセスのログの見方

SMTPデーモンに相当するプロセスです。外部のホストからメール配送の要求があった場合に、その接続を受け付けます。受信したメッセージはcleanupプロセスに渡します。

外部からの接続を受け付けるプロセスであるため、様々なログを出力します。

maillogのsmtpdプロセスのログ出力例)
外部のSMTPサーバからの接続を受信

Aug 19 12:04:03 e-algorithm postfix/smtpd[17521]: connect from XXXXX@XXX.XX.XX[XXX.XXX.XXX.XXX]

3.4. cleanupプロセスのログの見方

pickupプロセスやsmtpdプロセス経由で入ってきたメールをincomingキューに入れ、qmgrプロセスにその到着を通知します。

maillogのcleanupプロセスのログ出力例)
配送受付メールについてヘッダ情報を付加してincomingキューにつなげる

Aug 19 12:04:03 e-algorithm postfix/cleanup[17530]: 3ED5B4029F76: message-id=

3.5. qmgrプロセスのログの見方

システムに常駐し、incomingキューに入ったメールの配送処理を行います。qmgrは、Queue Managerの略です。

配送先がローカルユーザの場合はlocalプロセスを、外部のメールシステムを経由する場合はsmtpプロセスを呼び出します。

maillogのqmgrプロセスのログ出力例)
incomingキューに入ったメールの配送処理を実施

Aug 19 12:04:03 e-algorithm postfix/qmgr[2504]: 3ED5B4029F76: from=, size=7161, nrcpt=2 (queue active)
Aug 19 12:04:03 e-algorithm postfix/qmgr[2504]: 3ED5B4029F76: removed

3.6. localプロセスのログの見方

ローカルユーザ宛のメールの配送を行います。

maillogのlocalプロセスのログ出力例)
通常配信された場合

Jul 19 06:57:17 e-algorithm postfix/local[32468]: 0A74E40B3727: to=, orig_to=, relay=local, delay=0.03, delays=0.02/0.01/0/0, dsn=2.0.0, status=sent (delivered to maildir)

3.7. smtpプロセスのログの見方

qmgrから依頼を受けて、外部へのメッセージの転送を行います。smtpdと同様に外部とのインタフェースになるプロセスです。接続先のホストの状態に合わせてさまざまなログを出力します。

maillogのsmtpプロセスのログ出力例)
正常配信された場合

Aug 19 12:04:03 e-algorithm postfix/smtp[17533]: 3ED5B4029F76: to=, orig_to=, relay=xxx.xxxx.xx.xx[xxx.xxx.xxx.xxx]:25, delay=0.41, delays=0.1/0.01/0.01/0.29, dsn=2.0.0, status=sent (250 Message received: xxxxxxxxxxx@xxxxxx.xxxxxx.xx.xx)

参考情報

maillogを見ていて、異変に気づいたときなどの参考情報を追記していきます。

maillogを見ていて海外メールをはじきたい場合

即席で怪しい海外の英文メールをはじきたい場合、タイムゾーンでフィルタすると効果的です。Postfixの設定手順は以下です。

①main.cnfに以下を追加

header_checks = regexp:/etc/postfix/header_checks

②header_checksに以下を追加

日本(+0900)以外全部フィルタする設定です。必要に応じて、除外を特定のタイムゾーンをコメントアウトするのも楽です。

/^Date:.*-0900/ REJECT
/^Date:.*0000/ REJECT
/^Date:.*0100/ REJECT
/^Date:.*0200/ REJECT
/^Date:.*0300/ REJECT
/^Date:.*0400/ REJECT
/^Date:.*0500/ REJECT
/^Date:.*0600/ REJECT
/^Date:.*0700/ REJECT
/^Date:.*0800/ REJECT
/^Date:.*1000/ REJECT
/^Date:.*1100/ REJECT
/^Date:.*1200/ REJECT
/^Date:.*1300/ REJECT
/^Date:.*1400/ REJECT
/^Date:.*0030/ REJECT
/^Date:.*0130/ REJECT
/^Date:.*0230/ REJECT
/^Date:.*0330/ REJECT
/^Date:.*0430/ REJECT
/^Date:.*0530/ REJECT
/^Date:.*0630/ REJECT
/^Date:.*0730/ REJECT
/^Date:.*0830/ REJECT
/^Date:.*0930/ REJECT
/^Date:.*1030/ REJECT
/^Date:.*1130/ REJECT
/^Date:.*1230/ REJECT
/^Date:.*1330/ REJECT
/^Date:.*1430/ REJECT
/^Date:.*0045/ REJECT
/^Date:.*0145/ REJECT
/^Date:.*0245/ REJECT
/^Date:.*0345/ REJECT
/^Date:.*0445/ REJECT
/^Date:.*0545/ REJECT
/^Date:.*0645/ REJECT
/^Date:.*0745/ REJECT
/^Date:.*0845/ REJECT
/^Date:.*0945/ REJECT
/^Date:.*1045/ REJECT
/^Date:.*1145/ REJECT
/^Date:.*1245/ REJECT
/^Date:.*1345/ REJECT
/^Date:.*1445/ REJECT

③postfix再起動

# systemctl restart postfix

maillogを見ていてスパム送信している恐れに気づいた場合

maillogを見ていて、メールアカウントが乗っ取られスパムメールが配信されている場合、IPやドメインがブラックリスト登録されているか確認しておいた方がいいです。メールアカウントのパスワードを変更し、もしブラックリストに登録されてしまっている場合は、リストが広がらないように削除申請が必要です。放っておくとメールが送信できないだけではなく、ドメインのサイトを検索エンジンやセキュリティソフトで表示する際に「このサイトは・・・」と警告表示される恐れがあります。

ブラックリストの例

ブラックリスト検索サイトをいくつか調べてみました。

  • The spamhaus project
    非営利団体SPAMHAUSプロジェクトによるIPアドレスベースの送信者ブラックリスト
  • barracuda central
    バラクーダネットワークス
  • PhishTank
    OpenDNSの無料コミュニティーが運営するフィッシングサイト
  • Google Black API
    Google Safe Browsing API による判定

上記がブラックリストの例です。疑いがある場合は、まずは、簡単にチェックできるSPAMHAUS当たりからチェックしてみるといいかもです。挙げたものだけではなく、たくさんあるようです(少なくとも20~30はあるようです)が、もし登録されて入れもメインどころで拒否されなければ打撃は少ないのではと思います。広がらないようにする必要はありますが。

SPAMHAUSの場合、以下のURLの「XXX.XXX.XXX.XXX」を調べたいサーバのIPにすれば確認できます。赤字で「Listed」となったらブラックリストに登録されていることになります。

https://www.spamhaus.org/query/ip/XXX.XXX.XXX.XXX

もしブラックリストに登録されていた場合は、メールアカウント乗っ取りだけでなく、secureログや操作履歴など、他の侵入痕跡も心配ですね。

ブラックリストの解除の場合、エンドユーザや法人以外からの申請は通りにくいところもあり、解除されるまでリレーサービスを利用するなどの対処も受けられるので、商用環境など重要度に応じて、フォレンジック対応を行う専門業者に相談した方がいいかもです。

更新履歴

  • 2017年01月23日 spamhausのブラックリストのチェック方法について追記しました。
  • 2017年01月20日 postfixの内部構造とメール送信の流れのイメージを挿入しました。
  • 2017年01月13日 maillogを見て異変に気づいた場合の参考情報を追記しました。
  • 2016年08月19日 記事を作成しました。

SNSでもご購読できます。