先日、管理しているメールサーバの調子がおかしいとクライアントから連絡がありました。
「特定の日のメールが届いていない」というのです。
すぐにログを調べてみると、想像以上の異常が記録されていました。
350万回の認証失敗
/var/log/maillog を確認すると、SASL LOGIN authentication failed の嵐。
数えてみると 350万回以上 のログが残っていました。
メールサーバ自体の不調ではなく、外部からの大規模な攻撃が原因でした。
この攻撃で一番つらかったのは、サーバ防御の要である Fail2ban がリソース制限に引っかかって動作不能になってしまったことです。
結果的に「アクセスし放題」状態がしばらく続き、正規のクライアントの接続にも影響が出たようです。
攻撃の入り口は25番ポート
メールサーバの設定を見直してみると、25番ポートでの認証が有効になっていたことが分かりました。
25番は本来 MTA 間（サーバ間配送）のためのポートであり、ユーザ認証に使うのは 587(submission) や 465(smtps) が標準です。
そこに向かって大量のブルートフォースアタック（総当たり攻撃）が行われていたわけです。
対策と再設定
対応としてはシンプルです。
-
25番ポートでの認証を無効化
-
ユーザ認証は 587/465 のみ許可し、TLS必須に
-
Fail2ban の設定を見直し
-
必要な jail だけを残す（postfix / dovecot / sshd など）
-
systemd backend で効率的にログを監視
-
systemd の
LimitNOFILEを引き上げて「Too many open files」を防止
-
-
Postfix 側でも接続レート制限 (
smtpd_client_connection_rate_limitなど)
これらを反映してからはサーバも落ち着き、ログも静かになりました。
今回の学び
-
公開しているメールサーバには常時攻撃が来ている。
-
Fail2ban は有効だが、無限に守ってくれるわけではなくリソース制限の壁に注意が必要。
-
「25番でのユーザ認証」は避ける。
-
不具合報告を受けたらまずログを確認し、不正アクセスによるリソース枯渇の可能性も疑う。
日常的に「ログに出ているけど無害」と思っていた攻撃も、規模が大きくなるとインフラに直接ダメージを与えます。
メールサーバの運用は地味に見えて、実は攻防の最前線。
あらためて「基本設定をきちんと守ること」と「監視と見直しを怠らないこと」の重要性を痛感しました。
チェックリスト（運用者向け）
-
25番ポートでユーザ認証が有効になっていないか？
-
submission(587) / smtps(465) で TLS を必須にしているか？
-
Fail2ban の jail を必要最小限にしているか？
-
postfix / postfix-sasl / dovecot / sshd だけ
-
-
Fail2ban のリソース上限を systemd で十分に確保しているか？
-
LimitNOFILE を 65536 以上に
-
-
Postfix の接続レート制限を設定しているか？
-
定期的に maillog を grep して、不正アクセスの傾向を確認しているか？
まとめ
今回の件で、基本を守った堅牢な設定がいかに重要かを再確認しました。
攻撃は止められませんが、適切な制限と監視で「壊れないサーバ」を維持することは可能です。