メインコンテンツへスキップ
← ブログに戻る
チュートリアル2026年6月4日by K.hirano

Linux向け無料EDRは実質Wazuh一択だった — 自宅RasPi 5で4.5ヶ月運用した本音と実測

個人のLinuxで無料EDR的監視はWazuhが現実的。RasPi 5で4台を4.5ヶ月運用した実測と、商用EDRとの違いを整理します。

#linux#Wazuh#edr#Raspberry Pi 5#ホームラボ#自宅サーバー

こんにちは。梅雨入りの便りがそろそろ届く頃ですね。雨続きになる前に、家の中で動き続けている機械たちの「見張り番」の話をさせてください。

結論から言うと、個人の Linux なら、無料の Wazuh(オープンソースのセキュリティ監視ソフト)で EDR 的な監視は十分持てます。EDR は「パソコンやサーバーの中で起きた怪しい動きを見張って記録する仕組み」のことで、本来は企業向けの有料製品が多い分野です。私は Raspberry Pi 5 を1台だけ使い、Linux 3台と Windows 1台の計4台を 4.5ヶ月見張らせてきました。ただし、商用 EDR の完全な代わりにはなりません。それでも「何もない」状態と比べると、何が・いつ・なぜ起きたかが見えるようになり、自宅サーバーではこの差がかなり大きく効きます。

この記事では、RasPi 5 で 4.5ヶ月回して分かったことと、詰まりやすいところを実運用の感触で書きます。検出された脆弱性の扱い方は Wazuhを入れたら脆弱性が3,247件検出された話【RasPi 5 自宅ラボ セキュリティ実録 #2】 に分けてあるので、あわせて読むと全体がつながります。

目次

結論: 個人のLinuxならWazuhで無料のEDR的監視は現実的

監視を始めたのは 2026-01-15 です。それから 4.5ヶ月、RasPi 5 の上で Wazuh を動かし続け、4台分の出来事を1か所に集めてきました。

最初に線を引いておくと、Wazuh は商用 EDR の完全代替ではありません。怪しいプログラムを自動で止めてくれるような働きは期待できない、という意味です。ただ、個人の Linux で本当に困るのは、完全に防げないことより先に「何が起きたのか分からない」ことのほうでした。そこを埋めてくれるだけで、持つ価値は十分あります。

企業向けの比較サイトを読んでも、個人が自宅で本当に回せるのか、手間はどれくらいか、何が見えるようになるのかは、なかなか見えてきません。この記事はそこを埋めるつもりで書いています。

この記事で検証した内容

構築の手順書ではなく、「無料の EDR 的監視を個人の Linux で本当に持てるのか」を実機で確かめた記録です。確かめたのは次の4点でした。

検証項目環境・期間結果
Wazuh だけで EDR 的監視が成立するかRasPi 5 で 4台監視(Linux 3 + Windows 1)✅ 2026-01-15 から 4.5ヶ月継続運用
RasPi 5 で負荷に耐えるかWazuh 一式を常時稼働✅ RAM 2.7GB・load 0.5・56°C
ノイズは実用レベルまで減らせるか素の状態で 762件/日✅ 2段フィルタで通知は月数件まで圧縮
実際のインシデントで役立つかOOM 障害の実例✅ 検知 → 原因特定 → swap 増設まで到達

構築手順の全部、脆弱性ひとつひとつへの対応、自動化の作り込みは、それぞれ別の記事に切り分けました。構築で詰まった方は RasPi 5にWazuhを入れたらDockerが死んだ話(構築実録)、脆弱性の見方は 脆弱性が3,247件検出された話、検知の後を自動化したい方は WazuhとClaude CodeでCVE調査を自動化した話 をどうぞ。

先に答え: 何ができて、何ができないか

Wazuh を「無料 EDR」と呼ぶとき、混同しやすいところがあります。できることと、別物として考えるべきことを並べるとこうなります。

