1 はじめに
本記事では、Postfixのメールログの見方と
ログから見つかった不正アクセスをしようとしているホストのアクセス制限の
方法について説明していきます。
ここ2カ月ほど（2022年04月から）、
自宅ネットワーク・ルーターのアクセス・ランプが
激しく点滅していることに気づき、その原因が気になっていました。
ネットワーク・スニファーで見てみると、
どうも自宅のSMTPサーバーへの接続要求が
異常と言っても差し支えないほどとっても多い！
それで、メールログを見てみなければ、となったわけです。
TCP/IPについては多少知っていたものの、
メールログについてはほとんど知っていません。
たいした知りもせずにみてみると、
やたら行数が多くて、どこから見たら良いのか、
異常の原因となったログを見つけ出すのはそう簡単ではなく難しい！
それで、メールログの見方を調べようとなった次第です。
本記事は、この成果を整理したものです。
下に示す図書は、この調査を行う上で指針となったもので、
みなさんにも紹介したいと思います。
2 maillog
本章のタイトルである”maillog”は、Postfixメールログのファイル名です。
本章では、このmaillogに書かれている内容について見ていきます。
Postfixのメールログ（maillog）には、
大まかに言うと以下の内容が含んでいると言えます。
- ① 処理の発生日時
- ② ホスト名
- ③ プロセス名
- ④ メールキューID
- ⑤ 内容
- 送信元SMTPサーバー
- メッセージID
- 送信元のメールアドレス
- 送信先のメールアドレス
- 送信結果
以上の内容は、1行に記録されているわけではありません。
Postfixは、複数のプロセスが連携してメールの処理を行っています。
それぞれのプロセスがログを出力するわけですから、
ログの意味を理解するには各プロセスの役割を知っている必要があります。
複数行にわたるログ行から、上記の内容を見つけ出していくわけです。
本章では、
Postfixのプロセスについての概要を説明し、
実際のメールログからログの見方を示していきます。
なお、Postfixメールログのファイル・パスは、
RHEL 8系、CentOS 8系では次の通りとなっているとして説明していきます。
他のLinuxディストリブーションの場合については、
調査していませんので、ここで示すのはご容赦ください。
2.1 maillogを見るために必要なPostfixのプロセスの知識
Postfixプロセスと、各プロセスがはき出すログの概要については、 下に示すサイトをご覧ください。
maillogの見方―Postfix、Dovecotが出力するログの見方 ｜ zealseeds
とっても分かり易くまとめられています。
2.2 メール送信時のログ実例と目的のログの検索について
2.2.1 メール送信時のログ
メールログは、2.1節で述べたように、1通のメールの送受信に対して1行のログではなく、
複数のプロセスによる複数行にまたがるログとなります。
図2.2-2に示すメールログは、
図2.2-1に示す環境下において、nobody@nowhere.netのユーザーが
192.168.10.10の端末からhoge@example.comへメールを送信した時のものです。
① 送信元からのSMTP接続ログ
アプリケーションからMTAまでのSMTP通信が確立されると、
図2.2-2①の2行目にあるようにメールキューID（2D6C0BFF13）が生成されます。
メールキューIDとは、サーバー内部でメールを処理するときに付与されるユニークなIDで、
メール送信が完了するまでログに記録されます。
②で出力されるメッセージIDもメールを特定するためのユニークなIDですが、
こちらはログの1行目にしか出力されません。
そのため、複数行に分割されるログを解析するには、
メールキューIDをキーに次の②～⑤のログを追っていく必要があります。
② メッセージIDと送信元メールアドレス（エンペロープFrom）のログ
SMTP接続後、
メールを特定するためのメッセージID、送信元メールアドレスの情報が記録されます。
ここで記載される送信元メールアドレスが、エンベロープFromアドレスになります。
③ 送信元とのSMTP切断ログ
メール送信元のアプリケーションから、
メール送信に必要な情報がすべてMTAへ渡されるとSMTP接続が切断されます。
④ 送信先へのメール送信ログ
外部ドメインの宛先（example.com）にメールを送信しているときのログが以下の通りです。
［ログに記載されている項目］
- to= : 送信先メールアドレス情報
- relay= : 送信先SMTPサーバー情報
- delay/= : メール送信の処理時間
- status= : 通信結果
- 末尾の()内 : 送信先SMTPサーバーからの応答コードおよびメッセージ
「status=」の値は、以下となります。
- sent : 送信成功
- bounced : 送信失敗
- deferred : 一時的に配送不可のため再送
sent以外の場合は、
メールの送信ができていない状態となりますので「末尾（）内」に記載される内容より、
送信ができなかった原因を確認する必要があります。
⑤ メールキューの削除（メール送信処理終了）
メール送信が完了すると、最終的にメールキューを削除して、送信処理が完了となります。
2.2.2 ログ検索の方法
本項では、ログ検索方法の指針のみを示します。
具体的な方法は、探し出すログの種類によってそれぞれ違ってきますから、
ここで挙げるのはかなり難しいです。
メールログには、
自分や自分が属するドメイン内のメール送受信だけではなく、
多くは不正アクセスなのですが外部からのアクセスも
多数（１日で、数万行以上）記録されています。
また、１通のメールの送受信ログは複数行になりますので、
その中から目的のログを見つけ出すのは至難の技で、
工夫しなければ到底見つけ出すことができません。
目的のログを見つけ出すには、次のようなものをキーにgrepして、
順々に絞り込んでいくようにしなければなりません。
- 送信元や送信先メールアドレス
- 日時
範囲を狭められたら、
関連するログは、メールキューIDをキーに見つけ出します。
メールキューIDは、
メールが相手先サーバーに届くまでの間に発生した処理で
一貫して管理されています。
2.3 メールログ解析ツールpflogsumm
メールログの解析を目視だけで行うのは、大変つらい作業です。
探してみると、pflogsummというツールが見つかりました。
これで欲しい情報が容易に見つかるようになり、とっても便利です。
pflogsummは、Postfixのログ解析ツールで、Perlで作られたものです。
公式サイトは、以下の通りとなっています。
2.3.1 pflogsumm概要
pflogsummは、以下に示すような項目の集計ができます。
- メッセージの受信数、配送数数、転送数、バウンス数、拒否数
- 受信したメッセージのバイト数
- 送信者、受信者のホスト/ドメイン
- 送信者と受信者
- smtpd接続数、ホスト/ドメインの数、平均接続時間および合計接続時間
出力可能な情報の全種類については、公式サイトでご確認ください。
集計された情報はキャラクターベースで出力されますが、
欲しい情報がきちんと整理されていてとても見やすいです。
図2.3-1に、出力例を示します。
2.3.2 インストール
RHEL 8系、CentOS 8系では、下に示すようdnfでインストールするのが、
一番面倒がなく楽です。
dnfでインストールできない環境であれば、公式サイトからダウンロードし、
「README」ファイルの内容にしたがってセッティングします。
Perlのスクリプト・ファイルをコピー・セッティングするだけでなく、
manファイルもコピー・セッティングしておいた方が、後で何かと役にたつと思います。
2.3.3 pflogsummコマンド書式
pflogsummのコマンド書式は、次のようになります。
メールログ・ファイルが指定されなかった場合は、標準入力からの入力となります。
図2.3-2に、pflogsummのSYNOPSISを示します。
各オプションの意味については、manコマンド「man pflogsumm」でご確認ください
（pflogsummセッティングにおいて、manファイル（pflogsumm.1)が
所定のディレクトリ下にコピーされていない場合は表示されない）。
表2.3-1に、よく使われるオプションの説明を記しておきます。
2.3.4 pflogsummのCron登録
pflogsumをCronに登録して解析結果をメールするようにすれば、運用が楽になります。
なお、RHEL 8.Xには、mailコマンドがなく、mailxとなります。
場合によっては、mailxのインストールが必要となります。
解析結果メール送信先は、通常の外部メールアドレスでも良いと思うのですが、
2022年05月27日現在、わたしの環境下では外部指定はダメで、
内部のアカウントへしか送信できていません
（未調査: 送信先メールサーバーの問題のよう）。
3 Postfixのアクセス制限
本章では、Postfix側で行うアクセス制限の方法を示します。
IPアドレスによるアクセス制限は、ファイアウォールの設定で行う方が楽だと思います。
ルーターの設定でも、SMTPのアクセス制限の設定は可能ですが、
おそらく頻繁な設定変更で、
本体リセットを度々行わなくてはならないようになるものと思います。
ファイアウォールによるアクセス制限の方法については、
別記事を起こしたいと思います。
3.1 SMTPのアクセス制限は絶対に必要
メールログ解析結果により、わたしの環境下では、
SMTP-AUTHに失敗している不正アクセスが
日に6万件以上発生していることがわかりました
（1日は、60×60×24=86,400秒。 1秒に1件！ そりゃー、ルーターさんが悲鳴をあげるわな）。
無名の個人が運用しているメールサーバーで、
日に6件以上の不正アクセスがあったなんて思いもしませんでした。
踏み台にされないためにも、
アクセス制限は絶対に行っておかなければならないと思いました。
ルーターのアクセス・ランプの異常な点滅も精神的に良くない！
6万以上の件数だといっても、わずか数アドレスからアクセスだけで、
計算はしていませんが90%以上となっていると思いますので、
制限すべきIPアドレスの数はそう多くはありませんでした。
SMTPのポートを閉じてしまえば話は簡単なのですが、
外部からのメールを受信するのでしたら
ポートは開かざるをえません。
3.2 Postfixにおけるアクセス制限
アクセス制限は、次の２つのファイルの更新と作成で行います。
- (1) main.cfへSMTP接続制限を追加更新
- (2) アクセス制限対象dbの作成
3.2.1 main.cfへSMTP接続制限を追加更新
「main.cf」ファイルの最終行に以下の内容を追記します。
【設定内容説明】
- smtp_client_restrictions
- SMTPサーバーがクライアントからSMTP接続の要求を受けた際に適用する。
- reject_rbl_client
-
「reject_rbl_client」と記述されている行が5行存在します。
これは「RBL(Real-time Blackhole List)」と呼ばれるスパムメール送信元データベースから
REJECT対象の送信元を判別させるための記述です。
今回はIPアドレスを指定したアクセス制限以外にも、
各団体などが管理しているスパムメール送信元リストも
アクセス制限の判定条件に加えることします。
今回の設定例に記述したRBLのリストは、 The Anti-Abuse Projectの
「Multi-RBL Check」処理で利用されていたRBLの一覧から抜粋したものです。
- check_client_access
- アクセス制限を掛ける接続元のIPアドレスやホスト名などを指定します。
- permit
-
最終行にpermitが記述されています。
これはアクセス制限対象か否かを上から順番に評価されていき、
上記の各条件に当てはまらなかったらpermit(許可)と指定しています。
3.2.2 アクセス制限対象db作成
接続元IPアドレスを元にアクセス制限を掛けるため、
その対象となるIPアドレスのリストを用意し、Postfix用のdbファイルを作成します。
まずは、以下のアクセス制限対象リスト用ファイルを作成します。
ファイル「reject_client」は別の名前でも問題ありませんが、
その場合は3.2.1項で示した「main.cf」内の
「smtp_client_restrictions」でも 同じファイルを指定するようにしなければなりません。
ファイル「reject_client」には、拒否するIPアドレスが111.222.123.0/24だとすれば、
以下のようにIPアドレスと拒否のREJECTを記入します。
当ファイルへの記述する際の書式の詳細は、以下の公式マニュアルを参照してください。
入力し終えたら、次のコマンドを実行します。
ディレクトリ/etc/postfix/下にreject_client.dbという名前のファイルが作成されていれば、
成功です
最後に、上記作業で変更した設定をPostfixに反映させます。
RHEL 8系、CentOS 8系では、Postfixでは以下のコマンドで再読み込みを実行します
以上
HTMLだと、
思うように編集することは難しく、やろうすればとっても時間が掛かります。
ですので、本記事の元となっているWordで作成したPDFを
ページ最後に貼り付けました。
役に立てていただければ、うれしく思います。
このPDFファイルは、自由に配布されてもかまいません。
ただし、再配布の際には、
入手元と著者名は明らかにしてください。
なお、上のPDFファイルの内容、また本文中の記述に、
誤字や脱字、誤った内容の記述など見つかりましたら、
下に示すフォームでご連絡いただければ幸いです。
