Это руководство по установке, настройке и обслуживанию Arcivéo Security Monitor. Разделы сгруппированы: общий обзор, развёртывание панели, подключение инструментов безопасности, встроенные модули и диагностика. Команды можно копировать кнопкой справа.
Установка панели — на отдельных пошаговых страницах. Выберите способ:
Arcivéo Security Monitor — панель безопасности сервера. Собирает данные от установленных инструментов (Fail2ban, UFW, Lynis, ModSecurity, AIDE, ClamAV, Auditd, CrowdSec, Suricata, Falco и др.) и отображает их в едином интерфейсе с дашбордом, картой атак и детальными страницами по каждому инструменту.
Монитор не является активным средством защиты — он не блокирует атаки сам по себе. Его задача — агрегировать информацию от уже работающих инструментов и представить её в удобном виде.
Монитор работает только локально — он должен быть установлен на том же сервере, который мониторит. Никакого SSH или удалённого API нет.
Все команды (fail2ban-client, ufw status, ipset list и т.д.) панель выполняет от имени пользователя веб-сервера (обычно 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 в боковом меню и нажмите «Зарегистрировать ключ». Зарегистрируйте сразу два ключа: если единственный ключ потеряется или сломается, вход в панель по нему будет невозможен.
Каналов четыре: Telegram, Email, webhook и push в браузер. Они независимы — включайте любые, хоть все сразу. По этим же каналам уходят суточный отчёт безопасности, оповещения о нагрузке и находки сенсора событий: настраиваются они один раз, здесь, в разделе «Настройки».
Telegram. Нужны токен бота и chat id:
@BotFather → /newbot → получите токен вида 123456:ABC....@userinfobot, либо откройте https://api.telegram.org/bot<TOKEN>/getUpdates и найдите "chat":{"id":...}.Email. Два способа на выбор в «Настройки» → Email:
re_...) и подтверждённый домен отправителя.Webhook. Один адрес, принимающий POST, покрывает Slack, Discord, Mattermost, n8n и собственный обработчик. «Настройки» → Webhook: вставьте адрес и включите тумблер.
{"text": …}, для Discord — {"content": …} (Discord отклоняет сообщения длиннее 2000 символов, поэтому текст обрезается);text, event, severity, source, count, host, ts — разбирать текст сообщения не нужно.Push-уведомления. Сообщение приходит прямо в браузер, а если панель добавлена на главный экран телефона — как обычное уведомление приложения; ни бота, ни почтового сервера при этом не требуется. «Настройки» → Push-уведомления: включите тумблер и нажмите «Подключить это устройство» на каждом устройстве, которое должно получать уведомления. Счётчик «Подключено устройств» показывает, сколько их подключено.
Статус отчёта: «ВНИМАНИЕ» или «ОК». Заголовок становится «ВНИМАНИЕ» только при реальной проблеме или ожидающем действии: найдена угроза ClamAV, изменения файлов в AIDE, критические события Falco (Emergency/Alert/Critical за последние 24 ч), упавший сервис в Monit, требуется перезагрузка, истекает SSL (≤14 дней) или ждут security-обновления. Фоновый шум — SSH-переборы ботов, забаненные fail2ban IP, алерты Suricata, предупреждения Lynis и уже отбитые запросы ModSecurity — статус не поднимает, поэтому такие цифры в отчёте не означают «ВНИМАНИЕ» сами по себе.
Детальные модули мониторинга (Lynis, UFW, ModSecurity, карта атак, AIDE, ClamAV и др.) открываются при наличии действующей лицензии. Без неё дашборд, настройки и аккаунт работают, а модули показывают карточку «Требуется лицензия».
После покупки в кабинете у вас есть код активации вида ARCIVEO-XXXX-XXXX-XXXX-XXXX. Его нужно «активировать» на домен вашей панели — это превратит код в подписанный лицензионный файл (блок [license]), который вы вставляете в панель.
Как активировать (3 шага):
my.arciveo.com → раздел «Лицензии» / «Активация лицензии» — скопируйте код ARCIVEO-….monitor.example.com). Нажмите активировать — система сгенерирует лицензионный файл, привязанный к этому домену, и покажет его в поле с кнопкой «Копировать».Панель проверяет ключ криптографически: подпись, привязку к домену и срок действия.
APP_URL в config.php и введите только имя хоста — без https:// и без префикса www. Активация одноразовая: код превращается в лицензию для введённого домена и повторно не активируется — при ошибке в домене ключ не подойдёт вашей панели, а код будет израсходован. Поэтому вводите домен внимательно.
Все основные параметры панели заданы в одном файле config.php в корне (рядом с папкой public/) обычными константами define(). Файл создаётся при установке; править его вручную нужно редко — в основном при смене домена, переносе или подключении к другой базе. После любой правки перезапустите PHP-FPM (иначе из-за OPcache изменения не применятся).
Подставьте свои значения в подсвеченные места; остальное оставьте как есть:
База данных. Реквизиты подключения к MySQL/MariaDB:
DB_HOST — хост СУБД, почти всегда localhost;DB_NAME — имя базы данных панели;DB_USER — пользователь БД (доступ только к своей базе);DB_PASS — пароль этого пользователя;DB_CHARSET — кодировка соединения, оставьте utf8mb4.Приложение.
APP_URL — полный адрес панели (напр. https://monitor.example.com). Должен совпадать с доменом, на который активирована лицензия — иначе ключ будет отклонён (см. раздел «Лицензия»);TIMEZONE — часовой пояс PHP: влияет только на то, как панель показывает даты и время. На время запуска cron-заданий не влияет — там действует пояс системы (см. «Все cron-задания»).Время сессии. SESSION_LIFETIME — таймаут простоя сессии в секундах (скользящий: обновляется при активности). По умолчанию 28800 = 8 часов; после этого времени бездействия панель попросит войти заново. Например, 3600 = 1 час, 86400 = сутки.
Логирование ошибок. Ошибки никогда не показываются посетителям, а пишутся в logs/php_errors.log — их видно на странице «Логи приложения». Эти строки (display_errors=0, log_errors=1, путь error_log) менять обычно не нужно — настройки заданы прямо в файле и не зависят от php.ini.
public/), а у этой панели веб-корень (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 — API выключено в настройках. Отклонённые запросы записываются в журнал приложения вместе с IP отправителя, так что перебор токена виден на странице «Логи приложения».
Панель ставится на каждый сервер отдельно и хорошо отвечает на вопрос «как дела вот у этой машины». На вопрос «как дела у всех моих машин» она не отвечает — для этого каждая панель может отправлять короткую сводку в личный кабинет, где серверы видны одним списком.
Что взять в кабинете my.arciveo.com → раздел «Мои серверы»: там выдаётся токен (вида fk_…) и указан адрес приёмника https://my.arciveo.com/api/fleet.php. Токен один на аккаунт — он одинаковый для всех ваших серверов.
Что настроить в панели — «Настройки» → «Сводка по серверам»: адрес приёмника, токен, имя сервера (как он будет подписан в списке; оставите пустым — возьмётся домен панели) и тумблер «Отправлять сводку». Кнопка «Отправить сейчас» проверяет связь немедленно, не дожидаясь расписания.
Дальше сводка уходит по cron, каждые 15 минут:
Что именно уходит: имя и домен сервера, ОС, время работы, версия PHP; Оценка безопасности; состояния модулей (UFW, число jail'ов Fail2ban, баны за сегодня, запущены ли CrowdSec, Suricata и Falco, угрозы ClamAV, изменения AIDE, индекс Lynis, ожидающие обновления, нужна ли перезагрузка, дней до истечения SSL, число опасных открытых портов); последний замер нагрузки (load, CPU, RAM, диск, inodes); счётчики событий за 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'ы и автобан вредоносных IP из списка ipsum.
Файл /etc/fail2ban/jail.local — общие настройки и важнейшие jail'ы:
ignoreip обязательно впишите свой IP и доверенные сети, иначе можно забанить самого себя. После правок: sudo fail2ban-client reload.
Автоподгрузка блок-листа ipsum — в root-крон (sudo crontab -e): level 1 (100+ тысяч IP) грузится в набор ipsum, который отсекается на файрволе (подробнее — в разделе «Блок-лист IPset»):
ipsum — именно его читает дашборд (карточка «IPset ipsum»). Уровни: levels/1.txt — максимальный охват, levels/3.txt — точнее (3+ источника).
Почему «Монитор безопасности» разделён на две зоны. Защита работает на двух уровнях, и дашборд их не смешивает:
sshd, apache-*, nginx-* и т.п.) и злостные рецидивисты (jail recidive — те, кого уже банили несколько раз). Это IP, которые реально к вам ломились — они на карте атак и «Временной шкале».ipset ipsum, отсекаемый на файрволе правилом DROP. Эти адреса в большинстве вашего сервера и не касались — их режут заранее; счётчик «IPset ipsum» показывает, сколько отсечено превентивно.Разница простая: реактив — «эти атаковали и получили бан», превентив — «этих заблокировали ещё до попытки». Раньше в recidive искусственно загонялся list-3 ipsum (отсюда старое деление «списочные recidive»); теперь recidive — только настоящие рецидивисты, а превентив целиком на файрволе.
ipsum — публичный список вредоносных IP, обновляемый ежедневно. Монитор показывает число загруженных адресов на дашборде и карте атак и учитывает его в Оценке безопасности (−10, если набор не загружен).
Минимальный вариант без fail2ban — отдельный набор ipsum с блокировкой через iptables:
@reboot. Заодно команда create … -exist задаёт лимит maxelem 300000 (по умолчанию 65536 — level 1 не влезает, будет «Hash is full»):
ipsum и, если файрволом управляет установщик (свежий VPS — профили «Полная»/«Облегчённая»), подключает набор к UFW правилом DROP — трафик с этих IP реально блокируется. Правило стоит после ESTABLISHED,RELATED, поэтому текущие соединения (в т.ч. ваш SSH) не рвутся — режутся только новые подключения из списка. Набор восстанавливается при загрузке сервиса ipsum-load.service до файрвола (иначе UFW не поднялся бы), и обновляется кроном в 04:00. На уже настроенном сервере (панель, свой файрвол) установщик в файрвол не лезет — там ipsum остаётся списком для дашборда и карты атак, а правило DROP при желании добавляется вручную (минимальный вариант с iptables … --match-set ipsum … -j DROP — выше). При автоустановке вручную ничего делать не нужно.
Современная замена Fail2ban с коллективным threat intelligence: блокировки от сообщества плюс собственные правила. Требует отдельного 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) — известный баг конфиг-сниппета AIDE в Ubuntu 22.04. База не создаётся. Вынесите битый сниппет и повторите:
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 — он пишет лог от root в режиме 644, и монитор читает его без доп. групп:
chmod 755 /var/lib/aide и крон проверки в 02:00 — вручную ничего не нужно.
sudo aideinit && sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db.
Антивирусный сканер для Linux. Особенно полезен для проверки /var/www на PHP-шеллы и вредоносный код.
enable --now? Три типичные причины:
1. В конфиге осталась строка Example — clamd отказывается стартовать, пока она есть:
2. Не скачана база сигнатур — clamd не стартует без неё:
3. Просто загружается — clamd грузит ~8 млн сигнатур в память 30–60 сек. Подождите и проверьте: systemctl is-active clamav-daemon (статус activating → ещё грузит).
sudo journalctl -u clamav-daemon -n 30 --no-pager.
clamd только держит сигнатуры в памяти, сам он ничего не сканирует по расписанию. Панель показывает результаты планового скана, поэтому нужен крон, который сканирует и пишет лог. Автоустановка ставит обёртку /usr/local/bin/clamav-scan.sh и крон в 01:30 — после первого запуска заполнятся «Файлов проверено» и «Последнее сканирование». Запустить сразу, не дожидаясь расписания: sudo /usr/local/bin/clamav-scan.sh.
Linux Malware Detect (LMD) — сканер вредоносного ПО под веб-угрозы: PHP-шеллы, веб-бэкдоры, загрузчики. Использует движок 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 (тот работает на уровне HTTP, Suricata — на уровне TCP/IP).
/var/log/suricata/eve.json под root в режиме 750 на каталог, и веб-сервер (www-data) не может его прочитать. Откройте каталог на проход — файлы внутри остаются защищёнными:
Перехватывает системные вызовы через eBPF/kernel module и обнаруживает аномалии в реальном времени: shell из nginx, чтение /etc/passwd веб-процессом, запись в /bin и т.д.
journalctl -u falco (без sudo — через группу systemd-journal). Убедитесь, что www-data в этой группе — см. «Настройка sudo» (п.2) на странице ручной установки.
/etc/passwd, запись в системные каталоги). Ноль критических за сутки на спокойном сервере — здоровое состояние.
journalctl требует прав на журнал; чтобы панель видела события стабильно, автоустановка включает у Falco file_output → /var/log/falco/falco.log и службе ставит UMask=0022 (лог читается веб-сервером). Вручную на новой установке настраивать это не нужно.
ModSecurity — веб-файрвол (WAF) для Apache или Nginx. Блокирует атаки на уровне приложения: SQL-инъекции, XSS, обход путей, сканеры.
IncludeOptional /etc/modsecurity/*.conf, а пакет кладёт только modsecurity.conf-recommended — под маску *.conf он не попадает. Если не скопировать его в modsecurity.conf, SecRuleEngine остаётся Off: модуль загружен, правила CRS загружены, но трафик не проверяется и аудит-лог не создаётся. Промежуточный режим DetectionOnly только пишет события в лог, не блокируя запросы — панель показывает его жёлтым.
Доступ панели к аудит-логу. Лог /var/log/apache2/modsec_audit.log принадлежит root (права 640), веб-пользователь его не прочитает. Панель берёт данные через обёртку — создайте её:
SecRuleEngine без отступа: строки с отступом находятся внутри блоков <LocationMatch>/<Directory> (например, отключение WAF для phpMyAdmin) и глобальный режим не определяют.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 … — типичные места для 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) и при необходимости из /var/log/audit/audit.log командой tail. Оба должны быть в sudoers.
Следит за сервисами (nginx, php-fpm, mysql и т.д.) и перезапускает их при падении. Может слать алерты на email.
monit status. В /etc/monit/monitrc должен быть включён HTTP-интерфейс (блок set httpd с allow localhost), иначе monit status вернёт ошибку.
monitrc строка set httpd закомментирована (по умолчанию идёт как # set httpd port 2812 …). Раскомментируйте блок и разрешите localhost. (2) Сам по себе включённый httpd ничего не отслеживает — Monit считает только то, что описано check-стансами; без них список пуст даже при работающем интерфейсе. Минимальный рабочий конфиг:
conf.d с httpd на 2812 и набором проверок — на новой установке настраивать вручную не нужно.
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-клиенты и подобное). Когда такие профили есть, карточка «Профилей загружено» становится янтарной и показывает их число — например unconfined: 90 при 120 загруженных и 26 в enforce. Реально защищают только профили в enforce; на Ubuntu 22.04 (AppArmor 3.x) этого режима нет и цифры всегда сходятся.
unconfined, стоит только осознанно: они выключены не по ошибке, а потому что иначе ломается работа самих программ. Профили в complain — другое дело: там правила уже написаны и лишь не применяются.
debsums проверяет, что файлы установленных пакетов совпадают с контрольными суммами из репозитория — выявляет подменённые системные бинарники (дополняет AIDE). Полная проверка идёт 1–2 минуты, поэтому запускается по cron, а панель читает результат из data/debsums/debsums.log и сама раскладывает по категориям (важны только бинарники и библиотеки).
Задание — в root-крон (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 в фоне прямо из панели (не дожидаясь cron): показывает «Сканирование…» и по завершении сама обновляет отчёт. Для этого веб-пользователю нужна строка sudoers на запуск скрипта — установщик добавляет её автоматически в /etc/sudoers.d/monitor. Если панель ставилась вручную/раньше, допишите её тем же пользователем, что уже указан в файле:
Logwatch должен сохранять ежедневные отчёты в папку data/logwatch/ проекта в формате .txt. Монитор показывает последний отчёт и архив.
Сетевой монитор не требует установки — это встроенная страница панели. Она показывает сетевое состояние сервера из локальных источников:
/proc/net/dev;ip;ss;journalctl -k.Первые три источника работают без sudo, поэтому интерфейсы, трафик, соединения и порты видны сразу. Блок «События ядра» использует journalctl -k — он читается через группу systemd-journal («Настройка sudo», п.2), sudo не нужен. Проверить, что всё доступно веб-пользователю:
UFW BLOCK сюда не попадают — они на страницах «Брандмауэр UFW» и «Карта атак». Пустой блок с зелёной галкой = за сутки сетевых сбоев не было.
Встроенная страница показывает три вещи:
df); шкала краснеет при ≥90%;lsblk), только реальные (loop/snap скрыты);smartctl).Место и список устройств работают сразу, без настройки. Для SMART нужен пакет smartmontools. Веб-процесс не имеет прямого доступа к дисковым устройствам, поэтому SMART снимается по cron в файл data/disk/smart.txt, а панель его читает.
Задание — в root-крон (sudo crontab -e). Готовая обёртка smart-scan.sh кладётся в /usr/local/bin/ (chmod +x; см. сводку cron-задач) и сама пишет в data/disk/ панели.
Обёртка smart-scan.sh сама находит data/ панели — путь прописывать не нужно. Внутри lsblk -e7,11 исключает loop/cdrom.
Страница показывает историю нагрузки сервера — Load Average, занятость CPU и ожидание I/O, RAM/Swap, сетевой трафик (приём/передача), дисковый I/O (чтение/запись), заполнение диска и inodes, открытые файловые дескрипторы и MySQL-соединения, плюс текущее число TCP-соединений и процессов. Период переключается кнопками вверху: 24 часа, 7 дней, 30 дней.
Данные собирает cron/collect_metrics.php — раз в 5 минут пишет один «сырой» снимок счётчиков (/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; проценты и скорости страница считает сама по разнице между соседними снимками (заполнение диска/inodes/дескрипторов/MySQL-соединения — мгновенные значения, без пересчёта). Sudo не требуется — источники читаются без прав root.
Две глубины хранения. «Сырые» пятиминутные снимки живут сутки (плюс час запаса, чтобы у самой старой точки на графике был предшественник для расчёта скоростей). Каждый завершившийся час сворачивается в одну строку — этот почасовой ряд хранится 30 дней, и именно его читают виды «7 дней» и «30 дней». Так месяц истории стоит около 720 строк вместо примерно 8600.
Обёртка collect-metrics-all.sh (см. сводку cron-задач) сама находит все установленные инстансы панели на сервере и запускает cron/collect_metrics.php каждого от имени владельца сайта.
Топ процессов. Под графиками две таблицы по пять самых прожорливых по CPU процессов:
Обе таблицы всегда описывают сутки, даже когда графики показывают месяц: снимок процессов есть только у пятиминутных строк, а они дольше суток не хранятся.
ps, PHP-скрипт сбора и цепочка cron/sudo над ним) из списка исключаются — иначе они занимали бы первые строки в каждом снимке: ps в момент запуска показывает почти 100 % CPU. Остальные задания cron, запущенные в ту же минуту, в таблицу попадают — именно их и полезно там увидеть.
Оповещения о нагрузке (раздел «Настройки» → «Оповещения о нагрузке») — при превышении порога CPU/RAM/диска/inodes панель шлёт уведомление по всем включённым каналам (Telegram, Email, webhook, push — те же, что и у ежедневного отчёта; отдельно включать их для алертов не нужно), и ещё одно — когда метрика вернулась в норму. Повторно во время удержания порога не спамит: следующее уведомление придёт только после цикла «восстановилось → снова превысило».
collect_metrics.php при каждом запуске (раз в 5 минут) — отдельный cron не нужен. Состояние «уже уведомили / ещё нет» хранится в data/alerts_state.json, пороги — в настройках панели.
Суточный отчёт отвечает на вопрос «как обстоят дела на сервере». Сенсор отвечает на другой — «что произошло только что». Каждые 5 минут он опрашивает быстрые источники и записывает только то, что изменилось с прошлой проверки; страница «События безопасности» в меню показывает ленту находок.
Медленные проверки — Lynis, debsums, обновления пакетов, срок SSL — сенсор не трогает: их числа всё равно меняются раз в сутки, и они остаются за суточным отчётом.
Что он замечает — девять источников:
[Priority: 1] поднимает важность до критичной;FOUND в журнале сканирования;root (критично) и вход с адреса, который раньше не встречался (предупреждение);Инструмент, который не установлен или чей журнал панели недоступен, просто молчит — это не ошибка и не событие.
data/secwatch_state.json), и первый запуск только записывает её. Иначе при включении наблюдения пришло бы уведомление обо всём, что накопилось в журналах за месяцы.
Настройка — «Настройки» → «Наблюдение за событиями»:
23-7, когда предупреждения не отправляются.Уведомления идут по тем же каналам, что и суточный отчёт (Telegram, Email, webhook, push) — включать их отдельно не нужно. Все находки записываются в ленту независимо от того, ушло уведомление или нет, и хранятся 90 дней.
Лента. Фильтры: период (24 часа, 7, 30 или 90 дней), важность и источник; показываются последние 500 записей. Кнопка «Проверить сейчас» запускает ровно ту же проверку, что и cron, — удобно сразу после настройки, чтобы не ждать пять минут; она же покажет причину, если уведомление не ушло («ниже порога важности», «тихие часы», «не настроен ни один канал»). Красный счётчик у пункта меню — число критичных событий за последние 24 часа.
Карточка адреса. Клик по строке ленты или по строке блока Связанные адреса открывает всё, что известно про один адрес: хронологию его событий, страну и — первой строкой — вывод. Строка ленты ведёт на карточку, когда событие относится ровно к одному адресу; если адресов несколько, кликабельны сами адреса внутри строки. Выводов четыре:
Ниже хронологии — блок Что происходило на сервере в это же время: события, у которых адреса нет в принципе. AIDE не знает, кто изменил файл, ClamAV не знает, кто принёс заражённый файл. Показаны те из них, что пришлись на время активности адреса и на шесть часов после. Именно связка входа с тем, что случилось следом, и отличает попытку от состоявшегося доступа.
Расписание. Задание ставится в root-крон (sudo crontab -e) со смещением на 2 минуты от сбора метрик, чтобы две задачи не стартовали одновременно:
php cron/security_watch.php напрямую. Обёртка находит все установки панели на сервере и запускает проверку от владельца сайта — с теми же правами sudo, которыми панель пользуется из веба. Прямой вызов из root-крона создаст файл состояния 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Кроме них, панель проверяет файлы *access*.log и *requests*.log в каталогах /var/log/nginx/, /var/log/apache2/ и /var/log/httpd/. Так находится и журнал, который сайт пишет в собственный файл директивой CustomLog, — например, arciveo-monitor_requests.log, который создаёт установщик Arcivéo.
Читается только один журнал: если Nginx стоит перед Apache, сложение двух журналов посчитало бы каждый запрос дважды. Берётся первый журнал из списка выше, в который писали за последние сутки (найденные по маске проверяются после него, от свежих к старым); если за сутки не писали ни в один — самый свежий непустой. Поэтому журнал, опустевший после logrotate или оставшийся от выключенного веб-сервера, не заслоняет рабочий. Читается последний фрагмент журнала (3 МБ), результат кешируется на 5 минут — поэтому на нагруженном сайте выбранный период может быть покрыт не полностью; фактический охват подписан над графиком.
adm, а веб-пользователь в неё не входит. Установщик Arcivéo добавляет его в эту группу; после ручной установки поможет маленькая обёртка от root, которой разрешено ровно одно действие — показать журнал (так же устроена страница ModSecurity). Обёртка выбирает журнал по тем же правилам, что и панель. Команда выводится прямо на странице; вот она же. Вставляйте её целиком — это одна команда:
Веб-пользователь может отличаться от www-data — проверьте, под кем работает пул PHP-FPM сайта (ps -o user= -C php-fpm), и подставьте его в строку sudoers. Если в имени журнала нет ни access, ни requests, допишите его путь в начало строки L=… внутри обёртки.
Попытки известных уязвимостей. Панель сверяет запросы из журнала с сигнатурами двух десятков распространённых эксплойтов: PHP-CGI, обход каталогов в Apache, PHPUnit, Log4Shell, уязвимости роутеров, камер и VPN-шлюзов. Для каждой попытки она отвечает, может ли та сработать на этом сервере, и опирается на факты: установленные версии Apache и PHP, наличие Java, код ответа сервера на запрос файла. Красным отмечено только то, что действительно может сработать.
Защита веб-сервера. Панель запрашивает каждый сайт сервера через 127.0.0.1 и смотрит, что получает посетитель: видна ли версия веб-сервера и PHP, включён ли метод TRACE, есть ли защитные заголовки Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy и Content-Security-Policy. Сайты берутся из адреса, по которому открыта панель, и из файлов виртуальных хостов, если панель может их прочитать. Результат обновляется раз в 10 минут.
Если чего-то не хватает, под таблицей появляется одна команда. Она создаёт отдельный файл zz-arciveo-hardening.conf и перезагружает веб-сервер только после проверки конфигурации; заголовки, которые сайт уже отдаёт сам, не дублируются. CSP одной строкой не предлагается: политику собирают под конкретный сайт, иначе он перестанет загружать свои скрипты, стили и шрифты. Отменить изменения на Apache можно так:
ServerSignature) не помечается, если версия веб-сервера уже скрыта: без версии она показывает только название сервера и имя хоста.
Страница «Карта атак» определяет страну по IP командой geoiplookup. Без пакета GeoIP страны не определятся и точки на карте не появятся:
/usr/share/GeoIP/GeoIP.dat читается всеми, результаты кешируются в tmp/geoip_cache.json. Сама карта (Leaflet + плитки OpenStreetMap) грузится в браузере — нужен интернет на компьютере, где открыта панель.
Две встроенные карточки дашборда, показывающие не «вкл/выкл» инструмента, а реальную защищённость сервера. Установки не требуют, читаются локально без sudo.
Внешняя экспозиция — сколько сервисов слушают все интерфейсы (0.0.0.0/[::]) и доступны извне. Подсвечивает красным, если наружу торчат СУБД или кэш (MySQL, PostgreSQL, Redis, MongoDB, Memcached, Elasticsearch) — это прямая дыра (−10 к Оценке безопасности). Источник: ss -tuln.
127.0.0.1 (bind-address в конфиге MySQL/PostgreSQL, bind 127.0.0.1 в Redis) или закройте порт в UFW.
127.0.0.1 (loopback), виден только самому серверу — извне на него не попасть, даже если порт «открыт». Поэтому Postfix на порту 25, привязанный к loopback, безопасен: автонастройка ставит inet_interfaces = loopback-only (плюс нейтральный smtpd_banner — закрывает замечание Lynis MAIL-8818 о раскрытии версии). Карточка «Внешняя экспозиция» считает наружу только то, что слушает 0.0.0.0/[::]; loopback-сервисы туда не попадают.
/etc/postfix/main.cf задайте smtpd_banner = $myhostname ESMTP (без версии и ОС) и inet_interfaces = loopback-only, затем sudo systemctl restart postfix.
Обновления безопасности — сколько security-патчей ждут установки и нужна ли перезагрузка после обновления ядра (−5 к Оценке безопасности при наличии патчей). Источник: /usr/lib/update-notifier/apt-check, файл /var/run/reboot-required. Детальный список — на странице «Обновления безопасности».
update-notifier-common). Если apt-check отсутствует — монитор считает патчи через apt-get -s upgrade.
Автообновления безопасности (unattended-upgrades) — на странице «Обновления безопасности» отдельная карточка показывает, включена ли автоматическая установка security-патчей и когда она запускалась в последний раз. Sudo не нужен — статус читается через apt-config dump.
Бэкап — главная страховка: потеря данных страшнее любого взлома. Нужны две вещи — бэкап сервера/сайтов и отдельно бэкап БД панели (там пользователи, ключи WebAuthn, настройки, лицензия).
Вариант A — HestiaCP: вкладка Backup у пользователя → кнопка создания бэкапа (или по расписанию в настройках сервера). Бэкап включает сайты и их БД.
Вариант B — вручную (cron): дамп БД + архив каталога data/ панели:
Обновление до новой версии. Сначала сделайте бэкап. Затем перезалейте файлы кода, сохранив свои данные:
public/, includes/, assets/, cron/, database/, а также корневые .htaccess (фронт-контроллер — маршрутизацию нельзя оставлять от старой версии), manifest.json, sw.js;config.php (данные БД), data/ (отчёты), logs/, tmp/ (сессии и кэш).SSH_FX_PERMISSION_DENIED — Permission denied. Файлы панели принадлежат www-data (так их выставили при установке), а SFTP-клиент подключается под вашим пользователем — прав на запись у него нет. Отдавать www-data всю панель «чтобы работало» — как раз то, что приводит к этой ошибке; ниже три способа, любой решает проблему.
data/ (отчёты), tmp/ (сессии и кэш), logs/; они остаются за www-data. Остальное — код, и веб-серверу он нужен лишь на чтение, которое даёт группа www-data с правами 644. Побочный выигрыш: при уязвимости в PHP файлы панели уже не переписать. На хостинг-панелях (HestiaCP и подобные) вариант A не нужен: там файлы сайта и так принадлежат аккаунту, под которым вы заходите по SFTP, а веб-сервер читает их по группе.
chmod по файлам сбрасывает ACL-маску, и доступ молча пропадает. Если после «наведения порядка в правах» заливка снова упирается в Permission denied — повторите обе команды setfacl.
2 в варианте C — это 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.adm, cron-задания.Панель уже работает, и на том же сервере нужен ещё один сайт — свой домен рядом с монитором. Сервер после автонастройки — обычный Apache + PHP-FPM, поэтому сайту нужны три вещи: свой каталог, свой vhost и свой сертификат. Панель при этом не трогаем: она следит за сервером целиком, второй экземпляр для второго домена не нужен.
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 у регистратора домена создайте A-запись на IP этого сервера:
Через несколько минут проверьте: dig +short site2.example.com должен вернуть IP сервера.
2. Каталог сайта.
3. vhost. Блок вставляется в терминал целиком — путь к сокету PHP-FPM определяется сам:
4. Включите сайт и проверьте конфигурацию перед перезагрузкой:
5. SSL. certbot уже установлен автонастройкой; DNS к этому моменту должен указывать на сервер:
Третий и последующие домены добавляются так же — повторите шаги 1–5, меняя домен и каталог.
Host не совпал ни с одним ServerName (заход по IP или чужой домен, направленный на ваш сервер), Apache отдаёт первый по алфавиту включённый сайт из /etc/apache2/sites-enabled/. Стандартный 000-default автонастройка отключает, поэтому таким «дежурным» остаётся vhost панели (arciveo-monitor.conf) — на работу сайтов по их собственным именам это не влияет. Нужно, чтобы по IP открывался другой сайт, — назовите его файл так, чтобы он шёл раньше по алфавиту (например 000-site2.conf).
site2_error.log и site2_access.log в /var/log/apache2/.
.htaccess (фронт-контроллер), и вложенный сайт будет отдавать не то, что вы ожидаете. Держите сайты рядом: /var/www/monitor, /var/www/site2.
Если вы не можете войти — всё чинится напрямую в БД с сервера. Откройте БД (имя — из config.php):
Потерян ключ WebAuthn (не проходит второй фактор) — отключите 2FA, войдите по паролю, зарегистрируйте новый ключ:
Забыли пароль — задайте новый хеш (сгенерируйте его на сервере и подставьте):
Заблокировали себя IP-фильтром — отключите ограничение:
sudo mysql на сервере, либо phpMyAdmin / раздел БД в панели хостинга. После восстановления заново включите WebAuthn и IP-фильтр.
Сводка заданий — в root-крон сервера (добавляются через sudo crontab -e). Оставьте только строки тех инструментов, что используете; поправьте пути под свой сервер.
sudo crontab -l и что cron-служба активна.
TIMEZONE из config.php. Константа TIMEZONE влияет только на PHP (как панель показывает даты), но cron-демон запускает задания по системному времени ОС. Если пояс сервера не совпадает с вашим, отчёт «08:00» придёт не в то время. Пример: сервер стоит в другом поясе (Europe/Berlin, UTC+2), а вы — в Киеве (UTC+3) → отчёт «08:00» придёт в 09:00 по-вашему. Проверьте и при необходимости приведите пояс системы к своему:
0 8 * * * сработает в 08:00 по местному времени. Иначе сдвигать пришлось бы сам cron, но при переходе на зимнее/летнее время сдвиг снова разойдётся — поэтому правильнее настроить пояс системы.
crontab.txt) лежат в папке system/ рядом с проектом, вне public_html. Это не часть сайта — в веб-корень их загружать не нужно; разместите на сервере по системным путям (как в 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) — антивирусный скан ClamAV по опасным путям (web, home, temp); пишет сводку в /var/log/clamav/scan.log, откуда её читает страница ClamAV (строка 01:30 в crontab выше);load-ipsum.sh → /usr/local/bin/ (chmod +x) — обновляет ipset-набор ipsum (level 1) на месте, не разрывая действующих правил файрвола (строка 04:00 в crontab выше);daily-report-all.sh → /usr/local/bin/ (chmod +x) — запускает отчёт cron/daily_report.php панели (строка 08:00 в crontab выше);daily_report.php — уже входит в панель (cron/daily_report.php), запускается через daily-report-all.sh, отдельно ставить не нужно;collect-metrics-all.sh → /usr/local/bin/ (chmod +x) — запускает cron/collect_metrics.php панели (страница «Производительность», строка */5 в crontab выше); collect_metrics.php уже входит в панель, отдельно ставить не нужно;security-watch-all.sh → /usr/local/bin/ (chmod +x) — запускает cron/security_watch.php панели от имени владельца сайта (страница «События безопасности», строка 2-57/5 в crontab выше); 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-крон — он будет принадлежать root, и вкладка «Журнал cron» в панели не сможет его ни прочитать, ни очистить. Создайте файл заранее от имени веб-пользователя (владелец каталога сайта; на HestiaCP это аккаунт, напр. admin) — тогда root-крон будет лишь дописывать, не меняя владельца:
stat -c %U /path/to/monitor.
sudo crontab -e), иначе оно будет выполняться дважды.
sudo crontab (это была бы прямая эскалация до root любым, кто получит доступ к сессии панели), а узкий скрипт с двумя командами (list/set), который трогает только свой блок между служебными комментариями. Установите один раз:
www-data — проверьте, под кем работает пул PHP-FPM сайта (ps -o user= -C php-fpm), и подставьте его в sudoers-строку.
public/crontab_monitor.php загружен по FTP/SFTP под другим системным пользователем (например, root), чем остальные файлы сайта, веб-сервер не сможет его прочитать. Сверьте владельца и права с соседним файлом и приведите в соответствие:
Монитор определяет наличие инструментов через 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 каталогом домена, поэтому PHP-функции file_exists(), file_get_contents(), filemtime() по системным путям (/var/lib/aide, /var/log, /proc…) блокируются. Монитор обходит это, читая такие пути штатными системными командами (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.
Монитор подключается к MySQL под пользователем из config.php, у которого доступ только к своей базе. MySQL показывает в information_schema лишь базы с привилегиями — поэтому остальные не видны.
Чтобы монитор видел все БД, выдайте этому пользователю право только на чтение (один раз от root; подставьте имя пользователя из config.php):
sudo mysql панель не использует: список баз берётся через её собственное PDO-подключение.
PostgreSQL требует доступ уровня пользователя postgres, которого у веб-пользователя панели нет. Открывать из PHP широкий sudo psql небезопасно — вместо этого панель вызывает узкую обёртку без параметров, которая только печатает версию, число соединений и список баз с размерами. Создайте её:
monitor-pgstat из sudoers (шаг 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; после обновления ядра перезагрузите сервер.