Linux管理・運用の基本

これまで、GitやWebサーバーなど様々な場所にClamAVを組み込んできました。しかし、運用が始まると新たな課題に直面します。

「毎日サーバーにログインしてログをチェックするのは現実的ではない」 「業務上必要なファイルがウイルス扱いされ、プロセスが止まってしまう」

今回は、運用を「自動」かつ「スマート」にするための、Slack通知とホワイトリスト管理の実践テクニックを紹介します。

• 異常発生時のみSlackへリアルタイム通知する仕組み
• 誤検知（False Positive）を安全に回避するホワイトリスト設定
• 運用負荷を下げるためのログ管理と解析のコツ

「ログを見に行く」のではなく「異常があれば通知が来る」体制を作ります。第4回の定期スキャンスクリプトに以下の通知ロジックを追加しましょう。

1. 通知用スクリプト（実装例）

#!/bin/bash
set -uo pipefail

# Webhook URLは環境変数などで管理し、スクリプトへの直書きを避ける
WEBHOOK_URL="${SLACK_WEBHOOK_URL:-https://hooks.slack.com/services/YOUR/URL/HERE}"
LOG_FILE="/var/log/clamav/periodic_scan.log"

send_slack_notification() {
    local text=$1
    # -f でエラー時に失敗、-s で進捗非表示
    if ! curl -f -s -X POST -H 'Content-type: application/json' \
        --data "{\"text\":\"$text\"}" "$WEBHOOK_URL"; then
        echo "Slack通知に失敗しました" >&2
    fi
}

# スキャン実行（clamdscanを利用）
# 実行前に clamd が起動していることを確認してください
clamdscan -r /var/www/html --log="$LOG_FILE" || true

# 「FOUND」が含まれる行があるか確認
if grep "FOUND" "$LOG_FILE" > /dev/null; then
    INFECTED_COUNT=$(grep -c "FOUND" "$LOG_FILE")
    INFECTED_FILES=$(grep "FOUND" "$LOG_FILE" | head -n 5) # 最初の5件のみ抽出
    
    send_slack_notification "⚠️ *ClamAV 警告*: ${INFECTED_COUNT} 件の脅威を検知しました。\n\`\`\`\n${INFECTED_FILES}\n\`\`\`"
fi

改善のヒント: 重複通知の防止
毎回同じファイルを通知しないよう、前回のログとの差分（diff）をチェックして新しい「FOUND」のみを通知するロジックにすると、より運用が楽になります。

特定のシステムファイルや暗号化された業務ファイルが、ウイルス（Heuristicsなど）と誤判定されることがあります。これを除外するには、シグネチャベースで指定する「.fp（False Positive）」設定を使用します。

1. ホワイトリストファイルの作成

/var/lib/clamav/local_whitelist.fp を作成し、ログに出力されたウイルス名（シグネチャ）をそのまま記載します。

# 除外したいシグネチャ名を記載
Heuristics.PNG.EncodedInBinary
Unix.Trojan.Generic-12345

2. 設定の反映

追加後は clamd を再起動する必要があります。

sudo systemctl restart clamav-daemon

注意：ホワイトリストのリスク
.fp に登録したシグネチャはその個体だけでなく、その名前で検知される全ファイルがスルーされます。本当に安全なファイルか、ハッシュ値の確認などを含め慎重に判断してください。

大量のログから必要な情報だけを抜き出す、現場で役立つコマンド例です。

「今日の結果概要だけサクッと知りたい」

grep -E "Infected files:|Total errors:" /var/log/clamav/periodic_scan.log | tail -n 2

「具体的にどのファイルがいつ検知されたかリスト化」

grep "FOUND" /var/log/clamav/*.log | awk '{print $1, $3}' | sort | uniq

第7回では、持続可能な運用のための「仕組みづくり」を学びました。

• 通知を自動化し、管理者の「確認コスト」を最小化する。
• Webhook URLなどの機密情報は、環境変数等で安全に管理する。
• ホワイトリスト（.fp）は便利だが、セキュリティホールにならないよう慎重に運用する。

日々のログチェックという重荷から解放され、より重要なインシデント対応に集中できる体制が整いました。

さて、次回でこの連載もいよいよ最終回です。これまでの技術的な実装を振り返りつつ、ClamAVだけでは守りきれない領域や、セキュリティ設計の全体像を総括します。

最終回は「まとめ・設計思想」として、ClamAVのメンテナンスと、他の対策を組み合わせた「多層防御」の考え方について整理します。

ご覧いただきありがとうございました。