Това е ръководство за инсталиране, настройка и поддръжка на 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, имейл, webhook и push в браузъра. Те са независими — включете които пожелаете, дори и четирите. По същите канали вървят ежедневният доклад за сигурността, известията за натоварване и находките на сензора за събития; настройват се веднъж, тук, в раздел „Настройки“.
Telegram. Нужни са токен на бота и chat id:
@BotFather → /newbot → получете токен от вида 123456:ABC....@userinfobot или отворете https://api.telegram.org/bot<TOKEN>/getUpdates и намерете "chat":{"id":...}.Имейл. Два начина по избор в „Настройки“ → 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 дни) или чакащи обновления за сигурност. Фоновият шум — SSH опити на ботове, IP адреси, банати от fail2ban, известия на 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 вече го няма в тях). По-надеждно е да добавите свой cron с явен --config — той записва лога от root в режим 644 и мониторът го чете без допълнителни групи:
chmod 755 /var/lib/aide и cron за проверка в 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 и т.н.) и ги рестартира при срив. Може да изпраща известия по имейл.
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.
Страницата показва историята на натоварването на сървъра за последните 24 часа — 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 на всяка от името на собственика на сайта.
Топ процеси. Под графиките има две таблици с петте най-натоварващи процесора процеса:
И двете таблици винаги описват последните 24 часа, дори когато графиките показват месец: снимка на процесите имат само петминутните редове, а те не се пазят по-дълго от денонощие.
ps, PHP скриптът за събиране и веригата cron/sudo над него) се изключват от списъка — иначе биха заемали първите редове във всяка снимка: ps в момента на стартиране показва почти 100 % CPU. Другите cron-задачи, стартирали в същата минута, се появяват — точно за това е таблицата.
Известия за натоварване (раздел „Настройки“ → „Известия за натоварване“) — при превишаване на прага за CPU/RAM/диск/inodes панелът изпраща известие по всички включени канали (Telegram, имейл, 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, имейл, webhook, push) — не е нужно да се включва нищо отделно. Всички находки се записват в списъка независимо от това дали е изпратено известие, и се пазят 90 дни.
Списъкът със събития. Филтри: период (24 часа, 7, 30 или 90 дни), важност и източник; показват се последните 500 записа. Бутонът „Провери сега“ стартира точно същата проверка като cron — удобно веднага след настройката, за да не се чака пет минути; той посочва и причината, когато известие не е изпратено („под прага на важност“, „тихи часове“, „не е настроен нито един канал за известия“). Червеният брояч до елемента от менюто е броят критични събития за последните 24 часа.
Карта на адреса. Щракване върху ред в списъка със събития или в блока Свързани адреси отваря всичко, което се знае за един адрес: хронологията на събитията му, държавата и на първия ред заключението. Ред от списъка отваря картата, когато събитието се отнася точно за един адрес; ако адресите са няколко, връзките са самите адреси в реда. Заключенията са четири:
Под хронологията е блокът Какво се е случвало на сървъра по същото време: събития, които изобщо нямат адрес. AIDE не знае кой е променил файла, ClamAV не знае кой е донесъл заразения. Показани са тези, които попадат в активността на адреса и шестте часа след нея. Именно връзката между входа и това, което последва, отличава опита от осъществен достъп.
Разписание. Задачата се добавя в root-crontab (sudo crontab -e), изместена с 2 минути спрямо събирането на метрики, за да не стартират двете едновременно:
php cron/security_watch.php. Обвивката намира всички инсталации на панела на сървъра и стартира проверката от името на собственика на сайта — със същите права sudo, които панелът използва от уеб. Пряко извикване от root-crontab би създало файла на състоянието data/secwatch_state.json със собственик root и бутонът „Провери сега“ би спрял да работи.
Страницата „Уеб сървър“ разбира журнала за достъп и показва колко заявки е имало, каква част от тях е завършила с грешка и кой ги е правил. ModSecurity отговаря на въпроса „какво е блокирано“, тази страница — на въпроса „какво изобщо е стигало до сайта“.
Какво се вижда: брой заявки, RPS, дял на грешките, отделен брояч 5xx и обемът отдаден трафик; графика на заявките по часове; разпределение на кодовете 2xx/3xx/4xx/5xx; чести адреси, чести IP, чести грешки (код плюс път) и клиенти (User-Agent). Период: 24 часа или 7 дни.
Източникът е журналът за достъп във формат combined, затова стават и Nginx, и Apache, и не е нужен допълнителен модул. Панелът търси журнала сред стандартните файлове:
/var/log/nginx/access.log/var/log/apache2/access.log/var/log/apache2/other_vhosts_access.log/var/log/httpd/access_logОсвен тях панелът проверява файловете *access*.log и *requests*.log в директориите /var/log/nginx/, /var/log/apache2/ и /var/log/httpd/. Така се намира и журналът, който сайтът записва в собствен файл с директивата CustomLog — например arciveo-monitor_requests.log, който създава инсталаторът на Arcivéo.
Чете се само един журнал: когато Nginx стои пред Apache, събирането на два журнала би преброило всяка заявка два пъти. Взема се първият журнал от списъка по-горе, в който е писано през последното денонощие (намерените по маска се проверяват след него, от най-новите към по-старите); ако през денонощието не е писано в нито един — най-новият непразен. Затова журнал, изпразнен от logrotate или останал от спрян уеб сървър, не закрива работещия. Чете се последният фрагмент от журнала (3 MB), а резултатът се кешира за 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.
Обновления за сигурност — колко пачове за сигурност чакат инсталиране и нужно ли е рестартиране след обновяване на ядрото (−5 към Оценката за сигурност при наличие на пачове). Източник: /usr/lib/update-notifier/apt-check, файл /var/run/reboot-required. Подробен списък — на страницата „Обновления за сигурност“.
update-notifier-common). Ако apt-check липсва — Мониторът брои пачовете чрез apt-get -s upgrade.
Автообновления за сигурност (unattended-upgrades) — на страницата „Обновления за сигурност“ отделна карта показва дали е включено автоматичното инсталиране на пачове за сигурност и кога е стартирало за последно. Не е нужен sudo — статусът се чете чрез apt-config dump.
Резервното копие е основната застраховка: загубата на данни е по-страшна от всеки пробив. Нужни са две неща — резервно копие на сървъра/сайтовете и отделно резервно копие на базата данни на панела (там са потребителите, 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-crontab на сървъра (добавят се чрез 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-cron — той ще принадлежи на root и разделът „Журнал на cron“ в панела няма да може нито да го чете, нито да го изчиства. Създайте файла предварително от името на уеб-потребителя (собственик на каталога на сайта; при HestiaCP това е акаунт, напр. admin) — тогава root-cron само ще дописва, без да сменя собственика:
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, какъвто уеб потребителят на панела няма. Отварянето на широк sudo psql от PHP е несигурно — вместо това панелът извиква тясна обвивка без параметри, която само отпечатва версията, броя връзки и списъка с бази с техните размери. Създайте я:
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; след обновяване на ядрото рестартирайте сървъра.