完全な手動インストール：購入したばかりの VPS から稼働中のダッシュボードまで、手順を追って解説します。
サーバーの準備、サイトの作成、データベース、config.php、SSL をここで説明します。
各セキュリティツールと cron のコマンドは
FAQ リファレンス にあり、随所からリンクしています。
重要な原則：SSH やファイアウォールを変更する際は、別ウィンドウで新しい接続を確認するまで現在の接続を切断しないでください 。それでもアクセスを失った場合、ほとんどのホスティング業者は管理パネルで緊急コンソール（VNC/Recovery）を提供しています。
01. Ubuntu/Debian入りのVPSを購入した — まず何から購入後、ホスティング業者から次が届きます: IPアドレス 、ユーザー名（通常はroot）、パスワード（またはSSHキー）。ログインにはこれで十分です。作業手順（各ステップは以下の各セクション）:
SSHでサーバーに接続する;
システムを更新し、ホスト名とタイムゾーンを設定する;
sudo権限を持つ一般ユーザーを作成する（rootで作業しない）;SSHキーによるログインを設定し、パスワードログインを無効化する ;
ファイアウォールと自動防御を有効化する;
（任意） 管理パネルHestiaCPを導入する — Webサーバー、DB、メールがすぐに使える。
02. SSH での初回接続SSH はサーバーへの安全な接続を提供するターミナルです。203.0.113.10 は自分の IP に置き換えてください。
203.0.113.10 は例示用の存在しないアドレス です（ドキュメント用に予約済み）。そのまま入力せず、ホスティング業者からのメールに記載された実際のサーバーの IP に置き換えてください。そうしないと接続できません。
Windows 10/11: PowerShell または「ターミナル」を開き、標準の ssh を使用します（もしくは PuTTY / MobaXterm などのクライアント）。macOS / Linux: 「ターミナル」を開きます。
# root でログイン（パスワードはホスティング業者から届きます）:
ssh root@203.0.113.10
# ホスティング業者がパスワードの代わりに鍵ファイルを提供した場合:
ssh -i 鍵へのパス root@203.0.113.10 コピー
初回接続時に SSH が「authenticity of host」について尋ねます。yes と入力してください。パスワードは入力中に表示されません（正常な動作です）。ホスティング業者が一時パスワードを提供した場合は、passwd コマンドで変更してください。
03. システムの更新と基本設定まずはすべてのパッケージを更新し、ホスト名とタイムゾーンを設定します。
# システムを更新:
apt update && apt upgrade -y
# 基本ユーティリティ:
apt install -y curl wget ufw fail2ban unattended-upgrades
# タイムゾーン（例）とホスト名:
timedatectl set-timezone Asia/Tokyo
hostnamectl set-hostname myserver
# セキュリティ更新の自動適用:
dpkg-reconfigure -plow unattended-upgradesコピー
タイムゾーンの一覧は timedatectl list-timezones で確認できます。更新の最後に「Daemons using outdated libraries」という青い画面が表示されたら、すべてのサービスを選択（スペースキー）して OK を押してください。安全な操作です。
04. sudo権限を持つユーザーの作成常にrootで作業するのは安全ではありません。通常のユーザーを作成し、sudo権限（必要に応じて管理者としてコマンドを実行）を付与してください。deployは任意の名前に置き換えてください。
# ユーザーを作成（パスワードを設定し、情報を尋ねられます — Enterで省略可）:
adduser deploy
# sudoグループに追加:
usermod -aG sudo deploy
# 確認（rootで）:
su - deploy
sudo whoami # 出力されるはず: root
exitコピー
以降はこのユーザーでサーバーにログインし（ssh deploy@203.0.113.10）、管理者コマンドはsudoを付けて実行してください。
05. SSHキーとパスワードログインの無効化キー認証はパスワードより安全です。パスワードは総当たりで破られますが、キーはほぼ不可能です。まず自分のPC でキーを作成し、サーバーへコピーしてログインを確認してから、パスワードを無効にします。
ステップ1. 自分のPCでキーを作成します（Windows PowerShell / macOS / Linux）：
ssh-keygen -t ed25519 -C "my-laptop"
# すべての質問でEnter（キーは ~/.ssh/id_ed25519 に保存されます）コピー
ステップ2. 公開 キーをサーバーへコピーします：
# macOS / Linux:
ssh-copy-id deploy @203.0.113.10
# Windows (PowerShell):
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh deploy @203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"コピー
ステップ3. 新しい ウィンドウでキーによるログインを確認します。パスワードなしで入れるはずです：
ssh deploy @203.0.113.10 コピー
キーによるログインを検証し、動作を確認するまで（ステップ1〜3）オプションBは実行せず、作業中のセッションも閉じないでください。 これは root を含むすべての ユーザーのパスワードログインを無効にします。使えるキーがないと、サーバーへのアクセスを完全に失います。その場合はホスティングのコンソールからしか復旧できません。キーがなければオプションAを選んでください。
ステップ4. SSHアクセスを強化します。設定は別ファイルに置き、メインの設定は触りません。状況に応じてオプションを選んでください：
オプションA — root だけを閉じ、パスワードは残す。 キーは不要で、アクセスを失いません：
echo 'PermitRootLogin no' | sudo tee /etc/ssh/sshd_config.d/00-hardening.conf >/dev/null
sudo systemctl restart sshコピー
オプションB — 完全なハードニング。 パスワードログインを無効にし、root はキーのみに限定します。キーによるログインが動作することを確認した場合のみ 実行してください：
sudo tee /etc/ssh/sshd_config.d/00-hardening.conf >/dev/null <<'EOF'
PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin prohibit-password
KbdInteractiveAuthentication no
EOF
sudo systemctl restart sshコピー
どちらのオプションでも root のパスワードログインは無効になります。PermitRootLogin no は root を完全に禁止し、prohibit-password はキーによるログインのみを残します（管理は deploy でログインし sudo を使います）。SSHポートを変更したい場合は Port 2222 の行を追加しますが、先に ファイアウォールで新しいポートを開き（次のセクション）ログインを確認してください。さもないと自分のアクセスを塞いでしまいます。
06. 基本ファイアウォールと自動防御ファイアウォールで不要なものをすべて閉じ、fail2ban（SSHのパスワード総当たりをブロック）を有効にします。先に SSHを許可してください。そうしないとUFW有効化後にアクセスできなくなります。
# SSH（変更した場合はそのポート）とWebを許可:
sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp
# ファイアウォールを有効化:
sudo ufw enable
sudo ufw status verbose
# fail2ban — SSHを総当たりから保護（基本プロファイルはすぐ有効）:
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshdコピー
これは最低限です。fail2banの実運用設定、ipsumブロックリスト、拡張UFW、その他のツールは、リファレンスの
「セキュリティツール」グループ にあります。Arcivéo Monitorのパネル自体が、これらすべての状態をわかりやすく表示します。
07. HestiaCP パネルのインストール（任意）HestiaCP は無料のホスティング管理パネルです。Webサーバー（nginx + apache）、PHP、データベース（MariaDB）、メール、DNS、SSL証明書のインストールと設定を行い、サイト管理用のWebインターフェースを提供します。すべてを手動で設定したくない場合や、サイト（Arcivéo Monitor パネル自体を含む）を配置する予定がある場合に便利です。
HestiaCP はクリーンなサーバー （新しいサポート対象の Ubuntu/Debian、最低 ~1〜2 GB RAM）に、他のWebサーバーやDBをインストールする前に導入してください。そうしないと競合が発生します。インストールには10〜20分かかり、サーバーが再起動します。
# インストーラーをダウンロードして実行:
wget https://raw.githubusercontent.com/hestiacp/hestiacp/release/install/hst-install.sh
sudo bash hst-install.shコピー
インストーラーがメールアドレスとホスト名を尋ね、その後スタック全体を導入します。再起動後、パネルは https://YOUR_IP:8083 でアクセスできます（ログイン名とパスワードは最後にインストーラーが表示します）。
HestiaCP は UFW と fail2ban を自動で管理 します。個別に設定する必要はなく、自動的に取り込まれます。SSHキーとパスワード認証の無効化（前のセクション）は忘れず行ってください。
08. システム要件と ionCubeダッシュボードは一般的な LAMP/LEMP スタック上で動作する PHP アプリケーションです:
OS: Linux（Ubuntu/Debian 推奨）;Web サーバー: nginx または PHP-FPM 付きの Apache;PHP 8.0+ と拡張機能: pdo_mysql, openssl, curl, json, mbstring;ionCube Loader — ダッシュボードの動作に必要な PHP 拡張機能;DB: MySQL 5.7+ または MariaDB 10.3+;HTTPS — 必須（ログインと WebAuthn は https 経由でのみ動作します）;Web サーバーのユーザーに sudo （限定的な範囲 — ステップ 13）。
# PHP のバージョンと拡張機能を確認:
php -v
php -m | grep -iE 'pdo_mysql|openssl|curl|mbstring|ioncube'コピー
ionCube Loader のインストール （未インストールの場合）。管理パネル付きホスティング（HestiaCP, cPanel）では ionCube は PHP 設定のチェックボックスで有効化できます。Ubuntu/Debian で手動の場合:
# PHP のバージョンと拡張機能ディレクトリを確認:
php -v
EXTDIR=$(php -r 'echo ini_get("extension_dir");'); PHPVER=$(php -r 'echo PHP_MAJOR_VERSION.".".PHP_MINOR_VERSION;')
# ローダーをダウンロードして展開 (64-bit):
cd /tmp
wget -q https://downloads.ioncube.com/loader_downloads/ioncube_loaders_lin_x86-64.tar.gz
tar xzf ioncube_loaders_lin_x86-64.tar.gz
# お使いの PHP バージョンに合ったローダーを拡張機能ディレクトリにコピー:
sudo cp ioncube/ioncube_loader_lin_${PHPVER}.so "$EXTDIR"/
# 有効化 (CLI + PHP-FPM) して再起動:
echo "zend_extension=ioncube_loader_lin_${PHPVER}.so" | sudo tee /etc/php/${PHPVER}/mods-available/ioncube.ini
sudo phpenmod ioncube
sudo systemctl restart php${PHPVER}-fpm
# 確認 — 出力に "with the ionCube PHP Loader" の行が表示されます:
php -vコピー
ローダーのバージョンは PHP のバージョンと一致する必要があります（例: PHP 8.1 用の ioncube_loader_lin_8.1.so）。複数の PHP バージョンを使用している場合は、各バージョン用のローダーを有効化してください。
09. ドメインとDNSmonitor.example.com のようなアドレスでダッシュボードを開き、無料のSSLを取得するには、サーバーを指し示すドメインが必要です。DNS管理画面でAレコード を作成してください:
タイプ: A
名前: monitor (サブドメイン → monitor.example.com)
または @ (ドメインルート → example.com)
値: 203.0.113.10 ← サーバーのIP
TTL: 3600コピー
数分後、ドメインがサーバーを指しているか確認します:
dig +short monitor.example.com # あなたのIPが返るはず
# または dig がない場合:
getent hosts monitor.example.com コピー
Let's EncryptのSSL証明書はドメインに対してのみ発行されます。証明書の発行前 にDNSがサーバーを指している必要があります。
10. サイトを作成しパネルのファイルをアップロード
Apache: DocumentRoot はパネルのルートに指定し、public/ には向けないこと。 スタイル（CSS/JS）、sw.js、manifest.json は public/ と並んで assets/ にあり、サイトのルートから読み込まれます。ルートの .htaccess がフロントコントローラです。Apache で DocumentRoot を public/ に向けると、パネルはスタイルなし で表示されます。純粋な nginx では逆に、ルートを public/ とし、assets/ は別ルールで配信します（下の nginx ブロック参照）。
パネルのファイル（配布アーカイブ）は購入後、my.arciveo.com のアカウント → 「ダウンロード」 から取得できます。アップロード前にアーカイブを展開してください。
1) パネル用ディレクトリを作成し 、そこに配布物の中身 をアップロードします（内部に public/、assets/、config.php などが入るように）：
sudo mkdir -p /var/www/monitor
# 続けて配布ファイルを /var/www/monitor にアップロード（FileZilla / WinSCP / scp）コピー
2) Web サーバーを設定します。 Apache ：DocumentRoot はパネルのルートに（/public ではなく）。AllowOverride All は必須です。PHP-FPM ソケットのパスは自動判定されます。ブロックはそのまま丸ごと ターミナルに貼り付けます：
PHPSOCK=$(ls -1 /run/php/php*-fpm.sock 2>/dev/null | head -1) # PHP-FPM ソケットの自動判定
sudo tee /etc/apache2/sites-available/monitor.conf > /dev/null <<'EOF'
<VirtualHost *:80>
ServerName monitor.example.com
DocumentRoot /var/www/monitor
<Directory /var/www/monitor>
AllowOverride All
Require all granted
</Directory>
<FilesMatch \.php$>
SetHandler "proxy:unix:__PHPSOCK__|fcgi://localhost"
</FilesMatch>
</VirtualHost>
EOF
sudo sed -i "s#__PHPSOCK__#${PHPSOCK}#" /etc/apache2/sites-available/monitor.conf
sudo a2dissite 000-default.conf
sudo a2ensite monitor.conf
sudo apache2ctl configtest
sudo systemctl reload apache2コピー
nginx ：nginx には .htaccess がないため、ルートを public/ とし、（一つ上の階層にある）assets/、sw.js、manifest.json は別ルールで配信します：
PHPSOCK=$(ls -1 /run/php/php*-fpm.sock 2>/dev/null | head -1) # PHP-FPM ソケットの自動判定
sudo tee /etc/nginx/sites-available/monitor.conf > /dev/null <<'EOF'
server {
listen 80;
server_name monitor.example.com ;
root /var/www/monitor/public;
index index.php;
# assets、service worker、manifest は public/ の一つ上の階層にある
location ~ ^/(assets/|sw\.js|manifest\.json) { root /var/www/monitor; }
location / { try_files $uri $uri/ /index.php?$query_string; }
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:__PHPSOCK__;
}
}
EOF
sudo sed -i "s#__PHPSOCK__#${PHPSOCK}#" /etc/nginx/sites-available/monitor.conf
sudo ln -s /etc/nginx/sites-available/monitor.conf /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginxコピー
ファイルのアップロード — SFTP/SCP（FileZilla、WinSCP）または scp：
# ローカル PC から scp で行う例：
scp -r ./monitor/* deploy @203.0.113.10 :/var/www/monitor/コピー
ファイルの権限を設定してください。これは必須の手順です。 root や SFTP でアップロードした場合、ファイルの所有者は root になり、Web サーバー（www-data）が読み取れず、パネルが空白または 403 エラー で開きます（ログには：.htaccess unreadable / directory not executable）。下のコマンドで修正できます：
# Web ルート全体の権限を正常化：root が作成したディレクトリは
# Web サーバー（www-data）からアクセスできず、これがないとパネルは空白ページか 403 を返す。
# Apache は www-data で動作。別の Web ユーザーを使う場合は置き換えること。
cd /var/www/monitor
# 作業用フォルダは chown の前に作成する — さもないと新しいディレクトリが root:root のまま残り、
# chmod 750 で Web サーバー（www-data）が書き込めなくなる。
sudo mkdir -p data/lynis data/logwatch tmp logs
sudo chown -R www-data:www-data /var/www/monitor
sudo find /var/www/monitor -type d -exec chmod 755 {} \;
sudo find /var/www/monitor -type f -exec chmod 644 {} \;
sudo chmod 640 /var/www/monitor/config.php
sudo chmod 750 data tmp logsコピー
3) SFTP でのアップロードを自分に開放してください。 上のコマンドの後はすべてのファイルが www-data の所有になりますが、FileZilla / WinSCP はご自身のユーザーで接続するため、アップロードは SSH_FX_PERMISSION_DENIED（Permission denied ）で失敗します。アップロードのために root でログインすることはできません。root ログインは手順 05 で無効にしました。次の 2 つの方法のどちらかを選んでください。
方法 A — 自分のユーザーだけに ACL を付与（推奨）。 書き込み権限を得るのはご自身だけで、Web サーバーは引き続きパネルのコードを上書きできません:
sudo apt install -y acl
# パネルのディレクトリ全体に対する、自分のユーザーへの書き込み権限:
sudo setfacl -R -m u:deploy :rwX /var/www/monitor
# 同じルールを既定値として — あとから作成されるファイルとフォルダー用:
sudo setfacl -R -d -m u:deploy :rwX /var/www/monitorコピー
方法 B — www-data グループ経由。 より簡単ですが、パネルのファイルへの書き込み権限は Web サーバーにも渡ります。PHP に脆弱性があればコードを差し替えられてしまいます。コマンドの順序は重要です — config.php と作業フォルダーは最後に閉じます:
sudo usermod -aG www-data deploy
# グループへの書き込み権限 + setgid（ビット 2）: SFTP でアップロードした
# ファイルは www-data グループに残ります。さもないとパネルが上書きできません。
sudo find /var/www/monitor -type d -exec chmod 2775 {} \;
sudo find /var/www/monitor -type f -exec chmod 664 {} \;
sudo chmod 640 /var/www/monitor/config.php
sudo chmod 2750 /var/www/monitor/data /var/www/monitor/tmp /var/www/monitor/logsコピー
方法 B の後は FileZilla で接続し直してください （サーバー → 切断、その後もう一度ログイン）。新しいグループは新規ログイン時にしか反映されず、それまでは権限がないままです。確認: id deploy — グループ一覧に www-data が表示されるはずです。ls -ld /var/www/monitor — 権限は drwxrwsr-x で、x の代わりの s は setgid が設定されていることを示します。
11. データベースデータベースとユーザーを作成し、スキーマをインポートします。ブロックはまるごと ターミナルに貼り付けてください。monitor_db と monitor_user は例としての名前で、任意の名前を設定できます。データベース名・ユーザー名・パスワードは控えておき、次のステップで config.php に記入します:
# 1. データベース。パスワードは DBPASS で一度だけ設定し、全行に反映されます。
# ブロックはまるごとターミナルに貼り付けます。sudo mysql は unix ソケットで root ログイン
# (root パスワード不要)。対話式の `sudo mysql -u root -p` を
# コピペで使わないでください — 貼り付け時に SQL 行がパスワード入力に流れて失われます。
DBPASS='CHOOSE_A_PASSWORD ' # ← この行だけ変更してください
sudo mysql <<SQL
CREATE DATABASE IF NOT EXISTS monitor_db CHARACTER SET utf8mb4;
CREATE USER IF NOT EXISTS 'monitor_user'@'localhost' IDENTIFIED BY '$DBPASS';
GRANT ALL ON monitor_db.* TO 'monitor_user'@'localhost';
FLUSH PRIVILEGES;
SQL
# 確認 (monitor_db が表示されるはず):
mysql -u monitor_user -p"$DBPASS" -e "SHOW DATABASES;"
# この同じパスワードを config.php → DB_PASS に記入します。コピー
スキーマのインポートは不要です — DB が空であれば、ブラウザで初回アクセスした際にダッシュボードが自動でテーブルと admin アカウントを (database/db.sql から) 作成します。手動でのスキーマインポートは、自動初期化が機能しなかった場合にのみ必要です。
ブラウザ用インストーラー public/start_db.php を使用した場合は、インストール後すぐに削除してください : 認証なしでデータベースを再作成できてしまいます。このファイルがダッシュボードのルートまたは public/ に残っている間、ダッシュボードは赤い警告を表示します。
12. config.php の設定パネルのルートにある config.php（/var/www/monitor/config.php）は、手で編集する必要がある唯一のファイルです。パネルの設定はすべて define() 定数として記述されています。エディタで開いてください:
sudo nano /var/www/monitor/config.phpコピー
ハイライト された箇所に自分の値を入れ、それ以外はそのままにしてください:
// --- データベース（ステップ 11 より） ---
define('DB_HOST', 'localhost'); // そのまま
define('DB_NAME', 'db_name '); // ステップ 11 で作成したもの
define('DB_USER', 'user '); // ステップ 11 で作成したもの
define('DB_PASS', 'db_password '); // ステップ 11 で設定したもの
define('DB_CHARSET', 'utf8mb4'); // そのまま
// --- アプリケーション ---
define('APP_URL', 'https://monitor.example.com '); // パネルのアドレス、末尾のスラッシュなし
define('TIMEZONE', 'Asia/Tokyo '); // タイムゾーン
// --- セッション時間 ---
define('SESSION_LIFETIME', 28800); // 再ログインまでの無操作時間、秒（28800 = 8 時間）コピー
変更する項目:
DB_NAME、DB_USER、DB_PASS — ステップ 11 で DB を作成した際に設定したのと同じデータベース名・ユーザー・パスワード（例のまま残した場合は monitor_db / monitor_user）。DB_HOST と DB_CHARSET は触らないでください。APP_URL — https:// 付きのパネルの完全なアドレス。末尾のスラッシュなし 、www なし。ライセンスを有効化するドメイン（ステップ 16）と一致している必要があり、そうでなければキーは拒否されます。TIMEZONE — タイムゾーン（一覧は timedatectl list-timezones）。パネルの日付表示にのみ影響し、cron ジョブの実行時刻には影響しません （そちらはシステムのタイムゾーンが適用されます）。SESSION_LIFETIME — 無操作が何秒続くとパネルが再ログインを求めるか（デフォルトは 8 時間）。例: 3600 = 1 時間、86400 = 1 日。エラーログのブロック（display_errors、log_errors、error_log）はデフォルトのままにしてください。
ファイルを保存し（Ctrl+O、Enter、続いて Ctrl+X）、PHP-FPM を再起動してください。そうしないと OPcache のせいで変更が反映されません:
sudo systemctl restart php*-fpmコピー
config.php は秘密のファイルです （DB のパスワードが含まれます）。パネルのルート（＝ウェブルート）に置かれていますが、保護されています: 権限 640（ステップ 10 で設定済み）とルートの .htaccess による明示的な拒否です。公開リポジトリに載せたり、実際のパスワードを含んだままサポートに送ったりしないでください。
13. Webサーバー向けsudoの設定PHPはWebサーバーのユーザーとして実行され、このユーザーにシステムコマンドの権限はありません。アクセスは限定的に付与します。特定のユーティリティに対するピンポイントのsudo と、グループ経由でのログ読み取り （sudoなし）です。Web層が侵害されてもrootは取られません。
例中のwww-dataはApacheの標準ユーザーです。別のユーザーの場合（一部のパネルではPHPが別ユーザーで動作）はすべて置き換えてください。確認方法: ps -o user= -C php-fpm | sort -u。
1. sudo visudo -f /etc/sudoers.d/monitorで/etc/sudoers.d/monitorを作成し、以下を貼り付けます（使用しないモジュールの行は削除してください）:
# UFW — ステータスとルール（「ファイアウォール」ページ）
www-data ALL=(ALL) NOPASSWD: /usr/sbin/ufw status, /usr/sbin/ufw status verbose, /usr/sbin/ufw status numbered
www-data ALL=(ALL) NOPASSWD: /usr/sbin/ufw allow [0-9]*, /usr/sbin/ufw deny [0-9]*, /usr/sbin/ufw --force delete [0-9]*
# Fail2ban — ステータス、バンとバン解除（banned は全jailのバンを1コマンドで返す。
# ban/unban はパネルのボタンに必要）
www-data ALL=(ALL) NOPASSWD: /usr/bin/fail2ban-client status, /usr/bin/fail2ban-client status *, /usr/bin/fail2ban-client banned, /usr/bin/fail2ban-client set * banip *, /usr/bin/fail2ban-client set * unbanip *
# セキュリティ更新（「更新」カード）。読み取りのみだが必ずrootで実行:
# apt キャッシュ（約70 MB）はrootのみアクセス可能で、非rootは呼び出しごとに再構築する
# （CPU 4.2秒に対し0.01秒）。ワイルドカードなし — まさにこの1コマンドのみ、何もインストールしない。
www-data ALL=(ALL) NOPASSWD: /usr/bin/apt list --upgradable
# IPset（攻撃マップ、ダッシュボード）
www-data ALL=(ALL) NOPASSWD: /usr/sbin/ipset list -t ipsum
# CrowdSec
www-data ALL=(ALL) NOPASSWD: /usr/bin/cscli decisions list *, /usr/bin/cscli alerts list *, /usr/bin/cscli bouncers list *, /usr/bin/cscli scenarios list *
# Auditd — イベント検索 + ログ末尾の読み取り（正確なパス）
www-data ALL=(ALL) NOPASSWD: /usr/sbin/ausearch -m *
www-data ALL=(ALL) NOPASSWD: /usr/bin/tail -n 300 /var/log/audit/audit.log
# Monit / ModSecurity / AppArmor / PSAD
www-data ALL=(ALL) NOPASSWD: /usr/bin/monit status
www-data ALL=(ALL) NOPASSWD: /usr/sbin/apache2ctl -M
www-data ALL=(ALL) NOPASSWD: /usr/local/bin/monitor-modsec
www-data ALL=(ALL) NOPASSWD: /usr/sbin/aa-status
www-data ALL=(ALL) NOPASSWD: /usr/sbin/psad --Status
# 開いているポート（カーネル/SSH/Falcoのログはsudoなしで読み取り — systemd-journal
# グループ経由、p.2参照。journalctlにsudoを与える必要はなく、危険）
www-data ALL=(ALL) NOPASSWD: /usr/bin/ss -tuln, /usr/sbin/ss -tuln, /bin/ss -tuln
# PostgreSQL（使用する場合のみ） — 固定のread-onlyスクリプト、
# FAQ「PostgreSQLが表示されない」に従って作成。なければこの行は削除
www-data ALL=(ALL) NOPASSWD: /usr/local/bin/monitor-pgstatコピー
sudo chmod 440 /etc/sudoers.d/monitor
sudo visudo -c # "parsed OK" と表示されるはずコピー
2. ログとsystemdジャーナルへのアクセス。 モジュールは/var/log/fail2ban.log、auth.log、ufw.log、apache2/*、aideを直接読み取ります（Debian/Ubuntuではこれらのログはadmグループにあります）。カーネル、SSH、Falcoのイベントはjournalctlコマンドでsudoなし 、systemd-journalグループ経由でjournaldから取得します。Webユーザーを両方 のグループに追加し、PHP-FPMを再起動 してください:
sudo usermod -aG adm,systemd-journal www-data
sudo systemctl restart php*-fpm # 必須。さもないとグループが適用されないコピー
3. ClamAVやSuricataがログをadmグループ以外に書き込む場合（root:rootのことがあります）は、ACL経由でアクセスを付与してください:
sudo apt install acl
sudo setfacl -R -m u:www-data:rX /var/log/clamav /var/log/suricata 2>/dev/null
sudo setfacl -d -m u:www-data:rX /var/log/clamav /var/log/suricata 2>/dev/nullコピー
4. ModSecurityのラッパー。 WAFの監査ログ（/var/log/apache2/modsec_audit.log）は権限640でrootが所有しており、Webユーザーが直接読み取ることはできません。ModSecurityページはエンジンのモード、イベント、有効なルールの一覧を固定のread-onlyスクリプト経由で取得します — これが上記の行でsudoersに許可されています:
sudo tee /usr/local/bin/monitor-modsec >/dev/null <<'EOF'
#!/bin/sh
echo "ENGINE=$(grep -hE '^SecRuleEngine[[:space:]]+' /etc/modsecurity/*.conf 2>/dev/null | tail -1 | awk '{print $2}')"
echo "---LOG---"
tail -n 3000 /var/log/apache2/modsec_audit.log 2>/dev/null
echo "---RULES---"
for f in /etc/modsecurity/crs/rules/*.conf /usr/share/modsecurity-crs/rules/*.conf /etc/modsecurity/custom-rules.conf; do
[ -f "$f" ] && { echo "===FILE:$(basename "$f")==="; cat "$f"; }
done
EOF
sudo chown root:root /usr/local/bin/monitor-modsec
sudo chmod 755 /usr/local/bin/monitor-modsecコピー
/etc/modsecurity/modsecurity.confファイルがないとWAF自体が動作しません。パッケージは
modsecurity.conf-recommendedだけを配置し、ルールエンジンは無効のままです — 有効化の方法は
FAQ →「ModSecurityのインストール」 を参照してください。
sudoersのすべての行のユーザーは、FPMプールのユーザーと一致している必要があります。通常のApache/Debianでは
www-data、HestiaCPではサイトのプールがサイト所有者（例:
admin）で動作します —
grep -E '^user' /etc/php/*/fpm/pool.d/monitor.example.com.confで確認してください。
5. Apacheの前段にNginxがある場合 （HestiaCP、ISPmanagerなどのパネル — そこではNginxがPHPをApacheにプロキシし、静的ファイルは自身で配信します）。サービス用ディレクトリは.htaccessファイルで保護されていますが、Nginxはこれを読み取りません : 静的ファイル（.json、.txt、.log、.dat）はApacheを迂回して直接配信されます。パネルのキャッシュやデータが外部に漏れます — 例えばWAFイベントと攻撃者のIPを含むtmp/modsec_cache.jsonです。Nginxのサイト設定に拒否を追加してください:
location ^~ /data/ { deny all; }
location ^~ /tmp/ { deny all; }
location ^~ /logs/ { deny all; }
location ^~ /includes/ { deny all; }
location ^~ /cron/ { deny all; }
location ^~ /database/ { deny all; }
location = /config.php { deny all; }コピー
^~プレフィックスは必須です: location /内の静的ファイル向け正規表現ルールより先に選択されます。さもないと拒否が機能しません。/home/<user>/conf/web/<domain>/nginx.ssl.conf_deny（HTTP用はnginx.conf_deny）として配置してください — サイト設定はnginx.ssl.conf_*を読み込み、再構築時にこれらのファイルを上書きしません。適用: sudo nginx -t && sudo systemctl reload nginx。curl -s -o /dev/null -w '%{http_code}\n' https://monitor.example.com/tmp/modsec_cache.json — 403 になるはずです。ApacheがNginxなしで動作している場合（自身で80/443をリッスン）は何も追加する必要はありません — .htaccessで十分です。
バイナリへのパスは
whichで確認してください（例:
which ufw cscli ausearch ss）。sudoersは必ず
visudoで編集してください。
すべて のMySQLデータベースの一覧は別のGRANTで有効になります（
FAQ →「1つのDBしか表示されない」 ）。
14. IPによるアクセス制限モニターへのアクセスをIPアドレスで制限すれば、URLが知られても、ログインページは開きません。Webサーバー側（以下はnginxの例）でも、パネル内（「設定」→「IPによるアクセス制限」）でも設定できます。Apacheの場合は、パネル側の制限をご利用ください。
手順10でnginxサイトを設定済みの場合は、2つ目を追加せず 、既存の location / ブロックに allow/deny の行を書き加えてください。同一の server { } 内に同じ location / が2つあると設定エラーとなり、nginxは再起動しません。
# nginxの設定内（server { } の中）:
# Let's EncryptのACMEパスはIP制限を回避して開放しておく —
# SSLの発行と自動更新（手順15）がIPフィルターに依存しないようにするため。
location ^~ /.well-known/acme-challenge/ { allow all; }
location / {
allow 203.0.113.10 ; # ← 自分のIPを記入
allow 10.0.0.0/8; # ローカルネットワーク（必要な場合）
deny all;
try_files $uri $uri/ /index.php?$query_string;
}
# nginxを再読み込み:
sudo nginx -t && sudo systemctl reload nginxコピー
15. SSL（HTTPS）を発行
パネルはHTTPSでのみ動作します。 ログインセッションは保護されたcookieを使用し、WebAuthn（2FA）はHTTPSでのみ動作します。http:// ではログインできません。
証明書は無料です（Let's Encrypt）。ドメインのDNSは既にサーバーを指している必要があります。コマンドはWebサーバーによって異なります：
# Apache:
sudo certbot --apache -d monitor.example.com
# nginx — 必ず nginx を使っている場合のみ。Apache では実行しないでください：
# apt が nginx を引き込みポート 80 を占有し、Apache と競合します。
# sudo apt install python3-certbot-nginx
# sudo certbot --nginx -d monitor.example.com
# certbot が自動でHTTPSを設定に書き込み、自動更新も設定しますコピー
certbot が尋ねる項目： e-mail → Terms への同意（Y）→ e-mail の EFF への提供（任意）。その後、自動で証明書を発行し、<VirtualHost *:443> を書き込み、http→https のリダイレクトと自動更新を設定します。
certbot 実行前にDNSがサーバーを指している必要があります （80番ポートでの所有確認）。確認：dig +short monitor.example.com → サーバーのIP。ポート80/443を開放：sudo ufw allow 80,443/tcp。
発行後：https://monitor.example.com が鍵マーク付きで開き、http:// は https:// にリダイレクトされます（config.php の APP_URL は手順12で既に設定済み）。
16. ログインと初期設定https://monitor.example.com を開き、admin / useradmin でログインしてチェックリストを実施します:
admin のパスワードを変更 — メニューの「ユーザー」セクション。WebAuthn（2FA）を有効化 — 「WebAuthn キー」→ キー/passkey を登録（HTTPS が必要）。すぐに2つ登録してください。唯一のキーを紛失するとそのキーでのログインができなくなります。詳細 。IP でアクセスを制限 — 「設定」→「IP によるアクセス制限」（有効化する前に自分の IP を入力してください。さもないと自分のアクセスを遮断します）。ライセンスを入力 — アカウントから取得した ARCIVEO-… のコードを自分のドメインでアクティベートし、キーを「設定」→「ライセンス」に入力します。詳細 。通知を設定 — 「設定」で Telegram および/または Email を設定。詳細 。インストーラーを削除 public/start_db.php が残っている場合（手順 11）。
18. Cron とメンテナンス設定は一度だけ、こちらも任意ですが推奨します。詳しいコマンドはリファレンスを参照してください。
Cron ジョブ （レポート、リスト更新、チェック）；バックアップ ；パネルの更新と移行 ；アクセスの復旧 — キーやパスワードを紛失した場合に。
何かが動かない、または「データなし」と表示されますか？リファレンスの
「診断」 グループをご覧ください。