本文：約2,800文字
その日の朝、logwatchが1通届かなかった
毎朝、管理している6台のサーバーからlogwatchメールが届く。
各サーバーの昨日の状態をまとめたレポートで、スパム・SSH攻撃・ディスク使用率などが一目でわかる。
その日、1台分が届いていなかった。
まず届いていないサーバーを調査
担当AIのくらさん（Claude Code）に調査を指示した。
- cronは動いているか
- logwatchのMailTo設定は正しいか
- Eximの送信ログに記録があるか
結果：サーバー側は正常だった。
logwatchは MailTo = root のまま動いており、rootのメールがエイリアス経由で転送されていた。差出人が root@a700.hanbai.com になっていたため気づかなかっただけ。
設定を tensou@hanbai.org に明示して解決。些細な話だが、こういう「届いていると思っていたら別ルートで届いていた」系の問題は原因特定に時間がかかりやすい。
logwatchが7万行になっていた件
別のサーバーのlogwatchを見て気づいた。ファイルが75,760行ある。
原因を調べると、DovecotセクションのUnmatchedエントリが約7万行を占めていた。中身はこれの繰り返し：
dovecot: imap-login: Logged in: user=<__cpanel__service__auth__imap__...>cPanelの内部サービスが定期的に自己認証するログで、1日285〜287件発生する。logwatchはこれを「既知パターンに一致しない」として全行ベタ書きにするため肥大化していた。
対処として *Remove = __cpanel__service__auth__imap__ をlogfileの設定に追加した。ただし最初は設定ファイルのパスとディレクティブを誤っており、くらさんが自律的に問題を発見して全5台を正しく修正してくれた。
正しい設定：
- ファイル：
/etc/logwatch/conf/logfiles/maillog.conf - 設定値：
*Remove = __cpanel__service__auth__imap__
誤った設定（logwatch 7.5.5では動作しない）：
- ファイル：
/etc/logwatch/conf/services/dovecot.conf - 設定値：
*Ignore = ...
バージョンによって対応ディレクティブが異なる。ドキュメントを鵜呑みにせず実機で確認が基本だと改めて感じた。
スパム率45%という現実
6台のlogwatchを横並びで見ると、スパム率の差が際立った。
| サーバー | スパム率 |
|---|---|
| a700 | 16% |
| da01 | 17% |
| a200 | 20% |
| a500 | 44% |
| a600 | 45% |
| a400 | 47% |
a500・a600・a400は受信メールの半分近くがスパム。SpamAssassinは検知しているのに、ユーザー設定（vfilter）がないため受信フォルダに届いてしまっている。
特に目立ったアカウント：
- myanmarp（a400）：スパム率98% — 243通中239通
- iwashiro（a400）：スパム率96% — 516通中493通
- nksarc（a600）：スパム率89% — 751通中667通
これらに対してExim vfilterを設置した。スコア8以上のメールを /dev/null に破棄する設定で、翌日には着弾数が大幅に減る見込み。
hanbai.comへの認証クラック攻撃
DirectAdminサーバー（da01）のEximログに異常があった。
認証失敗4,252件のうち、hanbai.comが653回で標的1位。
存在しないアカウント名（ランダムな英数字）への総当たり攻撃が24時間継続していた。攻撃元の上位17IPをCSFでブロックして対応。
興味深いのは攻撃パターンで、最初にメールドメイン（hanbai.com）を送りつけ、次にusernameだけで試行するという二段階の手法が見られた。おそらく自動化されたクレデンシャルスタッフィングツールの動作と思われる。
DENY_IP_LIMITが常時満杯だった
CSFの設定で DENY_IP_LIMIT（ブロックリストの上限）が全サーバーで1000のままだった。
攻撃IPを追加するたびに古いエントリが自動削除されていたことになる。再攻撃してきたIPが再度ブロックされているとはいえ、設計として上限に張り付いているのは望ましくない。
全6台を2000に統一した。
1日の作業量
改めて数えると：
- IPブロック：37件 + サブネット1件
- vfilter設置：16アカウント
- DENY_IP_LIMIT引き上げ：全6台
- logwatch設定修正：5台
- その他：passwd_altファイル修正、Eximキュー掃除、logwatch手動再送
すべてくらさん（Claude Code）が実行した。AIに作業指示を渡して結果を受け取る、というワークフローが定着してきた。
指示書はHTML形式で作成し、コピーボタン付きのコードブロックにした。くらさんがそのままターミナルにペーストして実行できる形にすることで、コピーミスや読み間違いを減らしている。
まとめ
共用ホスティングの日常運用は、単発の大きな問題よりも「放置されていた小さな問題の積み重ね」で構成されている。
- logwatchの設定ミス（7万行になっていたが誰も気づいていなかった）
- vfilterの未設定（スパム率98%でも受信フォルダに届き続けていた）
- DENY_IP_LIMITの上限（常時満杯でも動いていたから問題として認識されていなかった）
どれも「動いているから問題ない」と見なされがちなもの。logwatch巡回をAIと組んで定期化することで、こうした積み残しを拾えるようになった。
販売開発 営業・サポート しみず / domainya@gmail.com
