Ручная установка

Полностью ручная установка: от только что купленного VPS до рабочей панели, по шагам. Подготовка сервера, создание сайта, база данных, config.php и SSL расписаны здесь. Команды по каждому инструменту безопасности и по cron — в FAQ-справочнике, ссылки по ходу.

Главное правило: меняя SSH или файрвол, не закрывайте текущее подключение, пока не проверили новое в отдельном окне. Если доступ всё же потерян — почти все хостеры дают аварийную консоль (VNC/Recovery) в панели управления.

01. Купил VPS с Ubuntu/Debian — с чего начать

После покупки хостер присылает: IP-адрес, имя пользователя (обычно root) и пароль (или SSH-ключ). Этого достаточно для входа. Порядок действий (каждый шаг — раздел ниже):

  1. Подключиться к серверу по SSH;
  2. Обновить систему, задать имя хоста и часовой пояс;
  3. Создать обычного пользователя с правами sudo (не работать под root);
  4. Настроить вход по SSH-ключу и отключить вход по паролю;
  5. Включить файрвол и автозащиту;
  6. (по желанию) поставить панель управления HestiaCP — веб-сервер, БД, почта «из коробки».

02. Первое подключение по SSH

SSH — это защищённый терминал к серверу. Подставьте свой IP вместо 203.0.113.10.

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 Europe/Kyiv 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-ключи и отключение входа по паролю

Вход по ключу надёжнее пароля: пароль можно подобрать, ключ — практически нет. Сначала создаём ключ на своём компьютере, копируем его на сервер, проверяем вход — и только потом отключаем пароль.

Шаг 1. Создать ключ на своём компьютере (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
Не выполняйте Вариант B, пока вход по ключу не проверен и не работает (Шаги 1–3), и не закрывайте рабочую сессию. Он отключает вход по паролю для всех пользователей, включая 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 — полный hardening. Отключить вход по паролю и оставить 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 (или ваш порт, если меняли) и веб: 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 — бесплатная панель управления хостингом: ставит и настраивает веб-сервер (nginx + apache), PHP, базу данных (MariaDB), почту, DNS и SSL-сертификаты, даёт веб-интерфейс для сайтов. Удобна, если не хочется настраивать всё вручную и планируется размещать сайты (в т.ч. саму панель Arcivéo Monitor).

Ставьте HestiaCP на чистый сервер (свежая поддерживаемая Ubuntu/Debian, минимум ~1–2 ГБ RAM), до установки других веб-серверов и БД — иначе будут конфликты. Установка занимает 10–20 минут и перезагрузит сервер.
# Скачать установщик и запустить: wget https://raw.githubusercontent.com/hestiacp/hestiacp/release/install/hst-install.sh sudo bash hst-install.sh

Установщик спросит email и имя хоста, затем поставит весь стек. После перезагрузки панель доступна по адресу https://YOUR_IP:8083 (логин и пароль покажет установщик в конце).

HestiaCP сама управляет UFW и fail2ban — отдельно их настраивать не нужно, она подхватит. SSH-ключи и отключение пароля (предыдущий раздел) всё равно сделайте.

08. Системные требования и ionCube

Панель — PHP-приложение на типичном LAMP/LEMP-стеке:

  • ОС: Linux (Ubuntu/Debian рекомендуются);
  • Веб-сервер: nginx или Apache с PHP-FPM;
  • PHP 8.0+ с расширениями: pdo_mysql, openssl, curl, json, mbstring;
  • ionCube Loader — расширение PHP, необходимое для работы панели;
  • БД: MySQL 5.7+ или MariaDB 10.3+;
  • HTTPS — обязательно (вход и WebAuthn работают только по https);
  • 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 (например ioncube_loader_lin_8.1.so для PHP 8.1). Если используете несколько версий PHP — подключите лоадер для каждой.

09. Домен и DNS

Чтобы открывать панель по адресу вроде monitor.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
SSL-сертификат Let's Encrypt выдаётся только на домен — DNS должен указывать на сервер до выпуска сертификата.

10. Создать сайт и залить файлы панели

Apache: DocumentRoot — на корень панели, НЕ на public/. Стили (CSS/JS), sw.js, manifest.json лежат в assets/ рядом с public/ и запрашиваются от корня сайта. Корневой .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) Настройте веб-сервер. 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:

