Това е ръководство за инсталиране, настройка и поддръжка на Arcivéo Monitor. Разделите са групирани: общ преглед, разгръщане на панела, свързване на инструментите за сигурност, вградени модули и диагностика. Командите могат да се копират с бутона вдясно.
Инсталирането на панела е на отделни страници стъпка по стъпка. Изберете начин:
Arcivéo Monitor — панел за сигурност на сървъра. Събира данни от инсталираните инструменти (Fail2ban, UFW, Lynis, ModSecurity, AIDE, ClamAV, Auditd, CrowdSec, Suricata, Falco и др.) и ги показва в единен интерфейс с табло, карта на атаките и подробни страници за всеки инструмент.
Мониторът не е активно средство за защита — той сам по себе си не блокира атаки. Задачата му е да обедини информацията от вече работещите инструменти и да я представи в удобен вид.
Мониторът работи само локално — трябва да е инсталиран на същия сървър, който наблюдава. Няма SSH или отдалечен API.
Всички команди (fail2ban-client, ufw status, ipset list и т.н.) панелът изпълнява от името на потребителя на уеб сървъра (обикновено www-data, при хостинг панелите — акаунтът на сайта) с ограничен набор права sudo — само за конкретни инструменти, без общ root достъп. Резултатите се обработват и показват в браузъра.
Оценката започва от максимума и намалява за всеки открит проблем:
PermitRootLogin yes) — −20Резултат: 80+ = Защитен, 60–79 = Внимание, <60 = Под заплаха.
WebAuthn — стандарт за удостоверяване без парола чрез хардуерен ключ. Поддържа YubiKey, Touch ID, Face ID, Windows Hello, Passkey.
След вход с парола системата изисква потвърждение чрез регистриран ключ. Дори паролата да изтече — без физически ключ или биометрия вход е невъзможен.
За настройка отворете Ключове WebAuthn в страничното меню и натиснете „Регистриране на ключ“. Регистрирайте веднага два ключа: ако единственият ключ се изгуби или повреди, входът в панела с него ще е невъзможен.
Панелът може да изпраща отчет за сигурността в Telegram и по имейл (ръчно и по график). Настройва се в раздел „Настройки“.
Telegram. Нужни са токен на бота и chat id:
@BotFather → /newbot → получете токен от вида 123456:ABC....@userinfobot или отворете https://api.telegram.org/bot<TOKEN>/getUpdates и намерете "chat":{"id":...}.Имейл. Два начина по избор в „Настройки“ → Email:
re_...) и потвърден домейн на подателя.Статус на отчета: „ВНИМАНИЕ“ или „ОК“. Заглавието става „ВНИМАНИЕ“ само при реален проблем или чакащо действие: открита заплаха от 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.
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-връзки и процеси.
Данните се събират от 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. Точките по-стари от 24 часа се изтриват автоматично при всеки запис.
Обвивката collect-metrics-all.sh (вж. обобщението на cron-задачите) сама намира всички инсталирани инстанции на панела на сървъра и стартира cron/collect_metrics.php на всяка от името на собственика на сайта.
Известия за натоварване (раздел „Настройки“ → „Известия за натоварване“) — при превишаване на прага за CPU/RAM/диск/inodes панелът изпраща известие в Telegram/Email (същите канали като при дневния отчет — не е нужно да ги включвате отделно за известията), и още едно — когато метриката се върне в норма. По време на задържане на прага не спами повторно: следващото известие ще дойде едва след цикъла „върна се в норма → отново превиши“.
collect_metrics.php при всяко стартиране (веднъж на 5 минути) — отделен cron не е нужен. Състоянието „вече известено / още не“ се съхранява в data/alerts_state.json, а праговете — в настройките на панела.
Страницата „Карта на атаките“ определя държавата по 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-задачи.Ако не можете да влезете — всичко се поправя директно в базата данни от сървъра. Отворете базата данни (името е от 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 вече е включен в панела, не е нужно да се поставя отделно;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; след обновяване на ядрото рестартирайте сървъра.