共用ホスティング6台、1日で全部対応した日の記録

本文：約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