# Пример через scp с локального компьютера: scp -r ./monitor/* deploy@203.0.113.10:/var/www/monitor/
Выставьте права на файлы — это обязательный шаг. Если заливали под root или по SFTP, файлы принадлежат root, и веб-сервер (www-data) не сможет их прочитать — панель откроется пустой или с ошибкой 403 (в логе: .htaccess unreadable / directory not executable). Команда ниже это чинит:
# Нормализуем права всего вебрута: каталог, созданный root, недоступен # веб-серверу (www-data) — без этого панель отдаёт пустую страницу или 403. # Apache работает под www-data; если у вас другой веб-пользователь — замените. cd /var/www/monitor # Рабочие папки создаём ДО chown — иначе новые каталоги останутся root:root # и при chmod 750 веб-сервер (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. Выберите один из двух вариантов.

Вариант A — ACL только для вашего пользователя (рекомендуется). Право записи получаете только вы; веб-сервер по-прежнему не может переписать код панели:

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. Проще, но право записи в файлы панели получает и веб-сервер: при уязвимости в 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, буква s вместо x означает, что setgid установлен.

11. База данных

Создайте базу и пользователя, затем импортируйте схему. Блок вставляется в терминал целиком. monitor_db и monitor_user — имена для примера, можете задать любые свои; запомните имя базы, пользователя и пароль — впишете их в config.php на следующем шаге:

# 1. База данных. Пароль задаётся ОДИН раз в DBPASS и подставляется во все строки. # Блок вставляется в терминал ЦЕЛИКОМ; sudo mysql входит root по unix-сокету # (пароль 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.
Схему импортировать не нужно — панель сама создаёт таблицы и учётку 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', 'Europe/Kyiv'); // ваш часовой пояс // --- Время сессии --- define('SESSION_LIFETIME', 28800); // простой до повторного входа, сек (28800 = 8 ч)

Что менять:

  • DB_NAME, DB_USER, DB_PASS — ровно те же имя базы, пользователь и пароль, что вы задали при создании БД в шаге 11 (если оставили примеры — monitor_db / monitor_user). DB_HOST и DB_CHARSET не трогайте.
  • APP_URL — полный адрес панели с https://, без слэша в конце и без www. Должен совпадать с доменом, на который активируете лицензию (шаг 16), иначе ключ будет отклонён.
  • TIMEZONE — ваш часовой пояс (список — timedatectl list-timezones). Влияет только на то, как панель показывает даты; на время запуска cron-заданий не влияет (там действует пояс системы).
  • SESSION_LIFETIME — через сколько секунд бездействия панель попросит войти заново (по умолчанию 8 часов). Напр. 3600 = 1 час, 86400 = сутки.
  • Блок логирования ошибок (display_errors, log_errors, error_log) — оставьте по умолчанию.

Сохраните файл (Ctrl+O, Enter, затем Ctrl+X) и перезапустите PHP-FPM — иначе из-за OPcache изменения не применятся:

sudo systemctl restart php*-fpm
config.php — секретный файл (в нём пароль БД). Он лежит в корне панели, который и есть веб-корень, но закрыт: права 640 (выставлены в шаге 10) и явный запрет в корневом .htaccess. Не выкладывайте его в публичные репозитории и не передавайте в поддержку с реальным паролем.
Подробный разбор всех параметров — в FAQ: «Файл config.php — все настройки панели».

13. Настройка sudo для веб-сервера

PHP выполняется от пользователя веб-сервера, у которого нет прав на системные команды. Доступ выдаётся узко: точечный sudo на конкретные утилиты и чтение логов через группы (без sudo). Взлом веб-слоя не даёт root.