項目WazuhでできるWazuhでは足りない/別物
ファイル改ざん検知できます自動隔離ではありません
OS変更の監視できますすべての変更を静かに整理してくれるわけではありません
脆弱性の検知できます攻撃の実行阻止までを自動で担うものではありません
設定準拠の確認できますCISを丸ごと盲信すると運用が壊れます
異常の通知できますノイズは多いです
プロセス挙動の自動遮断基本的に守備範囲外ここは商用EDRの土俵です

ひとことで言えば、Wazuh で持てるのはEDR 的な監視であって、商用 EDR と同じものではありません。見張りと記録は得意で、自動で止める仕事は守備範囲の外、と考えておくとずれません。

実機構成: RasPi 5 16GBとNVMe SSDで回した

使っている機材は次のとおりです。

  • Raspberry Pi 5 16GB
  • NVMe SSD 256GB
  • Wazuh Manager v4.14.5
  • 監視対象: Linux 3台 + Windows 1台

電源・ケース・冷却は組み方で変わるので、型番は決め打ちしません。まず押さえてほしいのは RasPi 5 の 16GB 版と NVMe SSD(高速なタイプの SSD)の2つです。この監視サーバーを含めた自宅ラボ全体の構成は Homelab実機ビルド一覧 にまとめています。

RasPi 5 上の Wazuh Manager が Linux サーバー3台と Windows PC 1台を監視し、重要アラートだけを LINE に通知する監視トポロジ図。4.5ヶ月無停止・メモリ約2.7GB RasPi 5 が監視のハブ: 4台のエージェントから集めて、重要なものだけ LINE へ。

監視される側の4台には「エージェント」と呼ばれる小さな見張り役を入れ、集めた情報を RasPi 5 に送らせます。RasPi 5 では Wazuh 一式(集めて分析する Manager、記録を蓄える Indexer、画面で見る Dashboard)を動かしていて、重要なものだけが LINE に届く仕組みです。

RasPi 5 で監視サーバーを立てると聞くと、少し無茶に見えるかもしれません。正直、私も最初はそう思いました。でも、測ってみると話は違いました。

4.5ヶ月運用して分かったこと

2026-06-04 時点で測ると、Wazuh 一式のメモリ使用量は約 2.7GBでした。そのうち、記録係の Indexer(Java で動いています)が 1.58GB を占めます。CPU の忙しさを示す load average は 0.50、CPU 温度は 56.2°C。15日連続で動かし続けても余裕があります。

16GB 版の RasPi 5 なら、少なくともこの規模では苦しくありません。

大事なのは、スペック表を見て安心することではなく、実際に回り続けているかどうかです。自宅ラボは「動いた」だけなら簡単で、本当に試されるのは「存在を忘れた頃もちゃんと動いている」かどうか。その意味で、4.5ヶ月の継続運用(直近は15日連続稼働)は、判断の材料になります。

実例① OOMで「なんか落ちた」が「何が・いつ・なぜ」に変わった

4.5ヶ月でいちばん大きかったのが、この一件です。

ある日、ワークステーション(普段の作業用 PC)でメモリが足りなくなり、OOM Killer(メモリが尽きたときに Linux がアプリを強制終了させる仕組み)がパスワードマネージャ(2.7GB)と Chrome を落としました。ついでに tmux(ターミナルの作業画面を保っておく道具)のセッションも2つ巻き添えです。こういうとき、現場では「また何か変なことが起きた」で終わってしまいがちです。

ところが Wazuh は、これを rule 5108 / Level 12 としてその場で検知していました。LINE に通知が届き、翌日ログをさかのぼると、原因はメモリリーク(アプリが使ったメモリを返さず溜め込む不具合)と swap 不足でした。swap は、メモリが足りないときに SSD を一時的な置き場として使う仕組みです。

そこで swap を 8GB→16GB に増やして、恒久対策としました。

EDR 的な監視があると、ただの「落ちた」が「何が・いつ・なぜ」に変わります。記憶や勘に頼らず、ログの時系列を並べて原因にたどり着けるので、復旧の速さも再発防止の確かさも変わってきます。

実例② CVEの見逃しを減らす使い方

