対象期間：2026年6月9日（昨日分ログ）
対象：共有ホスティングサーバー群（6台）
※ 本レポートはサーバー識別情報・IPアドレス・顧客情報を匿名化しています
サマリー
| サーバー | 状態 | 主なトピック |
|---|---|---|
| Server-A | ✅ 正常 | logwatch配信方式修正・動作確認 |
| Server-B | ✅ 正常 | 特記事項なし |
| Server-C | ✅ 正常 | 大型パッケージ更新後のサービス影響なし |
| Server-D | ✅ 正常 | SMTP認証攻撃を自動防御で処理中 |
| Server-E | ✅ 正常 | SSH総当たり攻撃を自動遮断 |
| Server-F | ⚠️ 要注意 | スパム受信率46%・高スパム率アカウント複数 |
1. Server-A：logwatch配信問題の解決
事象と原因
数日前より、Server-Aのlogwatchレポートがメール配信に失敗していた。バウンスメールの内容は次のとおり。
message has lines too long for transport
(received 4154, limit 2048)
調査の結果、以下の原因を特定した。
- logwatchが
--output mailオプションで直接Exim経由送信していた - レポート内に4154バイトの長行が存在（WordPressツールの定期処理ログが原因）
- EximがRFC 5321の行長制限（2048バイト）を適用して送信を拒否
診断上の落とし穴： 調査時に --range today（当日分）でテストしたところ最長968バイトと正常に見えた。実際の障害は --range yesterday（前日分）で発生しており、当日はデータが少ないため再現しなかった。
対処
cronスクリプトの配信方式を変更した。
# 変更前（直接メール送信）
logwatch --output mail
# 変更後（標準出力 → 行折り返し → mailコマンド）
logwatch --output stdout --format text --range yesterday 2>&1 \
| fold -w 998 | mail -s "Logwatch for ..." 宛先
fold -w 998 の値はRFC 5321の上限1000バイト（CRLF含む）から安全マージンを取った値。
テスト送信で正常配信を確認し、バックアップファイルを保存した上で本番適用済み。
横展開メモ
他のサーバーにも同様の構成が残っている場合、WordPressサイト数が増加するにつれて同じ問題が発生する可能性がある。--range yesterday での最長行確認コマンド：
logwatch --output stdout --format text --range yesterday 2>&1 \
| awk '{ print length }' | sort -rn | head -5
2. Server-C：大型パッケージ更新後の影響確認
更新内容
セキュリティスイートの大型アップデートが自動適用された（バージョン詳細は省略）。
影響
アップデート処理中にメールサービスが一時的に停止（プロセスリロード時の強制終了）。logwatchには Dovecot was killed として記録されていた。
即時確認の結果：
- メールサービスは6月4日より継続稼働中（アップデート前から）
- アップデート当日に正常にリロードされ、現在も稼働中
- 実際のメール配信停止時間はゼロに近い
同様のアップデートがServer-Fにも適用されており、どちらも現在は正常稼働している。
3. Server-D：SMTP認証ブルートフォース攻撃
状況
前日ログに18,758件のSMTP認証失敗が蓄積されていた。当日（6月10日）は1,374件。
攻撃の特徴：
- 送信元IPが毎回異なる分散型（ボットネット）
- 実在しそうな英名アカウントを大量に試行するディレクトリハーベスト攻撃パターン
- クラウドサービス（AzureおよびAWS）経由の攻撃も含まれる
防御状況
ファイアウォール（CSF）の設定を確認した。
| 項目 | 設定値 |
|---|---|
| SMTP認証失敗でブロック | 5回 |
| ブロック種別 | 永久ブロック |
| ブロック済みIP数 | 709件 |
攻撃元上位IPをCSFに手動追加しようとしたところ、すでに自動ブロック済みだった。自動防御が正常に機能している。
考察
個々のIPの試行回数が40〜80回程度で分散しているのは、5回ブロックを意識した設計の可能性がある。現在の設定値は適切と判断し、追加対策なしで様子見とする。
4. Server-E：SSH認証試行
複数のIPからSSH root ログイン試行が記録された。いずれも事前認証（[preauth]）段階で遮断されており、実際の認証には至っていない。
iptablesが16,295パケットをブロック済み。SSH関連の侵害の痕跡なし。
この種の試行はホスティングサーバーに対して恒常的に発生するもので、現状の設定で十分対応できている。
5. Server-F：スパム受信率の高止まり
状況
6月9日のSpamAssassin集計結果：
総受信数：4,335通
クリーン：2,331通（54%）
スパム ：2,004通（46%）
他サーバーのスパム率が概ね25%前後であるのと比較して、明らかに高い。
スパム率が特に高いアカウント（上位）
| スパム率 | スパム件数 | 備考 |
|---|---|---|
| 96% | 179件 | ほぼ全受信がスパム |
| 87% | 556件 | 件数・率ともに最大 |
| 79% | 231件 | — |
| 67% | 83件 | — |
| 66% | 165件 | 別途個別対応が必要な経緯あり |
スパムは受信時にSpamAssassinが判定した後、各アカウントの設定に従って処理される。スパムフラグがついたメールが意図せず破棄されているケースがあり、関係アカウントの設定を個別に確認する必要がある。
今後の対応
高スパム率アカウントへの個別通知は6月中のイニシアティブとして既定済み。本日の確認でServer-Fが優先対応サーバーであることを再確認した。
6. 今日のインシデントなし確認
| 確認項目 | 全サーバー |
|---|---|
| 不正ログイン成功 | なし |
| データ漏洩の痕跡 | なし |
| サービス停止（現在） | なし |
| ディスク逼迫 | なし（最大37%） |
教訓・ナレッジ
logwatchの行長問題（再現性注意）
- logwatchのデフォルト
--rangeはyesterday - 調査時に
todayでテストすると当日分のみでデータが少なく再現しないことがある - 必ず
--range yesterdayで再現確認すること
iptablesとCSFの違い
logwatchのiptablesセクションに記録されるのは「iptablesが遮断したパケット」であり、CSFが管理するIP単位のブロックとは別レイヤー。両方の数値を組み合わせて防御状況を評価することが重要。
クラウドIPからの攻撃
AzureやAWSなどのクラウドサービスIPからの攻撃は、CSFのデフォルト閾値では検知が遅れる場合がある（多数のIPを使い捨てるため）。今回は結果的に自動ブロック済みだったが、今後も定点観測を続ける。
本レポートは実際の運用記録をもとに作成しました。特定のサービス名・ドメイン名・IPアドレスは匿名化しています。