В примерах www-data — стандартный пользователь Apache. Если у вас другой (в некоторых панелях PHP под отдельным пользователем) — замените везде. Узнать: ps -o user= -C php-fpm | sort -u.

1. Создайте /etc/sudoers.d/monitor через sudo visudo -f /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'ов одной командой; # 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 МБ) доступен только root'у, не-root пересобирает его на каждый вызов # (4.2 с CPU против 0.01 с). Без wildcard — ровно эта одна команда, ничего не ставит. 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, см. п.2; sudo для journalctl давать НЕ нужно и небезопасно) 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 берутся из journald командой journalctl без sudo, через группу systemd-journal. Добавьте веб-пользователя в обе группы и перезапустите 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) принадлежит root с правами 640, читать его напрямую веб-пользователь не может. Страница 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. Наружу утекут кэши панели и данные — например tmp/modsec_cache.json с событиями WAF и IP атакующих. Добавьте запрет в конфиг сайта 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 /, иначе запрет не сработает.
В HestiaCP кладите это отдельным файлом /home/<user>/conf/web/<domain>/nginx.ssl.conf_denynginx.conf_deny для HTTP) — конфиг сайта подключает 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 → «Видна только одна БД»).

14. Ограничение доступа по IP

Ограничьте доступ к монитору по IP-адресу — даже если URL станет известен, страница входа не откроется. Можно на уровне веб-сервера (пример для nginx ниже) или в самой панели («Настройки» → «Ограничение доступа по IP»). Если у вас Apache, пользуйтесь ограничением в панели.

Если сайт nginx уже настроен по шагу 10, не добавляйте второй location / — впишите строки allow/deny в уже существующий блок. Два одинаковых location / в одном server { } — ошибка конфигурации, nginx не перезапустится.
# В конфиге nginx (внутри server { }): # ACME-путь Let's Encrypt держим открытым в обход 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 домена уже должен указывать на сервер. Команда зависит от веб-сервера:

# 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 и автопродление.
DNS должен указывать на сервер ДО запуска certbot (проверка владения по 80-му порту). Проверка: dig +short monitor.example.com → IP сервера. Порты 80/443 открыты: sudo ufw allow 80,443/tcp.

После выпуска: https://monitor.example.com открывается с замком, http:// редиректит на https:// (APP_URL в config.php уже задан в шаге 12).

16. Вход и первичная настройка

Откройте https://monitor.example.com, войдите admin / useradmin и пройдите чеклист:

  1. Сменить пароль admin — раздел «Пользователи» в меню.
  2. Включить WebAuthn (2FA) — «Ключи WebAuthn» → зарегистрировать ключ/passkey (требует HTTPS). Зарегистрируйте сразу два: при потере единственного ключа вход по нему будет невозможен. Подробнее.
  3. Ограничить доступ по IP — «Настройки» → «Ограничение доступа по IP» (впишите свой IP перед включением, иначе закроете себе доступ).
  4. Ввести лицензию — код ARCIVEO-… из кабинета активируйте на свой домен и вставьте ключ в «Настройки» → «Лицензия». Подробнее.
  5. Настроить уведомления — Telegram и/или Email в «Настройки». Подробнее.
  6. Удалить установщик public/start_db.php, если он остался (шаг 11).

17. Инструменты безопасности (опционально)

Панель уже работает. Инструменты ставятся по желанию — что нужно, то и ставите, панель сразу покажет статус. Команды установки каждого — в справочнике (отдельные разделы по инструментам):

18. Cron и обслуживание

Настраивается один раз, тоже опционально, но рекомендуется. Подробные команды — в справочнике:

  1. Cron-задания (отчёты, обновление списков, проверки);
  2. Резервное копирование;
  3. Обновление и перенос панели;
  4. Восстановление доступа — на случай потери ключа/пароля.
Что-то не работает или показывает «нет данных»? Загляните в группу «Диагностика» справочника.
Arcivéo - Security Monitor © 2026