これは Arcivéo Monitor のインストール・設定・運用に関するガイドです。 各セクションは、全体概要、ダッシュボードの導入、セキュリティツールの接続、 組み込みモジュール、診断の順にまとめられています。コマンドは右側のボタンでコピーできます。
パネルのインストール手順は、ステップごとの個別ページにまとめています。方法を選択してください：
Arcivéo Monitor はサーバーセキュリティのダッシュボードです。導入済みのツール（Fail2ban、UFW、Lynis、ModSecurity、AIDE、ClamAV、Auditd、CrowdSec、Suricata、Falco など）からデータを収集し、ダッシュボード・攻撃マップ・各ツールの詳細ページを備えた統一インターフェースで表示します。
Monitor は能動的な防御手段ではなく、攻撃自体をブロックすることはありません。稼働中のツールから情報を集約し、見やすい形で提示することが役割です。
モニターはローカルでのみ動作します — 監視対象と同じサーバーにインストールする必要があります。SSH やリモート API は使用しません。
すべてのコマンド（fail2ban-client、ufw status、ipset list など）は、ダッシュボードが Web サーバーのユーザー（通常は www-data、ホスティングパネルではサイトのアカウント）として、限定された権限の sudo で実行します — 特定のユーティリティのみに限られ、root 全体へのアクセスはありません。結果は解析されてブラウザーに表示されます。
スコアは満点から始まり、検出された問題ごとに減点されます:
PermitRootLogin yes） — −20結果: 80以上 = 保護済み、60〜79 = 要注意、<60 = 危険。
WebAuthn はハードウェアキーによるパスワード不要の認証規格です。YubiKey、Touch ID、Face ID、Windows Hello、Passkey に対応します。
パスワードでのログイン後、登録済みのキーによる確認が求められます。パスワードが漏洩しても、物理キーや生体認証がなければログインできません。
設定するには、サイドメニューの WebAuthn キー を開き、「キーを登録」をクリックします。キーは一度に2つ登録してください。唯一のキーを紛失または破損すると、そのキーでのパネルへのログインができなくなります。
ダッシュボードはセキュリティレポートを Telegram とメールに送信できます（ボタン操作またはスケジュール実行）。設定は「設定」セクションで行います。
Telegram。ボットトークンと chat id が必要です:
@BotFather → /newbot に送信し、123456:ABC... の形式のトークンを取得します。@userinfobot にメッセージを送るか、https://api.telegram.org/bot<TOKEN>/getUpdates を開いて "chat":{"id":...} を探します。メール。「設定」→ メールで選べる方法は 2 つ:
re_...）と確認済みの送信元ドメインを指定します。レポートのステータス:「注意」または「OK」。ヘッダーが「注意」になるのは、実際の問題または対応待ちがある場合のみです: ClamAV による脅威の検出、AIDE でのファイル変更、Falco の重大イベント（直近 24 時間の Emergency/Alert/Critical）、Monit で停止したサービス、再起動が必要、SSL の期限切れ間近（14 日以内）、またはセキュリティ更新の待機。バックグラウンドノイズ — ボットによる SSH の総当たり、fail2ban で BAN された IP、Suricata のアラート、Lynis の警告、すでに撃退済みの ModSecurity リクエスト — はステータスを上げません。したがってレポート内のこれらの数値だけで「注意」を意味することはありません。
詳細な監視モジュール（Lynis、UFW、ModSecurity、攻撃マップ、AIDE、ClamAV など）は、有効なライセンスがある場合に利用できます。ライセンスがなくてもダッシュボード、設定、アカウントは動作しますが、モジュールには「ライセンスが必要です」というカードが表示されます。
アカウントで購入すると、ARCIVEO-XXXX-XXXX-XXXX-XXXX の形式の有効化コードが発行されます。これをお使いのパネルのドメインに対して「有効化」する必要があります。これによりコードが署名済みのライセンスファイル（[license] ブロック）に変換され、それをパネルに貼り付けます。
有効化の手順（3ステップ）：
my.arciveo.com →「ライセンス」/「ライセンス有効化」セクションで ARCIVEO-… コードをコピーします。monitor.example.com）を入力します。有効化を押すと、システムがそのドメインに紐付いたライセンスファイルを生成し、「コピー」ボタン付きのフィールドに表示します。パネルはキーを暗号的に検証します：署名、ドメインへの紐付け、有効期限を確認します。
config.php の APP_URL 定数から取得し、ホスト名のみを入力してください。https:// や www プレフィックスは付けません。有効化は一度限りです：コードは入力したドメイン用のライセンスに変換され、再度有効化することはできません。ドメインを間違えるとキーがお使いのパネルに合わず、コードは消費されてしまいます。そのため、ドメインは慎重に入力してください。
パネルの主要な設定はすべて、ルート（public/ フォルダと同じ階層）にある単一の config.php ファイルに、通常の define() 定数として記述されています。ファイルはインストール時に作成され、手動で編集する機会はまれです。主にドメイン変更、移行、別のデータベースへの接続時に限られます。編集後は必ず PHP-FPM を再起動してください（そうしないと OPcache により変更が反映されません）。
ハイライトされた箇所にご自身の値を入力し、それ以外はそのままにしてください。
データベース。 MySQL/MariaDB への接続情報です。
DB_HOST — DBMS のホスト。ほぼ常に localhost；DB_NAME — パネルのデータベース名；DB_USER — DB ユーザー（自分のデータベースにのみアクセス可）；DB_PASS — このユーザーのパスワード；DB_CHARSET — 接続の文字コード。utf8mb4 のままにしてください。アプリケーション。
APP_URL — パネルの完全なアドレス（例：https://monitor.example.com）。ライセンスを有効化したドメインと一致している必要があります。一致しない場合はキーが拒否されます（「ライセンス」の項を参照）；TIMEZONE — PHP のタイムゾーン：パネルが日時を表示する方法にのみ影響します。cron ジョブの実行時刻には影響しません。そちらはシステムのタイムゾーンが適用されます（「すべての cron ジョブ」を参照）。セッション時間。 SESSION_LIFETIME — セッションのアイドルタイムアウト（秒単位。スライド式：操作するたびに更新）。デフォルトは 28800 = 8時間で、この時間操作がないとパネルは再ログインを求めます。例：3600 = 1時間、86400 = 1日。
エラーのログ記録。 エラーが訪問者に表示されることはなく、logs/php_errors.log に記録されます。「アプリケーションログ」ページで確認できます。これらの行（display_errors=0、log_errors=1、error_log のパス）は通常変更する必要はありません。設定はファイル内に直接記述されており、php.ini に依存しません。
public/ と同じ階層）にあり、このパネルの Web ルート（DocumentRoot）は public/ ではなくパネルのルートそのものです。ファイル自体が「漏洩」することはありません。ルートの .htaccess にこのファイルへの明示的な拒否設定（Require all denied）があり、サーバーは 403 を返します。このルールがなくてもソースは漏洩しません。これは PHP であり、サーバーはテキストとして返すのではなく実行するからです。念のため：公開リポジトリに置いたり、実際のパスワードを含めたままサポートに送ったりしないでください。ファイルの権限は 640 です。
UFW（Uncomplicated Firewall）は nftables/iptables への簡単なインターフェイスです。明示的に許可したポート以外の受信ポートをすべて閉じます。「UFW ファイアウォール」ページでは状態とルールを確認できます。
ufw enable の前に必ず SSH を許可してください（ufw allow OpenSSH）。さもないとサーバーへのアクセスを失います。
deny ルールで閉じたポートは外部からアクセス可能とは見なされません。
Skipping adding existing rule はエラーではありません。 同一のルールがすでに存在するため重複して追加しないことを UFW が知らせているだけです。自動設定を再実行した場合（冪等です）、これは通常のメッセージなので対応は不要です。
ログイン失敗の回数が上限を超えたIPを自動的にブロックします。SSH、nginx、Apache などのサービスのログを解析します。
基本インストールは上記を参照。ここでは、数十のアクティブな jail と数千のブロックを実現する実用構成を紹介します。全体設定、主要な jail、そして ipsum リストによる悪質な IP の自動 ban です。
/etc/fail2ban/jail.local ファイル — 全体設定と重要な jail:
ignoreip には必ず自分の IP と信頼するネットワークを記載してください。そうしないと自分自身を ban してしまう恐れがあります。編集後: sudo fail2ban-client reload。
ipsum ブロックリストの自動読み込みは root の cron に設定します (sudo crontab -e): level 1 (10万以上の IP) が ipsum セットに読み込まれ、ファイアウォールで遮断されます (詳細は「IPset ブロックリスト」セクションを参照):
ipsum でなければなりません — ダッシュボード (「IPset ipsum」カード) が読み取るのはこの名前です。レベル: levels/1.txt は最大カバレッジ、levels/3.txt はより高精度 (3つ以上の情報源)。
「セキュリティモニター」が2つのゾーンに分かれている理由。 保護は2つのレベルで機能しており、ダッシュボードは両者を混同しません:
sshd、apache-*、nginx-* などの jail) と悪質な常習犯 (recidive jail — すでに複数回 ban された相手)。これらは実際にあなたのサーバーへ侵入を試みた IP で、攻撃マップや「タイムライン」に表示されます。ipset ipsum で、ファイアウォールの DROP ルールで遮断されます。これらのアドレスは大半があなたのサーバーに触れてすらいません — 事前に遮断されます。「IPset ipsum」カウンターは、予防的に遮断された数を表示します。違いはシンプルです: リアクティブは「攻撃してきて ban された相手」、プロアクティブは「試行前にブロックされた相手」です。以前は recidive に ipsum の list-3 を人為的に流し込んでいました (これが旧来の「リスト型 recidive」区分の由来です)。現在の recidive は本物の常習犯のみで、予防的ブロックはすべてファイアウォール側にあります。
ipsum は、毎日更新される公開の悪意あるIPリストです。モニターはダッシュボードと攻撃マップに読み込んだアドレス数を表示し、セキュリティ評価に反映します（セットが未読み込みの場合は −10）。
fail2ban を使わない最小構成では、専用セット ipsum を作り iptables でブロックします:
@reboot に登録してください。同時に create … -exist コマンドで上限 maxelem 300000 を指定します（デフォルトの65536では level 1 が収まらず「Hash is full」になります）:
ipsum に読み込み、ファイアウォールをインストーラーが管理している場合（新規VPS — プロファイル「フル」／「軽量」）は DROP ルールでセットを UFW に接続します — これらのIPからのトラフィックは実際にブロックされます。ルールは ESTABLISHED,RELATED の後に置かれるため、現在の接続（SSHを含む）は切断されず、リスト上のIPからの新規接続のみが遮断されます。セットはサービス ipsum-load.service の起動時にファイアウォールより前に復元され（そうでないとUFWが起動できません）、cronで04:00に更新されます。すでに設定済みのサーバー（パネルや独自ファイアウォール）では、インストーラーはファイアウォールに手を加えません — そこでは ipsum はダッシュボードと攻撃マップ用のリストとして残り、必要なら DROP ルールを手動で追加します（iptables … --match-set ipsum … -j DROP による最小構成は上記）。自動インストールでは手動で行うことは何もありません。
集合知による threat intelligence を備えた Fail2ban の最新の代替。コミュニティによるブロックに加え、独自ルールも利用できます。ブロックをファイアウォールに適用するには別途 bouncer が必要です。
systemctl is-active crowdsec で確認します）。起動するには sudo systemctl enable --now crowdsec。落ちる場合は sudo journalctl -u crowdsec -n 30 を確認。「未起動」ステータスのあらゆるサービス（Suricata、Falco、Monit、MySQL）にも同じ手順が当てはまります。
stream halted / ブロックが適用されない。 これは孤立した api キーです。bouncer は cscli bouncers list から削除されたのに、古いキーが /etc/crowdsec/bouncers/*.yaml に残っています。bouncer を再登録し、新しいキーを記入してください:
AIDE（Advanced Intrusion Detection Environment）はファイルシステムのスナップショットを取得し、チェックのたびに /etc、/bin、/usr の変更を報告します。インストール後はデータベースの初期化（aideinit）が必須です。
aideinit の実行中、ターミナルは 5〜15分間 Running aide --init... の行で止まりますが、これは正常です（ファイルシステム全体のハッシュ化でディスク負荷がかかります）。Ctrl+C で中断しないでください。処理が「固まった」ように見えて何も出力されない場合、隠れた確認 Overwrite existing aide.db.new [Yn]? への応答を待っている可能性があります（Y を押してください）。別セッションから動作を確認: pgrep -af aide。
aideinit のエラー:「21_aide_spamassassin … printf: invalid number」（return code 20） — Ubuntu 22.04 の AIDE 設定スニペットの既知のバグです。データベースが作成されません。壊れたスニペットを退避して再実行してください:
aideinit が実行されていないか、あるいは（Ubuntu 24.04）/var/lib/aide ディレクトリが 700 で作成され www-data からアクセスできない状態です — sudo chmod 755 /var/lib/aide で解決します（上のブロック参照）。「チェック未実施」= データベースはあるがチェックがまだ実行されていない状態で、エラーではありません。結果はモニターが /var/log/aide/aide.log から読み取ります。
/etc/cron.daily/aide は新しい Ubuntu/Debian では /var/log/aide/aide.log を必要な形式で書き込まないことがあります（それらには aide.wrapper も既にありません）。明示的な --config を指定した独自の cron を追加するほうが確実です — root がログを 644 で書き込むため、モニターは追加のグループなしで読み取れます:
chmod 755 /var/lib/aide と 02:00 のチェック cron — 手動での作業は不要です。
sudo aideinit && sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db。
Linux 向けのアンチウイルススキャナーです。/var/www を PHP シェルや悪意あるコードについて検査するのに特に役立ちます。
enable --now の後も clamd デーモンが「非アクティブ」と表示される？ よくある原因は3つです:
1. 設定に Example 行が残っている — この行があるうちは clamd は起動を拒否します:
2. シグネチャデータベースがダウンロードされていない — これがないと clamd は起動しません:
3. 単に読み込み中 — clamd は約800万件のシグネチャをメモリに30〜60秒かけて読み込みます。待ってから確認してください: systemctl is-active clamav-daemon（ステータスが activating → まだ読み込み中）。
sudo journalctl -u clamav-daemon -n 30 --no-pager。
clamd デーモンはシグネチャをメモリに保持するだけで、スケジュールに従って自らスキャンすることはありません。パネルは定期スキャンの結果を表示するため、スキャンしてログを書き込む cron が必要です。自動インストールではラッパー /usr/local/bin/clamav-scan.sh と01:30の cron を設定します — 初回実行後に「検査済みファイル」と「最終スキャン」が埋まります。スケジュールを待たずにすぐ実行するには: sudo /usr/local/bin/clamav-scan.sh。
Linux Malware Detect (LMD) — Web の脅威に対応したマルウェアスキャナーで、PHP シェル、Web バックドア、ダウンローダーを検出します。ClamAV エンジンを利用し、独自のシグネチャで補完します。
maldet --report。
update-rc.d: error: unable to read /etc/init.d/maldet という行が表示されることがありますが、問題ありません。maldet は init.d を使わず、シグネチャ更新とスキャンは /etc/cron.daily/maldet から実行されます。下に installation completed と表示されていれば、正常にインストールされています。
apt ではなく /usr/local/maldetect にインストールされ、open_basedir が有効な場合は shell 経由で存在を確認します。「サーバーにデータがあるのにページが空」のセクションを参照してください。
ネットワーク型侵入検知システム。トラフィックをパケットレベルで解析し、数千種類の攻撃シグネチャを認識します。ModSecurity を補完します（ModSecurity は HTTP レベル、Suricata は TCP/IP レベルで動作）。
/var/log/suricata/eve.json を root 権限でディレクトリのパーミッション 750 で書き込むため、Web サーバー（www-data）が読み取れません。ディレクトリに通過権限を付与してください。内部のファイルは保護されたままです:
eBPF／カーネルモジュールを通じてシステムコールを捕捉し、異常をリアルタイムで検出します。nginx からの shell 起動、Web プロセスによる /etc/passwd の読み取り、/bin への書き込みなど。
journalctl -u falco を通じて Falco のイベントを読み取ります（sudo なし — systemd-journal グループ経由）。www-data がこのグループに属していることを確認してください。手動インストールページの「sudo の設定」（項目2）を参照してください。
/etc/passwd の読み取り、システムディレクトリへの書き込み）。平穏なサーバーで1日あたり重大イベントがゼロなのは健全な状態です。
journalctl 経由の読み取りにはジャーナルへの権限が必要です。パネルが安定してイベントを見られるよう、自動インストールでは Falco の file_output → /var/log/falco/falco.log を有効化し、サービスに UMask=0022 を設定します（ログは Web サーバーから読み取れます）。新規インストールでは手動で設定する必要はありません。
ModSecurity は Apache または Nginx 向けの Web ファイアウォール（WAF）です。SQL インジェクション、XSS、パストラバーサル、スキャナーなど、アプリケーション層への攻撃をブロックします。
IncludeOptional /etc/modsecurity/*.conf という行で設定を読み込みますが、パッケージが配置するのは modsecurity.conf-recommended だけで、*.conf のマスクには一致しません。これを modsecurity.conf にコピーしないと SecRuleEngine は Off のまま。モジュールは読み込まれ、CRS ルールも読み込まれますが、トラフィックは検査されず監査ログも作成されません。中間モードの DetectionOnly はイベントをログに記録するだけでリクエストをブロックしないため、パネルでは黄色で表示されます。
パネルからの監査ログへのアクセス。 ログ /var/log/apache2/modsec_audit.log は root 所有（権限 640）で、Web ユーザーは読み取れません。パネルはラッパー経由でデータを取得します。次のように作成してください:
SecRuleEngine ディレクティブを取得します。インデントされた行は <LocationMatch>／<Directory> ブロック内（例えば phpMyAdmin での WAF 無効化）にあり、グローバルモードは決定しません。www-data ですが、HestiaCP ではサイトのプールがサイト所有者（例えば admin）で動作します。grep -E '^user' /etc/php/*/fpm/pool.d/monitor.example.com.conf で確認してください。X-Forwarded-For ヘッダーから取得します。統計にはルールが発動したトランザクションのみが含まれます。SecAuditLogRelevantStatus ディレクティブは 4xx/5xx のあらゆる応答を監査ログに記録するため、通常の 403/500 もそこに入りますが、パネルはそれらを WAF イベントとは見なしません。---RULES--- ブロックは「すべての有効なルール」セクションに必要です。パネルは発動したものだけでなく、読み込まれたすべての CRS ルールとカスタムルールを表示します。ループ for f in … 内の 3 つのパスは、CRS ルールとローカルの追加分の典型的な配置先です。別の構成の場合（パッケージが独自のディレクトリにファイルを配置する、またはカスタムルールが /etc/modsecurity/custom-rules.conf 以外にある）は、sudo grep -rl 'IncludeOptional\|^Include ' /etc/apache2/mods-enabled/security2.conf /etc/apache2/conf-enabled/*.conf 2>/dev/null コマンドで実際のパスを見つけてリストに追加してください。ラッパーが古い場合（このセクションがない場合）は、セクションに「利用不可」という警告が表示されるだけで、ページの他の部分は従来どおり動作します。
Auditd（Linux Audit Daemon）はカーネルレベルでシステムコールを記録します。ログインとログアウト、sudo コマンド、認証の失敗、ファイルの変更などです。モニターは当日のログイン、失敗した試行、sudo コマンドを表示します。
ausearch（/usr/sbin/ausearch）でイベントを読み取り、必要に応じて tail コマンドで /var/log/audit/audit.log からも読み取ります。両方とも sudoers に登録されている必要があります。
サービス（nginx、php-fpm、mysql など）を監視し、ダウン時に再起動します。email でアラートを送信できます。
monit status でサービス一覧を取得します。/etc/monit/monitrc で HTTP インターフェース（allow localhost を含む set httpd ブロック）を有効にする必要があります。そうでないと monit status がエラーを返します。
monitrc の set httpd 行がコメントアウトされている（デフォルトでは # set httpd port 2812 … となっています）。ブロックのコメントを解除し、localhost を許可してください。(2) httpd を有効にしただけでは何も監視されません — Monit は check スタンザで記述したものだけをカウントするため、それがなければインターフェースが動作していても一覧は空です。最小限の動作設定:
conf.d が配置されます。新規インストールでは手動設定は不要です。
PSAD は iptables のログを解析してポートスキャンやネットワーク攻撃を検出し、送信元ごとに脅威レベル（1〜5）を割り当てます。fail2ban と Suricata を補完します。
psad --Status 経由でデータを読み込みます（sudoers への登録が必要）。iptables のロギングがない場合、ページは空になりますが、スキャンがまだ発生していないだけなので正常です。
Mandatory Access Control は、プログラムが侵害された場合でも、そのプログラムがアクセスできるファイルやリソースを制限します。Ubuntu/Debian では標準で AppArmor が使われます（通常はすでにインストール・有効化済み）。
aa-status でステータスを読み取ります（sudoers への登録が必要）。enforce/complain モードのプロファイル数と、プロファイルのないプロセスを表示します。
「読み込み済みプロファイル」が enforce + complain より多くても正常です。 AppArmor 4.x（Ubuntu 24.04 以降）では unconfined モードが導入されました。プロファイルはカーネルに読み込まれていますが、何も制限しません。Ubuntu は、user namespaces を使うプログラム（ブラウザ、torrent クライアントなど）のプロファイル数十個をこの状態にしています。こうしたプロファイルがあると、「読み込み済みプロファイル」カードは琥珀色になり、その数を表示します。例えば読み込み済み 120、enforce 26 に対して unconfined: 90 のように表示されます。実際に保護しているのは enforce のプロファイルだけです。Ubuntu 22.04（AppArmor 3.x）にはこのモードがなく、数値は常に一致します。
unconfined のままにしているプロファイルを enforce に切り替えるのは、十分に理解した上で行ってください。これらは誤って無効化されているのではなく、enforce にするとプログラム自体が動かなくなるためです。complain のプロファイルは別で、ルールはすでに書かれており、適用されていないだけです。
debsums は、インストール済みパッケージのファイルがリポジトリのチェックサムと一致するかを検証し、改ざんされたシステムバイナリを検出します（AIDE を補完）。完全スキャンには 1〜2 分かかるため cron で実行し、パネルは data/debsums/debsums.log から結果を読み取ってカテゴリ別に自動整理します（重要なのはバイナリとライブラリのみ）。
ジョブは root の cron（sudo crontab -e）に登録します。既製のラッパー debsums-scan.sh を /usr/local/bin/ に配置し（chmod +x。cron ジョブ一覧を参照）、レポートはパネルの data/debsums/ へ自動的に書き込まれます。
ラッパー debsums-scan.sh はパネルの data/ を自動検出するため、パスを指定する必要はありません。
/etc/（設定ファイル）や /usr/share/（リソース）の変更は通常は問題なく、パネルは別の色で表示します。警戒すべきはバイナリやライブラリ（/bin、/sbin、/usr/lib など）の変更で、「バイナリ / ライブラリ」カードにはまさにそれらが表示されます。
Lynis は手動または cron で実行します。レポートはプロジェクトの data/lynis/ フォルダに保存する必要があります。モニターは lynis-report.dat ファイルを読み取ります。
lynis-scan.sh をバックグラウンドで実行します。「スキャン中…」と表示し、完了すると自動でレポートを更新します。そのためには、Web ユーザーがスクリプトを実行できる sudoers 行が必要です。インストーラーが /etc/sudoers.d/monitor に自動で追加します。パネルを手動で／以前にインストールした場合は、ファイルにすでに指定されているユーザーで同じ行を追記してください:
Logwatch は日次レポートをプロジェクトの data/logwatch/ フォルダに .txt 形式で保存する必要があります。モニターは最新レポートとアーカイブを表示します。
ネットワークモニターはインストール不要で、ダッシュボードに組み込まれたページです。ローカルソースからサーバーのネットワーク状態を表示します:
/proc/net/dev から;ip 経由;ss 経由;journalctl -k 経由。最初の3つのソースは sudo なしで動作するため、インターフェース、トラフィック、接続、ポートはすぐに表示されます。「カーネルイベント」ブロックは journalctl -k を使用し、systemd-journal グループ経由で読み取られるため（「sudo の設定」、項目2）、sudo は不要です。すべてが Web ユーザーからアクセス可能か確認するには:
UFW BLOCK エントリはここには含まれません — それらは「ファイアウォール UFW」と「攻撃マップ」ページにあります。緑のチェックマーク付きの空ブロック = 24時間以内にネットワーク障害はありませんでした。
組み込みのページには 3 つの情報が表示されます。
df）。90% 以上でゲージが赤くなります。lsblk）。実デバイスのみ（loop/snap は非表示）。smartctl）。空き容量とデバイス一覧は設定不要ですぐに動作します。SMART には smartmontools パッケージが必要です。Web プロセスはディスクデバイスへ直接アクセスできないため、SMART は cron 経由で data/disk/smart.txt ファイルに取得され、ダッシュボードがそれを読み取ります。
ジョブは root の cron に登録します（sudo crontab -e）。既製のラッパー smart-scan.sh を /usr/local/bin/ に配置し（chmod +x、cron ジョブ一覧を参照）、ラッパー自身がダッシュボードの data/disk/ に書き込みます。
ラッパー smart-scan.sh はダッシュボードの data/ を自動で見つけるため、パスの指定は不要です。内部で lsblk -e7,11 により loop/cdrom を除外しています。
このページは直近24時間のサーバー負荷履歴を表示します。Load Average、CPU使用率とI/O待ち、RAM/Swap、ネットワークトラフィック（受信/送信）、ディスクI/O（読み取り/書き込み）、ディスクとinodeの使用状況、開いているファイルディスクリプタとMySQL接続数、加えて現在のTCP接続数とプロセス数を確認できます。
データは cron/collect_metrics.php が収集します。5分ごとにカウンタの「生の」スナップショットを1件（/proc/loadavg、/proc/meminfo、/proc/stat、/proc/net/dev、/proc/diskstats、df/df -i、/proc/sys/fs/file-nr、SHOW GLOBAL STATUS LIKE 'Threads_connected'）データベースの system_metrics テーブルに書き込みます。パーセンテージと速度は、隣接するスナップショットの差分からページ自身が計算します（ディスク/inode/ディスクリプタ/MySQL接続の使用状況は瞬時値で、再計算は行いません）。root権限は不要で、ソースはroot権限なしで読み取れます。24時間より古いポイントは書き込みのたびに自動削除されます。
ラッパー collect-metrics-all.sh（cronタスク一覧を参照）は、サーバー上にインストールされたすべてのパネルインスタンスを自動検出し、各インスタンスの cron/collect_metrics.php をサイト所有者の権限で実行します。
負荷アラート（「設定」→「負荷アラート」）— CPU/RAM/ディスク/inodeがしきい値を超えると、パネルはTelegram/Emailに通知を送信し（日次レポートと同じチャネルで、アラート用に別途有効化する必要はありません）、メトリクスが正常に戻ったときにもう1件送信します。しきい値を超えている間の再送でスパムにはなりません。次の通知は「復旧→再度超過」のサイクル後にのみ届きます。
collect_metrics.php が実行ごと（5分ごと）にチェックするため、別途cronは不要です。「通知済み/未通知」の状態は data/alerts_state.json に、しきい値はパネルの設定に保存されます。
「攻撃マップ」ページは geoiplookup コマンドで IP から国を判定します。GeoIP パッケージがないと国は判定できず、マップ上に点は表示されません:
/usr/share/GeoIP/GeoIP.dat は全ユーザーが読み取り可能で、結果は tmp/geoip_cache.json にキャッシュされます。マップ本体（Leaflet + OpenStreetMap タイル）はブラウザで読み込まれるため、ダッシュボードを開くコンピューターにはインターネット接続が必要です。
ダッシュボードに組み込まれた2枚のカードで、ツールの「オン/オフ」ではなく、サーバーの実際の防御状態を表示します。インストール不要、sudoなしでローカルに読み取ります。
外部への露出 — 全インターフェース（0.0.0.0/[::]）で待ち受けし、外部からアクセス可能なサービスの数です。DBMSやキャッシュ（MySQL、PostgreSQL、Redis、MongoDB、Memcached、Elasticsearch）が外部に露出している場合は赤で強調表示されます — これは直接的な穴です（セキュリティ評価に−10）。ソース: ss -tuln。
127.0.0.1 にバインドするか（MySQL/PostgreSQL設定の bind-address、Redisの bind 127.0.0.1）、UFWでポートを閉じてください。
127.0.0.1（loopback）で待ち受けするサービスはサーバー自身にしか見えず、ポートが「開いて」いても外部からはアクセスできません。そのため、loopbackにバインドされたポート25のPostfixは安全です: 自動設定が inet_interfaces = loopback-only を設定します（加えて中立的な smtpd_banner により、バージョン漏洩に関するLynisの指摘 MAIL-8818 を解消します）。「外部への露出」カードは 0.0.0.0/[::] で待ち受けするものだけを外部としてカウントし、loopbackサービスは含まれません。
/etc/postfix/main.cf に smtpd_banner = $myhostname ESMTP（バージョンとOSなし）と inet_interfaces = loopback-only を設定し、その後 sudo systemctl restart postfix を実行します。
セキュリティアップデート — インストール待ちのセキュリティパッチの数と、カーネル更新後に再起動が必要かどうかを示します（パッチがある場合、セキュリティ評価に−5）。ソース: /usr/lib/update-notifier/apt-check、ファイル /var/run/reboot-required。詳細な一覧は「セキュリティアップデート」ページにあります。
update-notifier-common）。apt-check がない場合、モニターは apt-get -s upgrade でパッチを数えます。
セキュリティ自動アップデート（unattended-upgrades） — 「セキュリティアップデート」ページの専用カードで、セキュリティパッチの自動インストールが有効かどうか、最後に実行されたのがいつかを表示します。sudoは不要で、ステータスは apt-config dump で読み取ります。
バックアップは最大の保険です。データの喪失はどんな侵入よりも深刻です。必要なものは2つ——サーバー／サイトのバックアップと、それとは別にパネルのDBのバックアップ（ユーザー、WebAuthnキー、設定、ライセンスが含まれます）です。
方法A — HestiaCP：ユーザーのBackupタブ → バックアップ作成ボタン（またはサーバー設定でスケジュール実行）。バックアップにはサイトとそのDBが含まれます。
方法B — 手動（cron）：DBのダンプ＋パネルのdata/ディレクトリのアーカイブ：
新しいバージョンへのアップデート。 まずバックアップを取ってください。その後、データを保持したままコードファイルを上書きします。
public/、includes/、assets/、cron/、database/、およびルートの .htaccess（フロントコントローラー — ルーティングを旧バージョンのまま残してはいけません）、manifest.json、sw.js;config.php（DB情報）、data/（レポート）、logs/、tmp/（セッションとキャッシュ）。SSH_FX_PERMISSION_DENIED（Permission denied）と表示する場合。 パネルのファイルは www-data の所有です（インストール時にそう設定されています）が、SFTP クライアントは書き込み権限のないご自身のユーザーで接続しています。「動かすため」にパネル全体を www-data に渡すことこそ、まさにこのエラーを招く原因です。以下の 3 つの方法のいずれでも問題は解決します。
data/（レポート）、tmp/（セッションとキャッシュ）、logs/。これらは www-data の所有のまま残ります。残りはコードで、Web サーバーには読み取りだけが必要で、それは 644 の権限を持つ www-data グループが与えます。副次的な利点として、PHP に脆弱性があってもパネルのファイルはもう書き換えられません。ホスティングパネル（HestiaCP など）では方法 A は不要です。そこではサイトのファイルはもともと SFTP で接続するアカウントの所有であり、Web サーバーはグループ経由で読み取ります。
chmod を実行すると ACL マスクがリセットされ、アクセスが黙って失われます。「権限を整理」した後にアップロードが再び Permission denied で止まる場合は、両方の setfacl コマンドを再実行してください。
2 が setgid です。SFTP でアップロードしたファイルは www-data グループに残り、そうでなければパネルは上書きできません。方法 C の後は FileZilla で接続し直してください — 新しいグループは新規ログイン時にしか反映されません。確認: id deploy（www-data グループが表示されること）と ls -ld /path/to/monitor（drwxrwsr-x — 文字 s は setgid が設定されていることを示します）。
別サーバーへの移行:
config.php、data/ とともにコピーします。mysqldump → 新サーバーでインポート。config.php のDB情報を修正してください。adm グループへの所属、cronジョブ。ログインできない場合は、サーバー上のデータベースで直接修復できます。データベースを開いてください（データベース名は config.php から）：
WebAuthn のセキュリティキーを紛失した（第二要素が通らない）場合は、2FA を無効化し、パスワードでログインして新しいキーを登録してください：
パスワードを忘れた場合は、新しいハッシュを設定してください（サーバー上で生成して置き換えます）：
IPフィルターで自分を締め出した場合は、制限を無効化してください：
sudo mysql、または phpMyAdmin / ホスティングパネルのデータベース欄から。復旧後は WebAuthn と IPフィルターを再度有効化してください。
ジョブの一覧はサーバーの root crontabに記述します（sudo crontab -e で追加）。使用するツールの行だけを残し、パスは自分のサーバーに合わせて調整してください。
sudo crontab -l、そして cron サービスが有効であること。
config.php の TIMEZONE ではありません。 定数 TIMEZONE は PHP にのみ影響します（パネルが日付をどう表示するか）が、cron デーモンは OS のシステム時刻でジョブを実行します。サーバーのタイムゾーンが自分と異なると、「08:00」のレポートは違う時刻に届きます。例: サーバーが別のタイムゾーン（Asia/Shanghai, UTC+8）にあり、あなたは東京（UTC+9）にいる場合 →「08:00」のレポートはあなたの時刻で 09:00 に届きます。確認し、必要ならシステムのタイムゾーンを自分に合わせてください:
0 8 * * * の行は現地時間の 08:00 に実行されます。そうでなければ cron 自体をずらすことになりますが、冬時間/夏時間の切り替え時に再びずれてしまいます — そのためシステムのタイムゾーンを設定するのが正しいやり方です。
crontab.txt）は、プロジェクトの隣、public_html の外にある system/ フォルダにあります。これはサイトの一部ではなく、web ルートにアップロードする必要はありません。サーバー上のシステムパスに配置してください（上記 crontab のとおり）:
lynis-scan.sh → /usr/local/bin/（chmod +x）— lynis audit system を実行し、スキャン中はフラグ /tmp/lynis-running を立て、lynis-report.dat をパネルの data/lynis/ にコピーします。logwatch_daily.sh → /usr/local/bin/（chmod +x）— 日次の Logwatch レポート（sshd, fail2ban, sudo, postfix）を data/logwatch/ に生成します。smart-scan.sh → /usr/local/bin/（chmod +x）— ディスクの状態（smartctl）を data/disk/ に取得します。debsums-scan.sh → /usr/local/bin/（chmod +x）— パッケージ整合性（debsums）を data/debsums/ でチェックします。clamav-scan.sh → /usr/local/bin/（chmod +x）— 危険なパス（web, home, temp）を対象とした ClamAV アンチウイルススキャン。サマリを /var/log/clamav/scan.log に書き込み、そこから ClamAV ページが読み取ります（上記 crontab の 01:30 の行）。load-ipsum.sh → /usr/local/bin/（chmod +x）— ipset の ipsum セット（level 1）をその場で更新し、有効なファイアウォール規則を壊さない（上記 crontab の 04:00 行）。daily-report-all.sh → /usr/local/bin/（chmod +x）— パネルのレポート cron/daily_report.php を実行します（上記 crontab の 08:00 の行）。daily_report.php — すでにパネルに含まれており（cron/daily_report.php）、daily-report-all.sh 経由で実行されます。個別に設置する必要はありません。collect-metrics-all.sh → /usr/local/bin/（chmod +x）— パネルの cron/collect_metrics.php を実行します（「パフォーマンス」ページ、上記 crontab の */5 の行）。collect_metrics.php はすでにパネルに含まれており、個別に設置する必要はありません。crontab.txt (system/cron/) — ジョブのサンプル。必要な行を sudo crontab -e で記述してください。/usr/local/bin/ に置く方法。 FileZilla から直接そこへ書き込むことはできません — ディレクトリは root の所有で、SFTP クライアントは SSH_FX_PERMISSION_DENIED を受け取ります。手順はこうです: まずファイルを /tmp にアップロードし（そこは誰でも書き込めます）、次に一つのコマンドで所定の場所へ移します:
/tmp であり、/var/tmp でもパネル内の tmp/ でもありません（後者は www-data の所有で、あなたのユーザーからはアクセスできません）。FileZilla のツリーでは /tmp は最上位のブランチで、var の隣にあり、その中ではありません。
/usr/local/bin/、ログは /var/log/arciveo-cron.log）— 手動で行うことは何もありません。
/home/*/web/*/public_html と /var/www/* を巡回してパネルのインストールを見つけ、レポートをその data/ に置きます。パネルが別のパスにある場合は、スクリプト内の for app in … の行に追加してください。そうしないと Lynis/SMART/debsums/Logwatch のレポートがパネルに反映されません。
logs/cron.log を最初に作成するのは root crontab です — root の所有となり、パネルの「cron ログ」タブはそれを読むことも消去することもできなくなります。事前に web ユーザー（サイトディレクトリの所有者。HestiaCP ではアカウント、例: admin）としてファイルを作成しておいてください — そうすれば root crontab は所有者を変えずに追記するだけになります:
stat -c %U /path/to/monitor。
sudo crontab -e）。でないと二重に実行されます。
sudo crontab ではなく（それではパネルのセッションにアクセスできた誰でもが root へ直接昇格できてしまいます）、2 つのコマンド（list/set）だけを持ち、サービスコメントで区切られた自分のブロックのみを操作する限定的なスクリプトです。一度だけインストールしてください:
www-data と異なる場合があります — サイトの PHP-FPM プールがどのユーザーで動作しているかを確認し（ps -o user= -C php-fpm）、それを sudoers の行に指定してください。
public/crontab_monitor.php が、サイトの他のファイルとは別のシステムユーザー（例: root）で FTP/SFTP 経由でアップロードされると、web サーバーはそれを読めません。隣接ファイルと所有者・権限を照合して合わせてください:
モニターは dpkg-query（APT のパッケージデータベース）でツールの有無を判定します。apt 以外の方法（手動、snap、ソースからのビルド）でインストールした場合、dpkg では認識されません。
500 エラー — PHP、nginx、およびモニター自体のログを確認してください:
www-data ではなく ユーザーアカウント（例えば admin — サイトディレクトリの所有者）で動作します。すべての sudo ルールとグループ所属（adm、systemd-journal）は このユーザーに対して設定する必要があります。さもないとサービスが稼働していてもモジュールが「非アクティブ / 0」と表示します。実際の PHP ユーザーを調べるには: ps -o user= -C php-fpm | sort -u またはサイトディレクトリの所有者 stat -c '%U' /path/to/monitor。以下のすべてのコマンドで www-data の代わりにそれを使用してください。自動インストールはウェブユーザーを自動的に判別し、それに対して sudoers を設定します。
データが表示されない — ほとんどの場合 sudo 権限が未設定です。ウェブユーザーとして具体的なコマンドを確認してください（www-data を自分のユーザーに置き換え）。フラグ -n = パスワードなし（PHP と同じ）— パスワードを求められる場合、sudoers にルールがありません:
sudo aa-status はプロファイルを表示するのに「AppArmor」ページは「非アクティブ」）。原因: ウェブユーザーにそのモジュールのコマンドに対する sudo 権限がありません。上記の一覧から確認してください: パスワードを求められる場合、不足している行を /etc/sudoers.d/monitor に追加してください（「sudo の設定」）。よくある「新しい」コマンド: /usr/sbin/aa-status（MAC）、/usr/sbin/psad --Status（PSAD）。
apache2ctl、ausearch、aa-status、ss が許可されていないか、ウェブユーザーが adm/systemd-journal グループに属していません（そこから fail2ban/auth/modsec のログと journalctl — Falco とカーネルイベント — が読み取られます）。
症状：サーバーにはデータがあり（shell では見える）、ページには「データなし」または誤ったステータスが表示される。たとえば AIDE のデータベースは作成済みなのに「未初期化」と表示される。
原因は open_basedir です。多くのパネルやホスティングは PHP-FPM プールをドメインのディレクトリに制限するため、システムパス（/var/lib/aide、/var/log、/proc など）に対する PHP 関数 file_exists()、file_get_contents()、filemtime() がブロックされます。モニターはこうしたパスを標準のシステムコマンド（cat、test、stat）で読み取ることで回避します。
open_basedir です。正しい対処はシステムコマンドでの読み取りです（AIDE とネットワークモニターでは対応済み）。open_basedir を /var や /proc に拡張する必要はなく、安全性も下がります。
モニターはポート443経由でドメインに直接接続して証明書を確認します。サーバー自体からドメインにアクセスできない場合や、ポートがファイアウォールで閉じられている場合は、確認が失敗します。
/etc/nginx/sites-enabled/、/etc/nginx/conf.d/）とApache（/etc/apache2/sites-enabled/）から自動で取得し、さらにHTTP_HOSTの現在のホストも含めます。
モニターはconfig.phpのユーザーでMySQLに接続しますが、そのユーザーは自分のデータベースにしかアクセスできません。MySQLはinformation_schemaに権限のあるデータベースのみを表示するため、それ以外は見えません。
モニターにすべてのDBを表示させるには、このユーザーに読み取り専用の権限を付与してください（rootで一度だけ実行し、config.phpのユーザー名に置き換えてください）：
sudo mysqlを使用しません。データベースの一覧は独自のPDO接続で取得しています。
PostgreSQL には postgres ユーザー権限が必要ですが、パネルの Web ユーザーにはこの権限がありません。PHP から広い権限の sudo psql を開くのは危険です。代わりにパネルは、パラメーターなしの限定的なラッパーを呼び出し、バージョン・接続数・サイズ付きのデータベース一覧のみを出力します。これを作成してください:
monitor-pgstat の行を削除し (手動インストールの手順 13)、スクリプト自体も作成しないでください: PostgreSQL のカードは非アクティブのまま表示されます。
ダッシュボードは何が起きているかを示します。以下は典型的なケースでどう対処するかです。基本方針は、慌てず、正規のアクティビティ（自分の操作、更新、バックアップ）と照合し、深刻度に応じて対応することです。
ignoreip にあることを確認してください。/etc 外、/usr/share 外）— 改竄の可能性があります。パッケージを照合し（debsums PACKAGE_NAME）、疑わしければ再インストールしてください（apt install --reinstall）。127.0.0.1 にバインドするか、UFW でポートを閉じます。これは実際の穴です。certbot renew やダッシュボードの設定を確認してください）。sudo apt update && sudo apt upgrade。カーネル更新後はサーバーを再起動してください。