Wazuh は、パッケージ(ソフトの部品)が更新されるたびに脆弱性のデータベースと照らし合わせ、当てはまる CVE(公開された脆弱性につく通し番号)を知らせてくれます。私の環境でも、CVE-2026-31448 などが rule 23506 / Level 13 で自動で通知されました。

ただ、Wazuh がしてくれるのは「ここに脆弱性がありますよ」と教えるところまでで、修正を代わりに済ませてくれるわけではありません。通知はあくまで入口で、そこから先は自分で次のことを判断します。

  • 影響範囲はどこか
  • そのパッケージは本当に使っているか
  • その場で上げてよいか
  • 代替や待機が必要か

脆弱性ひとつひとつへの対応は長くなるので、Wazuhを入れたら脆弱性が3,247件検出された話 に分けて書いています。

一番つまずいたのは導入手順ではなくARM64の構成だった

Raspberry Pi 5 の頭脳は ARM64 という種類で、普通の PC とは中身の作りが違います。ここで Wazuh の Docker 構成(アプリを箱ごと配って動かす方式)は動きませんでした。少なくとも私の環境では、ここが最初の罠でした。

結論だけ言うと、正解は deb パッケージを直接インストールするやり方でした。systemd のサービス3本(OS が起動と見張りを受け持つ常駐プログラム)で組む構成です。

細かい経緯は構築記事に書きましたが、この記事で覚えておいてほしいのは1点だけです。RasPi 5 で Wazuh を動かすなら、Docker 前提で考えないほうが早い。

ノイズは多い。だから2段フィルタが要る

Wazuh は便利ですが、静かな見張り番ではありません。正常な変更まで全部拾うので、最初は通知の多さに面食らいます。

私の環境で1日分を数えると、こんな具合でした。

  • FIM Integrity checksum changed が 762件/日
  • dpkg 系が 281件/日

FIM はファイルの中身が変わったことを知らせる改ざん検知で、dpkg はソフトの入れ替えの記録です。apt upgrade(ソフトの一括更新)を1回回すだけで、FIM が数百件鳴ることもあります。

ここで「うるさいから失敗」と切り捨てるのは早いです。Wazuh は異常を知らせるだけでなく、変更を残らず書き留める記録係でもあります。だから届いたものを全部通知に回すと、人間のほうが先に疲れてしまいます。

そこで入れたのが2段フィルタです。

  1. LINE通知は Level 12+ のみ
  2. さらに 30分クールタイム を入れる

これで、LINE に届く通知は月に数件まで減りました。

Wazuh のアラートを2段フィルタで圧縮するフロー図。1日762件のアラートを Level 12以上のみに絞り、さらに30分クールタイムをかけて、LINE 通知は月数件まで減らす 2段フィルタの仕組み: 762件/日の洪水を、LINE に届くのは月数件まで圧縮。

誤検知というより、正常な変更も全部記録されるのが Wazuh の本質です。ここを分かっていないと、「役に立つのに疲れる」という、いちばんもったいない状態に陥ります。

SCAスコアが思ったほど高くなくても焦らない

SCA は、サーバーの設定が推奨のお手本(ここでは CIS という団体の基準)にどれだけ沿っているかを点数にする機能です。CIS Ubuntu 24.04 の基準で測ると、私の環境は 48〜53% でした。

数字だけ見ると低く感じますが、不合格の内訳を見ると、大半は次の2種類でした。

  • 独立パーティション未分離
  • mount オプション系

どちらも、ディスクの区切り方や使い方の細かい設定の話です。自宅ラボでこれを全部厳しく当てはめると、今度は別の問題が出ます。たとえば AI 用のサーバーで /tmp noexec(一時フォルダでのプログラム実行を禁じる設定)を強くかけると、PyTorch 系のツールが壊れることがあります。

SCA は点数を上げる競技ではなく、自分の使い方に合わせて、どこを固めてどこを緩めるかを見るための物差しです。点数が低いからダメと決めつけず、何が理由で低いのかを見て判断してください。

判断の目安: こういう人には合う

