サーバー運用レポート 2026-06-10

対象期間：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アドレスは匿名化しています。