Изцяло ръчна инсталация: от току-що закупен VPS до работеща табло, стъпка по стъпка.
Подготовката на сървъра, създаването на сайта, базата данни, config.php и SSL са описани тук.
Командите за всеки инструмент за сигурност и за cron са в
справочника с ЧЗВ, връзките са по пътя.
Основно правило: когато променяте SSH или защитната стена, не затваряйте текущата връзка, докато не проверите новата в отделен прозорец. Ако все пак загубите достъп — почти всички хостъри дават аварийна конзола (VNC/Recovery) в контролния панел.
01. Купих VPS с Ubuntu/Debian — откъде да започна
След покупката хостинг доставчикът изпраща: IP адрес, потребителско име (обикновено root) и парола (или SSH ключ). Това е достатъчно за вход. Ред на действията (всяка стъпка е раздел по-долу):
Свързване към сървъра по SSH;
Обновяване на системата, задаване на име на хоста и часова зона;
Създаване на обикновен потребител с права sudo (не работете под root);
Настройка на вход по SSH ключ и изключване на входа с парола;
Включване на защитната стена и автозащитата;
(по желание) инсталиране на панела за управление HestiaCP — уеб сървър, БД, поща „в комплект“.
02. Първо свързване по SSH
SSH е защитен терминал към сървъра. Заменете 203.0.113.10 със своя IP.
203.0.113.10 е пример, несъществуващ адрес (запазен за документация). Не го въвеждайте както е — заменете го с реалния IP на вашия сървър от писмото на хостинга. Иначе няма да има връзка.
Windows 10/11: отворете PowerShell или „Терминал“ и използвайте вградения ssh (или клиентите PuTTY / MobaXterm). macOS / Linux: отворете „Терминал“.
# Вход като root (паролата е изпратена от хостинга):
ssh root@203.0.113.10
# Ако хостингът е дал файл-ключ вместо парола:
ssh -i път/до/ключа root@203.0.113.10
При първото свързване SSH ще попита за „authenticity of host“ — въведете yes. Паролата не се показва при въвеждане (това е нормално). Ако хостингът е дал временна парола — сменете я с командата passwd.
03. Обновяване на системата и базова настройка
Първата стъпка — обновете всички пакети и задайте име на хоста и часова зона.
# Обновяване на системата:
apt update && apt upgrade -y
# Основни инструменти:
apt install -y curl wget ufw fail2ban unattended-upgrades
# Часова зона (пример) и име на хоста:
timedatectl set-timezone Europe/Sofia
hostnamectl set-hostname myserver
# Автоматични обновления за сигурност:
dpkg-reconfigure -plow unattended-upgrades
Списък с часовите зони — timedatectl list-timezones. Ако в края на обновяването се появи син прозорец „Daemons using outdated libraries“ — отбележете всички услуги (Интервал) и натиснете OK, това е безопасно.
04. Създаване на потребител със sudo
Постоянната работа под root е несигурна. Създайте обикновен потребител и му дайте права sudo (изпълняване на команди като администратор при нужда). Заменете deploy с произволно име.
# Създаване на потребител (задава парола и пита за данни — може с Enter):
adduser deploy
# Добавяне в групата sudo:
usermod -aG sudo deploy
# Проверка (под root):
su - deploy
sudo whoami # трябва да изведе: root
exit
По-нататък влизайте на сървъра вече с този потребител: ssh deploy@203.0.113.10, а административните команди изпълнявайте с префикс sudo.
05. SSH-ключове и изключване на входа с парола
Влизането с ключ е по-сигурно от парола: паролата може да бъде отгатната, ключът — практически не. Първо създаваме ключ на собствения си компютър, копираме го на сървъра, проверяваме входа — и едва тогава изключваме паролата.
Стъпка 1. Създайте ключ на своя компютър (Windows PowerShell / macOS / Linux):
ssh-keygen -t ed25519 -C "my-laptop"
# Enter на всички въпроси (ключът ще се запише в ~/.ssh/id_ed25519)
Стъпка 3. Проверете влизането с ключ в нов прозорец — трябва да ви пусне без парола:
ssh deploy@203.0.113.10
Не изпълнявайте Вариант B, докато входът с ключ не е проверен и не работи (Стъпки 1–3), и не затваряйте работната сесия. Той изключва входа с парола за всички потребители, включително root. Без работещ ключ ще загубите напълно достъпа до сървъра — да го върнете ще може само през конзолата на хостинга. Нямате ключ — изберете Вариант A.
Стъпка 4. Затегнете достъпа по SSH. Настройките слагаме в отделен файл, основния конфиг не пипаме. Изберете вариант според ситуацията:
Вариант A — само затваряне на root, паролата остава. Ключ не е нужен, няма да загубите достъп:
Вариант B — пълен hardening. Изключване на входа с парола и root само с ключ. Изпълнявайте само след като се уверите, че входът с ключ работи:
sudo tee /etc/ssh/sshd_config.d/00-hardening.conf >/dev/null <<'EOF'
PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin prohibit-password
KbdInteractiveAuthentication no
EOF
sudo systemctl restart ssh
И при двата варианта root с парола е затворен. PermitRootLogin no забранява root напълно, prohibit-password — оставя входа само с ключ (за администриране влизайте с deploy и използвайте sudo). Ако искате да смените порта на SSH — добавете реда Port 2222, но първо отворете новия порт във файъруола (следващия раздел) и проверете входа, иначе ще си затворите достъпа.
06. Основна защитна стена и автозащита
Затворете всичко излишно със защитната стена и включете fail2ban (банва брутфорс на пароли по SSH). Първо разрешете SSH, иначе след включване на UFW ще загубите достъп.
# Разрешаване на SSH (или вашия порт, ако сте го променяли) и уеб:
sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp
# Включване на защитната стена:
sudo ufw enable
sudo ufw status verbose
# fail2ban — защита на SSH от брутфорс (базовият профил е активен веднага):
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd
Това е минимумът. Работните настройки на fail2ban, блок-листът ipsum, разширеният UFW и останалите инструменти са в групата „Инструменти за сигурност“ на справочника. Самият панел Arcivéo Monitor нагледно ще покаже статуса на всичко това.
07. Инсталиране на панела HestiaCP (по избор)
HestiaCP — безплатен панел за управление на хостинг: инсталира и настройва уеб сървър (nginx + apache), PHP, база данни (MariaDB), поща, DNS и SSL сертификати, дава уеб интерфейс за сайтове. Удобен е, ако не искате да настройвате всичко ръчно и планирате да разположите сайтове (вкл. самия панел Arcivéo Monitor).
Инсталирайте HestiaCP на чист сървър (нова поддържана Ubuntu/Debian, минимум ~1–2 ГБ RAM), преди инсталирането на други уеб сървъри и БД — иначе ще има конфликти. Инсталирането отнема 10–20 минути и рестартира сървъра.
# Изтегляне на инсталатора и стартиране:
wget https://raw.githubusercontent.com/hestiacp/hestiacp/release/install/hst-install.sh
sudo bash hst-install.sh
Инсталаторът ще поиска email и име на хоста, след което ще постави целия стек. След рестарта панелът е достъпен на адрес https://YOUR_IP:8083 (потребителското име и паролата инсталаторът показва накрая).
HestiaCP сам управлява UFW и fail2ban — не е нужно да ги настройвате отделно, той ще ги подхване. SSH ключовете и изключването на паролата (предишния раздел) все пак направете.
08. Системни изисквания и ionCube
Панелът е PHP приложение върху типичен LAMP/LEMP стек:
ОС: Linux (препоръчват се Ubuntu/Debian);
Уеб сървър: nginx или Apache с PHP-FPM;
PHP 8.0+ с разширенията: pdo_mysql, openssl, curl, json, mbstring;
ionCube Loader — разширение за PHP, необходимо за работата на панела;
БД: MySQL 5.7+ или MariaDB 10.3+;
HTTPS — задължително (входът и WebAuthn работят само по https);
sudo за потребителя на уеб сървъра (ограничен набор — стъпка 13).
# Проверка на версията на PHP и разширенията:
php -v
php -m | grep -iE 'pdo_mysql|openssl|curl|mbstring|ioncube'
Инсталиране на ionCube Loader (ако още не е наличен). На хостинг с панел (HestiaCP, cPanel) ionCube се включва с отметка в настройките на PHP. Ръчно на Ubuntu/Debian:
# Разбиране на версията на PHP и каталога с разширения:
php -v
EXTDIR=$(php -r 'echo ini_get("extension_dir");'); PHPVER=$(php -r 'echo PHP_MAJOR_VERSION.".".PHP_MINOR_VERSION;')
# Изтегляне и разархивиране на лоудърите (64-bit):
cd /tmp
wget -q https://downloads.ioncube.com/loader_downloads/ioncube_loaders_lin_x86-64.tar.gz
tar xzf ioncube_loaders_lin_x86-64.tar.gz
# Копиране на лоудъра за вашата версия на PHP в каталога с разширения:
sudo cp ioncube/ioncube_loader_lin_${PHPVER}.so "$EXTDIR"/
# Активиране (CLI + PHP-FPM) и рестартиране:
echo "zend_extension=ioncube_loader_lin_${PHPVER}.so" | sudo tee /etc/php/${PHPVER}/mods-available/ioncube.ini
sudo phpenmod ioncube
sudo systemctl restart php${PHPVER}-fpm
# Проверка — в изхода ще се появи редът "with the ionCube PHP Loader":
php -v
Версията на лоудъра трябва да съвпада с версията на PHP (например ioncube_loader_lin_8.1.so за PHP 8.1). Ако използвате няколко версии на PHP — активирайте лоудъра за всяка от тях.
09. Домейн и DNS
За да отваряте панела на адрес като monitor.example.com и да получите безплатен SSL, е нужен домейн, сочещ към вашия сървър. В панела за управление на DNS създайте A-запис:
Тип: A
Име: monitor (поддомейн → monitor.example.com)
или @ (корен на домейна → example.com)
Стойност: 203.0.113.10 ← IP на вашия сървър
TTL: 3600
След няколко минути проверете дали домейнът сочи към сървъра:
dig +short monitor.example.com # трябва да върне вашето IP
# или, ако няма dig:
getent hosts monitor.example.com
SSL-сертификатът на Let's Encrypt се издава само за домейн — DNS трябва да сочи към сървъра преди издаването на сертификата.
10. Създайте сайт и качете файловете на панела
Apache: DocumentRoot — към корена на панела, НЕ към public/. Стиловете (CSS/JS), sw.js, manifest.json се намират в assets/ до public/ и се заявяват от корена на сайта. Кореновият .htaccess е фронт-контролер. Ако при Apache зададете DocumentRoot към public/, панелът ще се отвори без стилове. При чист nginx е обратното: за корен се взема public/, а assets/ се обслужват с отделно правило (вижте блока за nginx по-долу).
Файловете на панела (архивът с дистрибуцията) се изтеглят след покупката в профила my.arciveo.com → „Изтегляния“. Разархивирайте архива преди качване.
1) Създайте директория за панела и качете в нея съдържанието на дистрибуцията (така че вътре да се окажат public/, assets/, config.php и т.н.):
sudo mkdir -p /var/www/monitor
# после качете файловете на дистрибуцията в /var/www/monitor (FileZilla / WinSCP / scp)
2) Настройте уеб сървъра.Apache: DocumentRoot — към корена на панела (НЕ към /public); AllowOverride All е задължителен. Пътят до сокета на PHP-FPM се определя автоматично. Блокът се поставя в терминала изцяло:
PHPSOCK=$(ls -1 /run/php/php*-fpm.sock 2>/dev/null | head -1) # авто-определяне на сокета PHP-FPM
sudo tee /etc/apache2/sites-available/monitor.conf > /dev/null <<'EOF'
<VirtualHost *:80>
ServerName monitor.example.com
DocumentRoot /var/www/monitor
<Directory /var/www/monitor>
AllowOverride All
Require all granted
</Directory>
<FilesMatch \.php$>
SetHandler "proxy:unix:__PHPSOCK__|fcgi://localhost"
</FilesMatch>
</VirtualHost>
EOF
sudo sed -i "s#__PHPSOCK__#${PHPSOCK}#" /etc/apache2/sites-available/monitor.conf
sudo a2dissite 000-default.conf
sudo a2ensite monitor.conf
sudo apache2ctl configtest
sudo systemctl reload apache2
nginx: nginx няма .htaccess, затова за корен вземаме public/, а assets/, sw.js, manifest.json (едно ниво по-горе) обслужваме с отделно правило:
PHPSOCK=$(ls -1 /run/php/php*-fpm.sock 2>/dev/null | head -1) # авто-определяне на сокета PHP-FPM
sudo tee /etc/nginx/sites-available/monitor.conf > /dev/null <<'EOF'
server {
listen 80;
server_name monitor.example.com;
root /var/www/monitor/public;
index index.php;
# assets, service worker и manifest са едно ниво над public/
location ~ ^/(assets/|sw\.js|manifest\.json) { root /var/www/monitor; }
location / { try_files $uri $uri/ /index.php?$query_string; }
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:__PHPSOCK__;
}
}
EOF
sudo sed -i "s#__PHPSOCK__#${PHPSOCK}#" /etc/nginx/sites-available/monitor.conf
sudo ln -s /etc/nginx/sites-available/monitor.conf /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
Качване на файлове — SFTP/SCP (FileZilla, WinSCP) или scp:
# Пример чрез scp от локалния компютър:
scp -r ./monitor/* deploy@203.0.113.10:/var/www/monitor/
Задайте права на файловете — това е задължителна стъпка. Ако сте качвали като root или по SFTP, файловете принадлежат на root и уеб сървърът (www-data) няма да може да ги прочете — панелът ще се отвори празен или с грешка 403 (в лога: .htaccess unreadable / directory not executable). Командата по-долу поправя това:
# Нормализираме правата на целия уеброут: директория, създадена от root, е недостъпна
# за уеб сървъра (www-data) — без това панелът връща празна страница или 403.
# Apache работи като www-data; ако имате друг уеб потребител — заменете го.
cd /var/www/monitor
# Работните папки създаваме ПРЕДИ chown — иначе новите директории ще останат root:root
# и при chmod 750 уеб сървърът (www-data) няма да може да пише в тях.
sudo mkdir -p data/lynis data/logwatch tmp logs
sudo chown -R www-data:www-data /var/www/monitor
sudo find /var/www/monitor -type d -exec chmod 755 {} \;
sudo find /var/www/monitor -type f -exec chmod 644 {} \;
sudo chmod 640 /var/www/monitor/config.php
sudo chmod 750 data tmp logs
3) Отворете си качването на файлове по SFTP. След горната команда всички файлове принадлежат на www-data, а FileZilla / WinSCP се свързват с вашия собствен потребител — качването тогава се проваля с SSH_FX_PERMISSION_DENIED (Permission denied). Влизането като root за качване не е вариант — root достъпът беше изключен в стъпка 05. Изберете един от двата варианта.
Вариант A — ACL само за вашия потребител (препоръчително). Право на запис получавате само вие; уеб сървърът все така не може да презапише кода на панела:
sudo apt install -y acl
# Право на запис за вашия потребител върху цялата директория на панела:
sudo setfacl -R -m u:deploy:rwX /var/www/monitor
# Същото правило по подразбиране — за файлове и папки, създадени по-късно:
sudo setfacl -R -d -m u:deploy:rwX /var/www/monitor
Вариант B — през групата www-data. По-прост, но право на запис върху файловете на панела получава и уеб сървърът: при уязвимост в PHP кодът би могъл да бъде подменен. Редът на командите е важен — config.php и работните папки се затварят последни:
sudo usermod -aG www-data deploy
# Запис за групата + setgid (бит 2): качените по SFTP файлове остават
# в групата www-data — иначе панелът няма да може да ги презапише.
sudo find /var/www/monitor -type d -exec chmod 2775 {} \;
sudo find /var/www/monitor -type f -exec chmod 664 {} \;
sudo chmod 640 /var/www/monitor/config.php
sudo chmod 2750 /var/www/monitor/data /var/www/monitor/tmp /var/www/monitor/logs
След вариант B свържете се наново във FileZilla (Сървър → Прекъсване на връзката, след което влезте отново) — новата група се прилага само при ново влизане, дотогава права пак няма да имате. Проверка: id deploy — в списъка с групи трябва да се появи www-data; ls -ld /var/www/monitor — права drwxrwsr-x, буквата s вместо x означава, че setgid е зададен.
11. База данни
Създайте база данни и потребител, след което импортирайте схемата. Блокът се поставя в терминала изцяло. monitor_db и monitor_user са примерни имена, може да зададете свои; запомнете името на базата, потребителя и паролата — ще ги впишете в config.php на следващата стъпка:
# 1. База данни. Паролата се задава ВЕДНЪЖ в DBPASS и се подставя във всички редове.
# Блокът се поставя в терминала ИЗЦЯЛО; sudo mysql влиза с root през unix-сокет
# (парола за root не е нужна). НЕ използвайте интерактивния `sudo mysql -u root -p`
# с копиране — при поставяне SQL-редовете отиват в подканата за парола и се губят.
DBPASS='CHOOSE_A_PASSWORD' # ← променете само този ред
sudo mysql <<SQL
CREATE DATABASE IF NOT EXISTS monitor_db CHARACTER SET utf8mb4;
CREATE USER IF NOT EXISTS 'monitor_user'@'localhost' IDENTIFIED BY '$DBPASS';
GRANT ALL ON monitor_db.* TO 'monitor_user'@'localhost';
FLUSH PRIVILEGES;
SQL
# Проверка (трябва да покаже monitor_db):
mysql -u monitor_user -p"$DBPASS" -e "SHOW DATABASES;"
# Същата парола впишете в config.php → DB_PASS.
Не е нужно да импортирате схемата — панелът сам създава таблиците и профила admin при първото отваряне в браузъра (от database/db.sql), ако базата е празна. Ръчен импорт на схемата е нужен само ако авто-инициализацията не е сработила.
Ако сте използвали браузърния инсталатор public/start_db.php — изтрийте го веднага след инсталацията: той позволява без оторизация да се пресъздаде базата. Докато файлът е в корена на панела или в public/, панелът показва червено предупреждение.
12. Настройка на config.php
config.php в корена на панела (/var/www/monitor/config.php) е единственият файл, който трябва да редактирате ръчно. Всички настройки на панела са зададени в него чрез константи define(). Отворете го в редактор:
sudo nano /var/www/monitor/config.php
Заменете със своите стойности на откроените места; останалото оставете както е:
// --- База данни (от стъпка 11) ---
define('DB_HOST', 'localhost'); // оставете
define('DB_NAME', 'db_name'); // това, което създадохте в стъпка 11
define('DB_USER', 'user'); // това, което създадохте в стъпка 11
define('DB_PASS', 'db_password'); // това, което зададохте в стъпка 11
define('DB_CHARSET', 'utf8mb4'); // оставете
// --- Приложение ---
define('APP_URL', 'https://monitor.example.com'); // адрес на панела, без наклонена черта накрая
define('TIMEZONE', 'Europe/Sofia'); // вашата часова зона
// --- Време на сесията ---
define('SESSION_LIFETIME', 28800); // бездействие до повторно влизане, сек (28800 = 8 ч)
Какво да промените:
DB_NAME, DB_USER, DB_PASS — точно същите име на базата, потребител и парола, които зададохте при създаването на БД в стъпка 11 (ако сте оставили примерите — monitor_db / monitor_user). DB_HOST и DB_CHARSET не пипайте.
APP_URL — пълният адрес на панела с https://, без наклонена черта накрая и без www. Трябва да съвпада с домейна, на който активирате лиценза (стъпка 16), иначе ключът ще бъде отхвърлен.
TIMEZONE — вашата часова зона (списък — timedatectl list-timezones). Влияе само върху това как панелът показва датите; върху времето на стартиране на cron-задачите не влияе (там важи зоната на системата).
SESSION_LIFETIME — след колко секунди бездействие панелът ще поиска повторно влизане (по подразбиране 8 часа). Напр. 3600 = 1 час, 86400 = денонощие.
Блокът за журнал на грешките (display_errors, log_errors, error_log) — оставете по подразбиране.
Запазете файла (Ctrl+O, Enter, след това Ctrl+X) и рестартирайте PHP-FPM — иначе заради OPcache промените няма да се приложат:
sudo systemctl restart php*-fpm
config.php е секретен файл (в него има паролата за БД). Той се намира в корена на панела, който е и уеб-коренът, но е защитен: права 640 (зададени в стъпка 10) и изрична забрана в кореновия .htaccess. Не го публикувайте в публични хранилища и не го изпращайте на поддръжката с реалната парола.
PHP се изпълнява от потребителя на уеб сървъра, който няма права за системни команди. Достъпът се дава прецизно: точков sudo за конкретни инструменти и четене на логове през групи (без sudo). Пробив на уеб слоя не дава root.
В примерите www-data е стандартният потребител на Apache. Ако вашият е друг (в някои панели PHP работи под отделен потребител) — заменете го навсякъде. Проверка: ps -o user= -C php-fpm | sort -u.
1. Създайте /etc/sudoers.d/monitor чрез sudo visudo -f /etc/sudoers.d/monitor и поставете (премахнете редовете на неизползваните модули):
# UFW — статус и правила (страница „Брандмауер“)
www-data ALL=(ALL) NOPASSWD: /usr/sbin/ufw status, /usr/sbin/ufw status verbose, /usr/sbin/ufw status numbered
www-data ALL=(ALL) NOPASSWD: /usr/sbin/ufw allow [0-9]*, /usr/sbin/ufw deny [0-9]*, /usr/sbin/ufw --force delete [0-9]*
# Fail2ban — статус, бан и разбан (banned връща баните на всички jail-ове с една команда;
# ban/unban са нужни за бутоните на панела)
www-data ALL=(ALL) NOPASSWD: /usr/bin/fail2ban-client status, /usr/bin/fail2ban-client status *, /usr/bin/fail2ban-client banned, /usr/bin/fail2ban-client set * banip *, /usr/bin/fail2ban-client set * unbanip *
# Обновления за сигурност (карта „Обновления“). Само четене, но именно от root:
# кешът на apt (~70 МБ) е достъпен само за root, не-root го пресъздава при всяко извикване
# (4.2 с CPU срещу 0.01 с). Без wildcard — точно тази една команда, нищо не инсталира.
www-data ALL=(ALL) NOPASSWD: /usr/bin/apt list --upgradable
# IPset (карта на атаките, дашборд)
www-data ALL=(ALL) NOPASSWD: /usr/sbin/ipset list -t ipsum
# CrowdSec
www-data ALL=(ALL) NOPASSWD: /usr/bin/cscli decisions list *, /usr/bin/cscli alerts list *, /usr/bin/cscli bouncers list *, /usr/bin/cscli scenarios list *
# Auditd — търсене на събития + четене на последните редове от журнала (точен път)
www-data ALL=(ALL) NOPASSWD: /usr/sbin/ausearch -m *
www-data ALL=(ALL) NOPASSWD: /usr/bin/tail -n 300 /var/log/audit/audit.log
# Monit / ModSecurity / AppArmor / PSAD
www-data ALL=(ALL) NOPASSWD: /usr/bin/monit status
www-data ALL=(ALL) NOPASSWD: /usr/sbin/apache2ctl -M
www-data ALL=(ALL) NOPASSWD: /usr/local/bin/monitor-modsec
www-data ALL=(ALL) NOPASSWD: /usr/sbin/aa-status
www-data ALL=(ALL) NOPASSWD: /usr/sbin/psad --Status
# Отворени портове (журналите на ядрото/SSH/Falco се четат БЕЗ sudo — през групата
# systemd-journal, вж. т.2; sudo за journalctl НЕ трябва да се дава и е опасно)
www-data ALL=(ALL) NOPASSWD: /usr/bin/ss -tuln, /usr/sbin/ss -tuln, /bin/ss -tuln
# PostgreSQL (само ако го използвате) — фиксиран read-only скрипт,
# създайте го по FAQ „PostgreSQL не се показва“; без него изтрийте реда
www-data ALL=(ALL) NOPASSWD: /usr/local/bin/monitor-pgstat
sudo chmod 440 /etc/sudoers.d/monitor
sudo visudo -c # трябва да е "parsed OK"
2. Достъп до логовете и журнала на systemd. Модулите четат /var/log/fail2ban.log, auth.log, ufw.log, apache2/*, aide директно (на Debian/Ubuntu тези логове са в групата adm). Събитията на ядрото, SSH и Falco се вземат от journald с командата journalctlбез sudo, през групата systemd-journal. Добавете уеб потребителя в двете групи и рестартирайте PHP-FPM:
sudo usermod -aG adm,systemd-journal www-data
sudo systemctl restart php*-fpm # задължително, иначе групите няма да се приложат
3. Ако ClamAV или Suricata записват логовете не в групата adm (среща се root:root) — дайте достъп през ACL:
4. Обвивка за ModSecurity. Одит логът на WAF (/var/log/apache2/modsec_audit.log) принадлежи на root с права 640 и уеб потребителят не може да го чете директно. Страницата ModSecurity взима режима на двигателя, събитията и списъка с активни правила през фиксиран read-only скрипт — точно той е разрешен в sudoers с реда по-горе:
Без файла /etc/modsecurity/modsecurity.conf самият WAF не работи: пакетът поставя само modsecurity.conf-recommended и двигателят на правилата остава изключен — как да го включите вижте FAQ → „Инсталиране на ModSecurity“.
Потребителят във всички редове на sudoers трябва да съвпада с потребителя на FPM пула: на обикновен Apache/Debian това е www-data, в HestiaCP пулът на сайта работи от собственика на сайта (например admin) — проверете grep -E '^user' /etc/php/*/fpm/pool.d/monitor.example.com.conf.
5. Ако пред Apache стои Nginx (HestiaCP, ISPmanager и други панели — там Nginx проксира PHP към Apache, а статиката отдава сам). Служебните директории са затворени с файлове .htaccess, но Nginx не ги чете: всеки статичен файл (.json, .txt, .log, .dat) той ще отдаде директно, заобикаляйки Apache. Навън ще изтекат кешовете на панела и данни — например tmp/modsec_cache.json със събитията на WAF и IP адресите на атакуващите. Добавете забраната в конфигурацията на сайта в Nginx:
Префиксът ^~ е задължителен: той се избира преди регулярното правило за статиката вътре в location /, иначе забраната няма да сработи.
В HestiaCP поставете това като отделен файл /home/<user>/conf/web/<domain>/nginx.ssl.conf_deny (и nginx.conf_deny за HTTP) — конфигурацията на сайта включва nginx.ssl.conf_* и при пресъздаване не презаписва такива файлове. Прилагане: sudo nginx -t && sudo systemctl reload nginx.
Проверка: curl -s -o /dev/null -w '%{http_code}\n' https://monitor.example.com/tmp/modsec_cache.json — трябва да е 403. Ако Apache работи без Nginx (слуша сам на 80/443), не е нужно да добавяте нищо — .htaccess е достатъчен.
Пътищата до бинарните файлове проверете чрез which (например which ufw cscli ausearch ss). Редактирайте sudoers само чрез visudo. Списъкът с всички MySQL бази се включва с отделен GRANT (FAQ → „Вижда се само една БД“).
14. Ограничаване на достъпа по IP
Ограничете достъпа до монитора по IP адрес — дори URL адресът да стане известен, страницата за вход няма да се отвори. Може на ниво уеб сървър (пример за nginx по-долу) или в самата панел („Настройки“ → „Ограничаване на достъпа по IP“). Ако използвате Apache, ползвайте ограничението в панела.
Ако сайтът на nginx вече е настроен по стъпка 10, не добавяйте вториlocation / — впишете редовете allow/deny в вече съществуващия блок. Два еднакви location / в един server { } е грешка в конфигурацията и nginx няма да се рестартира.
# В конфига на nginx (вътре в server { }):
# ACME-пътя на Let's Encrypt държим отворен в обход на IP-ограничението —
# за да не зависят издаването и автоподновяването на SSL (стъпка 15) от IP-филтъра.
location ^~ /.well-known/acme-challenge/ { allow all; }
location / {
allow 203.0.113.10; # ← впишете своя IP
allow 10.0.0.0/8; # локална мрежа (ако е необходимо)
deny all;
try_files $uri $uri/ /index.php?$query_string;
}
# Презареждане на nginx:
sudo nginx -t && sudo systemctl reload nginx
15. Издаване на SSL (HTTPS)
Панелът работи само по HTTPS. Сесията за вход използва защитена cookie, а WebAuthn (2FA) работи само по HTTPS. По http:// не може да се влезе.
Сертификатът е безплатен (Let's Encrypt). DNS на домейна вече трябва да сочи към сървъра. Командата зависи от уеб сървъра:
# Apache:
sudo certbot --apache -d monitor.example.com
# nginx — САМО ако използвате точно nginx. На Apache НЕ стартирайте:
# apt ще издърпа nginx и ще заеме порт 80, конфликт с Apache.
# sudo apt install python3-certbot-nginx
# sudo certbot --nginx -d monitor.example.com
# certbot сам ще впише HTTPS в конфигурацията и ще настрои автоподновяване
Какво ще попита certbot: e-mail → съгласие с Terms (Y) → предаване на e-mail към EFF (по ваша преценка). После сам ще издаде сертификата, ще впише <VirtualHost *:443>, ще настрои пренасочване http→https и автоподновяване.
DNS трябва да сочи към сървъра ПРЕДИ стартиране на certbot (проверка на собствеността по порт 80). Проверка: dig +short monitor.example.com → IP на сървъра. Портове 80/443 отворени: sudo ufw allow 80,443/tcp.
След издаването: https://monitor.example.com се отваря с катинар, http:// пренасочва към https:// (APP_URL в config.php вече е зададен в стъпка 12).
16. Вход и първоначална настройка
Отворете https://monitor.example.com, влезте с admin / useradmin и минете през списъка:
Смяна на паролата на admin — раздел „Потребители“ в менюто.
Включване на WebAuthn (2FA) — „Ключове WebAuthn“ → регистрирайте ключ/passkey (изисква HTTPS). Регистрирайте веднага два: при загуба на единствения ключ входът с него ще е невъзможен. Повече.
Ограничаване на достъпа по IP — „Настройки“ → „Ограничаване на достъпа по IP“ (въведете своя IP преди включване, иначе ще си затворите достъпа).
Въвеждане на лиценз — активирайте кода ARCIVEO-… от профила за своя домейн и въведете ключа в „Настройки“ → „Лиценз“. Повече.
Настройка на известията — Telegram и/или Email в „Настройки“. Повече.
Изтриване на инсталатораpublic/start_db.php, ако е останал (стъпка 11).
17. Инструменти за сигурност (по избор)
Панелът вече работи. Инструментите се инсталират по желание — инсталирате каквото ви трябва и панелът веднага показва статуса. Командите за инсталация на всеки са в справочника (отделни раздели по инструменти):
Това е демонстрация на Arcivéo Security Monitor само за преглед — всякакви промени са изключени. Разгърнете го на своя сървър, за да управлявате реални данни за сигурността.