Wazuh と相性がいいのは、こんな方です。

  • 自宅サーバーやVPSの異常を、あとから説明できる形で残したい
  • 商用EDRは高くて手が出ないが、監視は欲しい
  • Linuxの変更や脆弱性を、1台にまとめて見たい
  • ノイズを許容してでも、見える化を優先したい

反対に、次のどれかに当てはまるなら、Wazuh 単体では期待とずれます。

  • 自動隔離や自動遮断が必須
  • 通知の少なさを最優先したい
  • 導入後のチューニングに時間を使いたくない

次にやること

ここまでをまとめると、個人の Linux なら Wazuh で無料の EDR 的監視は現実的に持てます。実際、RasPi 5 一台で4台の監視が 4.5ヶ月回っています。ただし、商用 EDR の完全代替ではありません。

これから始めるなら、やることは3つです。

  1. 自分の環境で「何を見たいか」を決める
  2. RasPi 5 16GB + NVMe SSD で回す前提を固める
  3. まずは Level 12+ の通知だけに絞って運用する

なお、OS やライブラリのバージョンが違うと手順が変わることがあるので、大事なサーバーに入れる前に、まず試しの環境で動きを確かめておくと安心です。

構築でつまずいたら RasPi 5にWazuhを入れたらDockerが死んだ話(構築実録) へ。脆弱性の見方は 脆弱性が3,247件検出された話、自動化の方向性は WazuhとClaude CodeでCVE調査を自動化した話 が役に立つはずです。

監視の足場ができると、次はパスワードや鍵も自宅に置きたくなってきます。そのときは Vaultwarden + Bitwarden SSH Agentで作る個人セキュリティ基盤 へどうぞ。

最後にもう一度だけ。無料で手に入るのは、監視の入口です。完全な防御ではありません。それでも個人の運用では、その入口があるだけで、トラブルの見え方がずいぶん変わります。

参考リンク

この記事を書いた人

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です!エンジニア専門結婚相談所も運営中、ClaudeCodeで解決できない心の課題も解決いたします!

RTX 4070 Ti 自宅サーバーに Qwen3-TTS を入れた実録 — API変更で3回詰まった話
チュートリアル2026年2月22日

RTX 4070 Ti 自宅サーバーに Qwen3-TTS を入れた実録 — API変更で3回詰まった話

自宅の RTX 4070 Ti に Qwen3-TTS をデプロイした記録。クラス名・メソッド名・戻り値の形式が全部変わっていて3回詰まった。同じ罠に落ちる人が減るよう全部書く。

#AI#TTS#Qwen3#Ubuntu#自宅サーバー
PowerShellでVCP 0x60を書き換え、KVMホットキー切替はWindowsも外部ツール不要
開発ログ2026年7月13日

PowerShellでVCP 0x60を書き換え、KVMホットキー切替はWindowsも外部ツール不要

メーカー案内がないKVMモニターの入力切替を、GNOME・ddcutil・PowerShell標準APIで実装する手順と検証範囲を整理します。

#KVM#ddc/ci#powershell#gnome#wayland
Ollama導入の罠と解決手順——GPU認識・日本語チャットまでの全記録と結論
チュートリアル2026年2月24日

Ollama導入の罠と解決手順——GPU認識・日本語チャットまでの全記録と結論

RTX 4070 Ti搭載の自宅サーバーにOllamaをSSHでセットアップした実録。非対話環境でのインストール罠、バイナリ直接DL、systemdサービス化、qwen2.5:7bでの日本語チャットまで。

#Ollama#ローカルLLM#Ubuntu#GPU#LLM
Claude Code 音声入力、日本語で動かすまでの3ステップと1つの壁
開発ログ2026年3月4日

Claude Code 音声入力、日本語で動かすまでの3ステップと1つの壁

Claude Code の /voice が日本語非対応だったため whisper.cpp で自前の音声入力を作った記録。文字起こしは成功したが、Wayland の壁で Claude Code への直接統合は断念。失敗から学べることをまとめた。

#claude-code#whisper-cpp#voice-input#wayland#linux

META-MARK × セキュリティ

関連する記事をもっと読みますか?

自作PC・AI・セキュリティ・ホームラボについて、実際に動かした記録を書いています。