これは Arcivéo Security Monitor のインストール・設定・運用に関するガイドです。 各セクションは、全体概要、ダッシュボードの導入、セキュリティツールの接続、 組み込みモジュール、診断の順にまとめられています。コマンドは右側のボタンでコピーできます。
パネルのインストール手順は、ステップごとの個別ページにまとめています。方法を選択してください：
Arcivéo Security 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 全体へのアクセスはありません。結果は解析されてブラウザーに表示されます。
二つのリズム。 パネルの各ページは開いたその時点でツールに問い合わせます。したがって常に現在の状態が表示されます。それとは別に、スケジュール（cron）で動く裏方の処理があります。
ジョブの一覧は「すべての cron ジョブを一箇所で」の節にあります。
スコアは満点から始まり、検出された問題ごとに減点されます:
PermitRootLogin yes） — −20PasswordAuthentication yes） — −10X11Forwarding が有効、MaxAuthTries が 3 を超える、または sshd_config を全アカウントが読める — −5TRACE メソッドが有効、または Strict-Transport-Security や X-Frame-Options ヘッダーがない — −5結果: 80以上 = 保護済み、60〜79 = 要注意、<60 = 危険。
WebAuthn はハードウェアキーによるパスワード不要の認証規格です。YubiKey、Touch ID、Face ID、Windows Hello、Passkey に対応します。
パスワードでのログイン後、登録済みのキーによる確認が求められます。パスワードが漏洩しても、物理キーや生体認証がなければログインできません。
設定するには、サイドメニューの WebAuthn キー を開き、「キーを登録」をクリックします。キーは一度に2つ登録してください。唯一のキーを紛失または破損すると、そのキーでのパネルへのログインができなくなります。
チャネルは四つあります。Telegram、メール、Webhook、そしてブラウザーへのプッシュです。互いに独立しているので、好きなものだけでも、四つすべてでも有効にできます。日次のセキュリティレポート、負荷アラート、イベントセンサーの検出結果も同じチャネルを通ります。設定は一度だけ、ここ「設定」で行います。
Telegram。ボットトークンと chat id が必要です:
@BotFather → /newbot に送信し、123456:ABC... の形式のトークンを取得します。@userinfobot にメッセージを送るか、https://api.telegram.org/bot<TOKEN>/getUpdates を開いて "chat":{"id":...} を探します。メール。「設定」→ メールで選べる方法は 2 つ:
re_...）と確認済みの送信元ドメインを指定します。Webhook。 POST を受け取るアドレスが一つあれば、Slack、Discord、Mattermost、n8n、そして自作のハンドラーまで賄えます。「設定」→ Webhook: アドレスを貼り付けてスイッチを入れてください。
{"text": …} を、Discord には {"content": …} を送ります（Discord は 2000 文字を超えるメッセージを拒否するため、本文は切り詰められます）。text、event、severity、source、count、host、ts。メッセージ本文を改めて解析する必要はありません。プッシュ通知。 メッセージはブラウザーに直接届きます。パネルをスマートフォンのホーム画面に追加してあれば、通常のアプリ通知として表示されます。ボットもメールサーバーも間に挟みません。「設定」→ プッシュ通知: スイッチを入れ、通知を受け取りたい端末ごとに「この端末を接続」を押します。「接続済みの端末」のカウンターで台数を確認できます。
レポートのステータス:「注意」または「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 です。
パネルはパスワードによるログインで、さらに有効にしていれば IP フィルターでも守られています。プログラムにはどちらも使えないため、外部システムには専用の入り口があります。トークンで保護された読み取り専用のアドレスが二つです。トークンはサーバー上の何も変更しません。取得できるのは数値だけです。
有効化 — 「設定」→ 「読み取り専用 API」: スイッチ「API を有効にする」。トークンは最初の保存時に自動生成されます。「新しいトークン」ボタンは別のトークンを発行し、その瞬間に以前のトークンを使っていた相手をすべて遮断します。
/api/status.php — JSON: セキュリティスコア、各モジュールの状態、上位プロセスを含む直近の負荷測定、直近24時間のセキュリティイベント。/api/metrics.php — 同じ数値を Prometheus のテキスト形式で（arciveo_* のメトリクス: arciveo_security_score、arciveo_fail2ban_banned、arciveo_cpu_busy_pct など）。クライアントがヘッダーを付けられない場合は、トークンをパラメーターとして渡すこともできます — ?token=…。ただしこの形式ではウェブサーバーのアクセスログに残るため、ヘッダーのほうが望ましいです。
Prometheus。 scrape_configs 用のそのまま使えるブロックです。
api disabled という本文を伴う 404 — 設定で API が無効になっています。拒否したリクエストは送信元 IP とともにアプリケーションログに記録されるため、トークンの総当たりは「アプリケーションログ」ページで確認できます。
パネルはサーバーごとに設置され、「このマシンの調子はどうか」にはよく答えます。しかし「自分のマシンすべての調子はどうか」には答えません。そのために、各パネルは短い要約をアカウントへ送ることができます。そこではサーバーが一つの一覧に並びます。
アカウントで用意するもの my.arciveo.com → 「マイサーバー」の節: ここでトークン（fk_… の形式）が発行され、送信先アドレス https://my.arciveo.com/api/fleet.php が示されます。トークンはアカウントにつき一つで、すべてのサーバーで共通です。
パネルで設定するもの — 「設定」→ 「サーバー一覧」: 送信先アドレス、トークン、サーバー名（一覧での表示名。空欄ならパネルのドメインが使われます）、スイッチ「要約を送信する」。「今すぐ送信」ボタンを押せば、スケジュールを待たずにその場で接続を確認できます。
以後、要約は cron により15分ごとに送信されます。
送信される内容: サーバー名とドメイン、OS、稼働時間、PHP のバージョン。セキュリティスコア。各モジュールの状態（UFW、Fail2ban の jail 数、本日の遮断件数、CrowdSec・Suricata・Falco が動作中かどうか、ClamAV の脅威、AIDE の変更、Lynis の指数、保留中の更新、再起動の要否、証明書の残り日数、危険な開放ポートの数）。直近の負荷測定（load、CPU、RAM、ディスク、inode）。直近24時間のイベント件数と、最後の重大イベント。ログもパスワードもファイルの中身も要約には含まれません。
sudo crontab -l）、そして「今すぐ送信」ボタンの応答。送信エラーは FLEET の印とともにアプリケーションログに記録されます。そこでトークンが拒否された（HTTP 401）のか、接続自体が確立しなかったのかを確認できます。
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接続数とプロセス数を確認できます。 既定は24時間の範囲です。上部のボタンで7日または30日に切り替えられます。
データは 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権限なしで読み取れます。
保存の深さは二段階。 5分ごとの「生の」スナップショットは1日分保持されます（さらに1時間の余裕を持たせ、グラフ最古の点にも計算用の直前の点が残るようにしています）。終了した各時間は1行にまとめられ、この時間単位の系列は30日保存されます。「7日」「30日」の表示が読むのはまさにこの系列です。おかげで1か月分の履歴は約8600行ではなく約720行で済みます。
ラッパー collect-metrics-all.sh（cronタスク一覧を参照）は、サーバー上にインストールされたすべてのパネルインスタンスを自動検出し、各インスタンスの cron/collect_metrics.php をサイト所有者の権限で実行します。
上位プロセス。 グラフの下には、CPU を最も消費している5つのプロセスを示す表が二つあります。
グラフが1か月を表示していても、この二つの表は常に直近24時間を示します。プロセスのスナップショットを持つのは5分ごとの行だけで、その行は1日を超えて保存されないためです。
ps、収集用の PHP スクリプト、その上の cron/sudo の連鎖）は一覧から除外されます。そうしないと毎回先頭を占めてしまうからです。ps は起動した瞬間には CPU をほぼ 100 % 使っているように見えます。同じ分に動いた他の cron ジョブはそのまま表示されます。表があるのはまさにそれを見るためです。
負荷アラート（「設定」→「負荷アラート」）— CPU/RAM/ディスク/inode のしきい値を超えると、パネルは有効なすべてのチャネル（Telegram、メール、Webhook、プッシュ。日次レポートと同じチャネルで、アラート用に別途有効化する必要はありません）で通知を送り、値が正常に戻ったときにもう一度通知します。しきい値を超えたままの間は繰り返し送りません。次の通知は「正常に戻った → 再び超えた」というサイクルのあとに初めて届きます。
collect_metrics.php が実行ごと（5分ごと）にチェックするため、別途cronは不要です。「通知済み/未通知」の状態は data/alerts_state.json に、しきい値はパネルの設定に保存されます。
日次レポートは「サーバーの調子はどうか」という問いに答えます。センサーが答えるのは別の問い — 「たった今、何が起きたのか」です。5分ごとに応答の速い情報源へ問い合わせ、前回の点検から変わった点だけを記録します。メニューの「セキュリティイベント」ページに検出結果の一覧が表示されます。
時間のかかる点検 — Lynis、debsums、パッケージ更新、SSL の有効期限 — にセンサーは触れません。これらの数値はどのみち1日1回しか変わらず、日次レポートの担当のままです。
検知する対象は九つの情報源です。
[Priority: 1] の印が付くと重大に格上げされます。FOUND 行。root でのログイン成功（重大）と、これまで見たことのないアドレスからのログイン（警告）。インストールされていないツール、あるいはパネルがログを読めないツールは、単に黙っているだけです。これはエラーでもイベントでもありません。
data/secwatch_state.json）を保持しており、初回の実行はその印を書き込むだけです。そうでなければ、監視を有効にした途端、ログに何か月も溜まっていたものすべてについて通知が来てしまいます。
設定 — 「設定」→ 「イベントの監視」:
23-7 の形式で指定する時間帯で、その間は警告を送りません。通知は日次レポートと同じチャネル（Telegram、メール、Webhook、プッシュ）を通ります。別途有効にする必要はありません。検出結果は通知が送られたかどうかに関わらずすべて一覧に記録され、90日保存されます。
イベント一覧。 フィルター: 期間（24時間、7日、30日、90日）、重要度、情報源。直近 500 件が表示されます。「今すぐ点検」ボタンは cron とまったく同じ点検を実行します。設定した直後に5分待たずに済むので便利です。通知が送られなかった場合はその理由も示します（「重要度の下限未満」「静音時間帯」「通知チャネルが未設定」）。メニュー項目の赤いカウンターは、直近24時間の重大イベントの件数です。
アドレスカード。 イベント一覧の行、または関連するアドレスのブロックの行をクリックすると、ひとつのアドレスについて分かっていることがすべて開きます。イベントの時系列、国、そして最初の行に結論です。イベントがちょうどひとつのアドレスに関するものであれば一覧の行がカードを開き、複数ある場合は行内のアドレス自体がリンクになります。結論は4種類です。
時系列の下には同じ時間帯にサーバーで起きたことのブロックがあります。そもそもアドレスを持たないイベントです。AIDEは誰がファイルを変えたかを知らず、ClamAVは誰が感染ファイルを持ち込んだかを知りません。アドレスが動いていた時間帯と、その後6時間に当たるものを表示します。ログインとそれに続いて起きたことの組み合わせこそが、試みと実際のアクセスを分けます。
スケジュール。 ジョブは root の crontab に登録します（sudo crontab -e）。メトリクス収集と同時に始まらないよう、2分ずらしてあります。
php cron/security_watch.php を直接呼び出してはいけません。 ラッパーはサーバー上のパネルの全インストールを見つけ、サイト所有者の権限で点検を実行します。パネルがウェブから使っているのとまったく同じ sudo 権限です。root の crontab から直接呼び出すと、状態ファイル data/secwatch_state.json の所有者が root になり、パネルの「今すぐ点検」ボタンが動かなくなります。
「ウェブサーバー」ページはアクセスログを解析し、リクエストが何件あり、そのうちどれだけがエラーで終わり、誰が送ってきたのかを示します。ModSecurity が答えるのは「何がブロックされたか」、このページが答えるのは「そもそもサイトに何が届いていたか」です。
表示される内容: リクエスト数、RPS、エラー率、5xx の個別カウンター、送出したデータ量。時間ごとのリクエストのグラフ、2xx/3xx/4xx/5xx の内訳、よく現れるアドレス、よく現れる IP、よく起きるエラー（コードとパス）、クライアント（User-Agent）。期間は24時間または7日です。
情報源は combined 形式のアクセスログなので、Nginx でも Apache でも使え、追加モジュールも不要です。パネルは次の標準ファイルの中からログを探します。
/var/log/nginx/access.log/var/log/apache2/access.log/var/log/apache2/other_vhosts_access.log/var/log/httpd/access_logこれらに加えて、パネルは /var/log/nginx/、/var/log/apache2/、/var/log/httpd/ にある *access*.log と *requests*.log のファイルも調べます。これにより、サイトが CustomLog ディレクティブで独自のファイルに書き込むログも見つかります。たとえば Arcivéo のインストーラーが作成する arciveo-monitor_requests.log です。
読み取るログは1つだけです。Nginx が Apache の前段にある構成では、2つのログを足すと各リクエストを二重に数えてしまうからです。上の一覧のうち、直近1日以内に書き込みのあった最初のログを使います（名前のパターンで見つかったファイルはその後に、新しい順に試します）。1日どのログにも書き込みがなければ、空でないログのうち最も新しいものを使います。そのため、logrotate で空になったログや、停止したウェブサーバーが残したログが、稼働中のログを覆い隠すことはありません。読み取るのはログの末尾（3 MB）で、結果は5分間キャッシュされます。そのためアクセスの多いサイトでは、選んだ期間が完全には覆われないことがあります。実際にカバーできた範囲はグラフの上に表示されます。
adm グループに属していますが、ウェブユーザーはこのグループに入っていません。Arcivéo のインストーラーはウェブユーザーをこのグループに追加します。手動でインストールした場合は、ログを表示するという一つの動作だけを許可した root 所有の小さなラッパーで解決します（ModSecurity のページも同じ仕組みです）。ラッパーはパネルと同じ規則でログを選びます。コマンドはページ自体にも表示されますが、ここにも載せておきます。1つのコマンドなので、まとめて貼り付けてください。
ウェブユーザーは www-data とは限りません。サイトの PHP-FPM プールがどのユーザーで動いているかを確認し（ps -o user= -C php-fpm）、そのユーザー名を sudoers の行に入れてください。ログの名前に access も requests も含まれない場合は、ラッパー内の L=… の行の先頭にそのパスを追加してください。
既知の脆弱性を狙った試行。パネルはログのリクエストを、よく使われる約 20 種のエクスプロイトのシグネチャと照合します。PHP-CGI、Apache のディレクトリトラバーサル、PHPUnit、Log4Shell、ルーター・カメラ・VPN ゲートウェイの脆弱性などです。試行ごとに、このサーバーで成功しうるかどうかを事実に基づいて示します。根拠は、インストール済みの Apache と PHP のバージョン、Java の有無、ファイル要求に対するサーバーの応答コードです。赤で示すのは、実際に成功しうるものだけです。
Web サーバーの堅牢化。パネルはサーバー上の各サイトに 127.0.0.1 経由でリクエストを送り、訪問者が受け取る内容を確認します。Web サーバーと PHP のバージョンが見えるか、TRACE メソッドが有効か、保護用ヘッダー Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy、Content-Security-Policy があるかです。サイトはパネルを開いたアドレスと、パネルが読める場合はバーチャルホストのファイルから取得します。結果は 10 分ごとに更新されます。
不足があると、表の下にコマンドが 1 つ表示されます。別ファイル zz-arciveo-hardening.conf を作成し、設定テストに合格した場合にのみ Web サーバーを再読み込みします。サイトがすでに送っているヘッダーは重複させません。CSP は 1 行では提案しません。ポリシーはサイトごとに作る必要があり、そうしないとサイト自身のスクリプト、スタイル、フォントが読み込めなくなるためです。Apache で変更を元に戻すには:
ServerSignature) は指摘しません。バージョンがなければ、署名に表示されるのはサーバー名とホスト名だけです。
「攻撃マップ」ページは 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ジョブ。パネルはすでに動作しており、同じサーバーにもう1つサイトが必要になった場合です — モニターの隣に独自ドメインで置きます。自動セットアップ後のサーバーは通常の Apache + PHP-FPM なので、サイトに必要なのは3つだけです。専用のディレクトリ、専用の vhost、専用の証明書です。パネルには手を触れません。パネルはサーバー全体を監視するため、2つ目のドメインのために2つ目のパネルを入れる必要はありません。
site2.example.com は新しいサイトのアドレスです。独立したドメイン（mycompany.com）でもサブドメイン（shop.mycompany.com）でもかまいません。Apache にとって違いはなく、異なるのは DNS レコード（手順1）と証明書の発行（手順5）だけです。site2 は単なるサイトの短い名前で、ディレクトリ /var/www/site2 と設定ファイル site2.conf の名前に使われています。ドメインとは無関係で、Apache はアドレスを ServerName からのみ取得します。名前は自由で、たとえば shop.mycompany.com なら shop が便利です（ディレクトリ /var/www/shop、設定 shop.conf）。
1. DNS。 ドメイン登録業者の DNS 画面で、このサーバーの IP を指す A レコードを作成します。
数分後に確認します。dig +short site2.example.com がサーバーの IP を返すはずです。
2. サイトのディレクトリ。
3. vhost。 ブロックはまとめてターミナルに貼り付けます。PHP-FPM ソケットのパスは自動で判別されます。
4. サイトを有効化し、再読み込みの前に設定を検証します。
5. SSL。 certbot は自動セットアップですでにインストール済みです。この時点で DNS はサーバーを指している必要があります。
3つ目以降のドメインも同じ手順です。ドメインとディレクトリを変えて手順1〜5を繰り返してください。
Host がどの ServerName とも一致しない場合（IP でのアクセスや、あなたのサーバーに向けられた他人のドメイン）、Apache は /etc/apache2/sites-enabled/ の中でアルファベット順で最初の有効なサイトを返します。標準の 000-default は自動セットアップが無効化するため、この「当番」の役目はパネルの vhost（arciveo-monitor.conf）が担い続けます。各サイトを自身の名前で開く分には影響ありません。IP で別のサイトを開きたい場合は、そのファイル名をアルファベット順で先に来るようにします（たとえば 000-site2.conf）。
/var/log/apache2/ の site2_error.log と site2_access.log。
.htaccess（フロントコントローラー）で制御されているため、入れ子にしたサイトは想定と異なるものを返します。サイトは並べて配置してください: /var/www/monitor、/var/www/site2。
ログインできない場合は、サーバー上のデータベースで直接修復できます。データベースを開いてください（データベース名は 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 はすでにパネルに含まれており、個別に設置する必要はありません。security-watch-all.sh → /usr/local/bin/（chmod +x）— パネルの cron/security_watch.php をサイト所有者の権限で実行します（「セキュリティイベント」ページ、上の crontab の 2-57/5 の行）。security_watch.php はパネルに同梱されており、別途の設置は不要です。fleet-push-all.sh → /usr/local/bin/（chmod +x）— パネルの cron/fleet_push.php を通じてサーバー要約をアカウントへ送信します（上の 3,18,33,48 の行）。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。カーネル更新後はサーバーを再起動してください。