FAQ — Arcivéo · demo.arciveo.com

01. Inštalácia panela — vyberte spôsob

Inštalácia panela je na samostatných krokových stránkach. Vyberte spôsob:

Jeden skript z účtu pripraví celý server (webový stack, DB, nástroje, cron). Ďalej už len rozbaliť panel, vydať SSL a zadať licenciu.

Otvoriť

Ručná

Príprava VPS, webový server a vhost, databáza, SSL a každý nástroj — krok za krokom, vlastnými rukami. Úplná kontrola.

Otvoriť

Ak si nie ste istí, zvoľte automatickú. Táto príručka zostáva jednotným zdrojom pre SSL, nástroje, cron a diagnostiku — inštalačné stránky odkazujú na jej sekcie a nič neduplikujú.

02. Čo je Arcivéo Monitor

Arcivéo Monitor — panel zabezpečenia servera. Zbiera údaje z nainštalovaných nástrojov (Fail2ban, UFW, Lynis, ModSecurity, AIDE, ClamAV, Auditd, CrowdSec, Suricata, Falco a i.) a zobrazuje ich v jednotnom rozhraní s dashboardom, mapou útokov a podrobnými stránkami pre každý nástroj.

Monitor nie je aktívny ochranný prostriedok — útoky sám neblokuje. Jeho úlohou je agregovať informácie z už fungujúcich nástrojov a prehľadne ich prezentovať.

03. Ako monitor funguje na serveri

Monitor funguje len lokálne — musí byť nainštalovaný na tom istom serveri, ktorý monitoruje. Žiadny SSH ani vzdialené API neexistuje.

Všetky príkazy (fail2ban-client, ufw status, ipset list atď.) panel vykonáva pod používateľom webového servera (zvyčajne www-data, na hostingových paneloch — účet webu) s úzkou sadou práv sudo — len na konkrétne nástroje, bez všeobecného root prístupu. Výsledky sa spracujú a zobrazia v prehliadači.

Pre viacero serverov nainštalujte monitor na každom osobitne, s vlastnou doménou.

04. Ako sa počíta skóre bezpečnosti

Skóre začína na maxime a znižuje sa za každý zistený problém:

UFW nie je aktívny — −30
Fail2ban nebeží (žiadne aktívne jail) — −25
Žiadne kľúče WebAuthn — −15
Lynis hardening index < 60 — −20; 60–79 — −10
IPset ipsum nie je načítaný — −10
Hrozby zistené nástrojom ClamAV — −20
Zmeny súborov podľa AIDE — −15
SSL vypršal — −30, vyprší o <14 dní — −15, <30 dní — −5
CrowdSec je nainštalovaný, ale nebeží — −5
Suricata je nainštalovaná, ale nebeží — −5
Databáza/cache (MySQL, PostgreSQL, Redis…) dostupné zvonku — −10
Povolené prihlásenie root cez SSH (PermitRootLogin yes) — −20
Čakajú bezpečnostné aktualizácie na inštaláciu — −5

Výsledok: 80+ = Chránený, 60–79 = Pozor, <60 = Ohrozený.

Zrážky za ClamAV, AIDE, CrowdSec a Suricata sa uplatňujú len vtedy, ak je nástroj nainštalovaný. Lynis a AIDE bez inicializovanej databázy sa zobrazujú ako „žiadne údaje“ a skóre neznižujú. Počet dnešných útokov sa zobrazuje na dashboarde, ale skóre bezpečnosti neovplyvňuje.

05. WebAuthn — dvojfaktorová autentifikácia

WebAuthn — štandard autentifikácie bez hesla pomocou hardvérového kľúča. Podporuje YubiKey, Touch ID, Face ID, Windows Hello, Passkey.

Po prihlásení heslom systém vyžiada potvrdenie zaregistrovaným kľúčom. Aj keď heslo unikne — bez fyzického kľúča alebo biometrie sa prihlásiť nedá.

Nastavenie otvoríte cez Kľúče WebAuthn v bočnom menu a kliknite na „Zaregistrovať kľúč“. Zaregistrujte si hneď dva kľúče: ak sa jediný kľúč stratí alebo pokazí, prihlásenie do panela pomocou neho už nebude možné.

WebAuthn funguje iba cez HTTPS. Na HTTP spojení nie je registrácia ani prihlásenie kľúčom dostupné.

06. Upozornenia: Telegram a Email

Panel dokáže posielať bezpečnostný report do Telegramu a na e-mail (tlačidlom aj podľa plánu). Nastavuje sa v sekcii „Nastavenia“.

Telegram. Potrebujete token bota a chat id:

V Telegrame napíšte @BotFather → /newbot → dostanete token v tvare 123456:ABC....
Napíšte svojmu novému botovi ľubovoľnú správu (aby vám mohol odpovedať).
Zistite svoj chat id: napíšte botovi @userinfobot, alebo otvorte https://api.telegram.org/bot<TOKEN>/getUpdates a nájdite "chat":{"id":...}.
Vložte token a chat id do „Nastavenia“ → Telegram a stlačte „Uložiť a poslať test“.

Email. Dva spôsoby na výber v „Nastavenia“ → Email:

SMTP — hostiteľ, port (465/SSL alebo 587/TLS), prihlasovacie meno a heslo vašej e-mailovej schránky;
Resend — moderné API: zadajte API kľúč (re_...) a overenú doménu odosielateľa.

Tlačidlo „Poslať test“ hneď overí kanál. Plán automatického reportu — cez cron (sekcia „Všetky cron úlohy“): ten spustí odoslanie a kanály sa berú z nastavení.

Stav reportu: „POZOR“ alebo „OK“. Nadpis sa zmení na „POZOR“ iba pri reálnom probléme alebo čakajúcej akcii: nájdená hrozba ClamAV, zmeny súborov v AIDE, kritické udalosti Falco (Emergency/Alert/Critical za posledných 24 h), spadnutá služba v Monit, potrebný reštart, končiace SSL (≤14 dní) alebo čakajúce bezpečnostné aktualizácie. Šum na pozadí — pokusy botov o SSH prihlásenie, IP adresy zabanované cez fail2ban, alerty Suricata, upozornenia Lynis a už odrazené požiadavky ModSecurity — stav nezvyšuje, preto takéto čísla v reporte samy osebe neznamenajú „POZOR“.

07. Licencia — zadanie a aktivácia

Podrobné moduly monitorovania (Lynis, UFW, ModSecurity, mapa útokov, AIDE, ClamAV a i.) sa sprístupnia s platnou licenciou. Bez nej dashboard, nastavenia a účet fungujú, no moduly zobrazujú kartu „Vyžaduje sa licencia“.

Po nákupe v účte máte aktivačný kód v tvare ARCIVEO-XXXX-XXXX-XXXX-XXXX. Ten treba „aktivovať“ na doménu vášho panela — kód sa tým premení na podpísaný licenčný súbor (blok [license]), ktorý vložíte do panela.

Ako aktivovať (3 kroky):

Vezmite aktivačný kód. Účet my.arciveo.com → sekcia „Licencie“ / „Aktivácia licencie“ — skopírujte kód ARCIVEO-….
Aktivujte kód na svoju doménu. Tam istom v účte otvorte „Aktivácia licencie“, zadajte: aktivačný kód, váš email a doménu panela (adresu, na ktorej sa otvára monitor, napr. monitor.example.com). Kliknite na aktiváciu — systém vygeneruje licenčný súbor viazaný na túto doménu a zobrazí ho v poli s tlačidlom „Kopírovať“.
Vložte kľúč do panela. Skopírujte celý text licencie → v paneli otvorte „Nastavenia“ → blok „Licencia“, vložte a kliknite na „Uložiť“. Moduly sa hneď odomknú.

Panel kryptograficky overuje kľúč: podpis, viazanie na doménu a platnosť.

Doména pri aktivácii sa musí presne zhodovať s adresou panela. Vezmite ju z konštanty APP_URL v config.php a zadajte len názov hostiteľa — bez https:// a bez predpony www. Aktivácia je jednorazová: kód sa premení na licenciu pre zadanú doménu a znova sa už neaktivuje — pri chybe v doméne kľúč vášmu panelu nesadne a kód sa spotrebuje. Preto zadávajte doménu pozorne.

Ak platnosť vypršala alebo sa zmenila doména, v hlavičke panela sa objaví upozornenie. Licencia je viazaná na doménu natrvalo a na inú doménu sa neprenáša: na nové obdobie alebo novú doménu potrebujete nový kľúč (kupuje sa v účte a aktivuje sa jednorazovo).

08. Súbor config.php — všetky nastavenia panela

Všetky základné parametre panela sú zadané v jednom súbore config.php v koreni (vedľa priečinka public/) bežnými konštantami define(). Súbor sa vytvorí pri inštalácii; ručne ho treba upravovať zriedka — najmä pri zmene domény, prenose alebo pripojení k inej databáze. Po akejkoľvek úprave reštartujte PHP-FPM (inak sa kvôli OPcache zmeny neprejavia).

Do zvýraznených miest doplňte svoje hodnoty; ostatné nechajte tak, ako je:

// --- Databáza --- define('DB_HOST', 'localhost'); // nechať define('DB_NAME', 'db_name'); // čo ste zadali pri vytváraní DB define('DB_USER', 'user'); // čo ste zadali pri vytváraní DB define('DB_PASS', 'db_password'); // čo ste zadali pri vytváraní DB define('DB_CHARSET', 'utf8mb4'); // nechať // --- Aplikácia --- define('APP_URL', 'https://monitor.example.com'); // adresa panela, bez lomky na konci define('TIMEZONE', 'Europe/Bratislava'); // vaše časové pásmo // --- Trvanie relácie --- define('SESSION_LIFETIME', 28800); // nečinnosť do opätovného prihlásenia, s (28800 = 8 h)

Databáza. Prihlasovacie údaje pripojenia k MySQL/MariaDB:

DB_HOST — hostiteľ databázy, takmer vždy localhost;
DB_NAME — názov databázy panela;
DB_USER — používateľ DB (prístup len k vlastnej databáze);
DB_PASS — heslo tohto používateľa;
DB_CHARSET — kódovanie spojenia, nechajte utf8mb4.

Aplikácia.

APP_URL — úplná adresa panela (napr. https://monitor.example.com). Musí sa zhodovať s doménou, na ktorú je licencia aktivovaná — inak bude kľúč odmietnutý (pozri časť „Licencia“);
TIMEZONE — časové pásmo PHP: ovplyvňuje len to, ako panel zobrazuje dátumy a čas. Na čas spúšťania cron úloh nemá vplyv — tam platí pásmo systému (pozri „Všetky cron úlohy“).

Trvanie relácie. SESSION_LIFETIME — časový limit nečinnosti relácie v sekundách (posuvný: obnovuje sa pri aktivite). Predvolene 28800 = 8 hodín; po tomto čase nečinnosti panel vyžiada opätovné prihlásenie. Napríklad 3600 = 1 hodina, 86400 = deň.

Zaznamenávanie chýb. Chyby sa návštevníkom nikdy nezobrazujú, ale zapisujú sa do logs/php_errors.log — vidno ich na stránke „Logy aplikácie“. Tieto riadky (display_errors=0, log_errors=1, cesta error_log) zvyčajne netreba meniť — nastavenia sú zadané priamo v súbore a nezávisia od php.ini.

config.php — tajný súbor. Obsahuje heslo k DB. Nachádza sa v koreni panela (vedľa public/), pričom webový koreň (DocumentRoot) tohto panela je práve koreň panela, nie public/. Samotný súbor „neuniká“: v koreňovom .htaccess je preň nastavený výslovný zákaz (Require all denied) — server vráti 403. Aj bez tohto pravidla by zdrojový kód neunikol: je to PHP — server ho vykonáva, nevydáva ho ako text. Pre istotu: nezverejňujte ho vo verejných repozitároch a neposielajte do podpory s reálnym heslom. Práva na súbor — 640.

Pri prenose alebo obnove prístupu je tento súbor hlavným zdrojom prihlasovacích údajov: názov DB, používateľ a heslo sa berú práve odtiaľto (pozri časti „Aktualizácia a prenos panela“ a „Obnova prístupu“).

09. Firewall UFW

UFW (Uncomplicated Firewall) — jednoduché rozhranie k nftables/iptables. Uzatvára všetky prichádzajúce porty okrem výslovne povolených. Stránka „Firewall UFW“ zobrazuje stav a pravidlá.

sudo apt install ufw # Povoliť SSH (nutné PRED zapnutím!) a web sudo ufw allow OpenSSH sudo ufw allow 80,443/tcp # Uzavrieť databázu zvonka (prístup len lokálne) sudo ufw deny 3306 # Zapnúť a overiť sudo ufw enable sudo ufw status verbose

Pred ufw enable vždy povoľte SSH (ufw allow OpenSSH), inak stratíte prístup k serveru.

„Externá expozícia“ na dashboarde zohľadňuje UFW: port uzavretý pravidlom deny sa nepovažuje za dostupný zvonka.

Skipping adding existing rule — to nie je chyba. UFW takto oznamuje, že presne takéto pravidlo už existuje, a znovu ho nepridáva. Pri opakovanom spustení automatickej konfigurácie (je idempotentná) je to bežná správa — netreba na ňu reagovať.

10. Inštalácia Fail2ban

Automaticky zablokuje IP adresu po prekročení počtu neúspešných pokusov o prihlásenie. Analyzuje logy SSH, nginx, Apache a ďalších služieb.

sudo apt install fail2ban sudo systemctl enable --now fail2ban # Skontrolovať stav: sudo fail2ban-client status

Funkčná konfigurácia (jail.local s desiatkami jailov a automatickým banom z ipsum) — v nasledujúcej sekcii.

11. Funkčná konfigurácia Fail2ban + ipsum

Základná inštalácia je vyššie. Tu je funkčná konfigurácia, ktorá poskytuje desiatky aktívnych jailov a tisíce blokovaní: všeobecné nastavenia, kľúčové jaily a autoban škodlivých IP zo zoznamu ipsum.

Súbor /etc/fail2ban/jail.local — všeobecné nastavenia a najdôležitejšie jaily:

[DEFAULT] bantime = 1w findtime = 900 maxretry = 3 backend = systemd banaction = nftables-multiport ignoreip = 127.0.0.1/8 ::1 <YOUR_IP> <TRUSTED_NETS> # Progresívny ban: každé opakovanie — dlhšie bantime.increment = true bantime.factor = 2 bantime.maxtime = 5w bantime.rndtime = 300 [sshd] enabled = true maxretry = 5 bantime = -1 # trvalý ban za brute-force SSH findtime = 3600 # Recidivisti: kto dostal niekoľko banov — banuje sa navždy [recidive] enabled = true logpath = /var/log/fail2ban.log banaction = %(banaction_allports)s bantime = -1 findtime = 86400 maxretry = 2 [http-get-dos] enabled = true maxretry = 100 findtime = 300 bantime = 1w # Webové služby (apache-*, nginx-*, php-url-fopen, phpmyadmin-syslog): [nginx-http-auth] enabled = true port = http,https [apache-badbots] enabled = true port = http,https # … a ostatné jaily podľa služieb (dovecot, exim, postfix-sasl, # mysqld-auth, vsftpd, portscan, pam-generic) — enabled = true

Do ignoreip nezabudnite zapísať svoju IP adresu a dôveryhodné siete, inak môžete zabanovať sami seba. Po úpravách: sudo fail2ban-client reload.

Automatické načítanie blok-listu ipsum — do root-cronu (sudo crontab -e): level 1 (100+ tisíc IP) sa načíta do setu ipsum, ktorý sa odrezáva na firewalle (podrobnejšie v sekcii „Blok-list IPset“):

# 04:00 — aktualizácia ipset ipsum (level 1, maximálny záber): 0 4 * * * /usr/local/bin/load-ipsum.sh >> /path/to/monitor/logs/cron.log 2>&1

Set sa musí volať ipsum — práve ten číta dashboard (karta „IPset ipsum“). Úrovne: levels/1.txt — maximálny záber, levels/3.txt — presnejšie (3+ zdroje).

Prečo je „Monitor bezpečnosti“ rozdelený na dve zóny. Ochrana funguje na dvoch úrovniach a dashboard ich nezmiešava:

Reálne útoky (reaktív) — všetko, čo zachytil fail2ban: živé pokusy o prienik (jaily sshd, apache-*, nginx-* a pod.) a zlomyseľní recidivisti (jail recidive — tí, ktorých už niekoľkokrát banovali). Sú to IP, ktoré sa k vám skutočne dobýjali — nájdete ich na mape útokov a v „Časovej osi“.
Preventívne blokovanie (proaktív) — verejný blok-list známych škodlivých IP ipset ipsum, odrezávaný na firewalle pravidlom DROP. Tieto adresy sa väčšinou vášho servera ani nedotkli — režú sa vopred; počítadlo „IPset ipsum“ ukazuje, koľko ich bolo odrezaných preventívne.

Rozdiel je jednoduchý: reaktív — „tieto zaútočili a dostali ban“, preventív — „tieto sa zablokovali ešte pred pokusom“. Predtým sa do recidive umelo vháňal list-3 ipsum (odtiaľ staré rozdelenie „zoznamoví recidive“); teraz sú v recidive iba skutoční recidivisti a preventív je celý na firewalle.

12. Blok-list IPset (ipsum)

ipsum — verejný zoznam škodlivých IP, aktualizovaný denne. Monitor zobrazuje počet načítaných adries na dashboarde a mape útokov a zohľadňuje ho v Skóre bezpečnosti (−10, ak sada nie je načítaná).

Minimálny variant bez fail2ban — samostatná sada ipsum s blokovaním cez iptables:

# Vytvoriť sadu (jednorazovo): sudo ipset create ipsum hash:ip # Aktualizačný skript /usr/local/bin/update-ipsum.sh: #!/bin/bash ipset flush ipsum for ip in $(curl -s https://raw.githubusercontent.com/stamparm/ipsum/master/levels/3.txt); do ipset add ipsum "$ip" 2>/dev/null done iptables -C INPUT -m set --match-set ipsum src -j DROP 2>/dev/null \ || iptables -I INPUT -m set --match-set ipsum src -j DROP # Cron (sudo crontab -e, denne o 4:00): 0 4 * * * /usr/local/bin/update-ipsum.sh

Rozšírený variant s fail2ban-recidive — v sekcii „Funkčná konfigurácia Fail2ban + ipsum“.

ipset žije v pamäti a pri reštarte sa stráca. Samotný denný cron nechá sadu prázdnu od reštartu až po ďalšie spustenie (dashboard ukáže 0). Načítavajte sadu aj pri štarte — vyčleňte načítanie do skriptu a naviažte ho na @reboot. Zároveň príkaz create … -exist nastaví limit maxelem 300000 (predvolene 65536 — level 1 sa nezmestí, nastane „Hash is full“):

# /usr/local/bin/load-ipsum.sh #!/bin/bash curl -s https://raw.githubusercontent.com/stamparm/ipsum/master/levels/1.txt \ | grep -v '^#' | sed 's/^/add ipsum /' \ | (echo "create ipsum hash:ip hashsize 131072 maxelem 300000 -exist"; echo "flush ipsum"; cat) \ | ipset restore -exist # sudo crontab -e — denne o 04:00 A pri každom štarte: 0 4 * * * /usr/local/bin/load-ipsum.sh @reboot sleep 60 && /usr/local/bin/load-ipsum.sh

Ako to funguje pri automatickej inštalácii. Skript načíta úplný zoznam level 1 (100+ tisíc IP) do sady ipsum a ak firewall spravuje inštalátor (čerstvý VPS — profily „Plná“/„Odľahčená“), pripojí sadu k UFW pravidlom DROP — prevádzka z týchto IP sa reálne blokuje. Pravidlo je za ESTABLISHED,RELATED, takže aktuálne spojenia (vrátane vášho SSH) sa nepretrhnú — režú sa len nové pripojenia zo zoznamu. Sada sa obnovuje pri načítaní služby ipsum-load.service pred firewallom (inak by sa UFW nespustil) a aktualizuje sa cronom o 04:00. Na už nakonfigurovanom serveri (panel, vlastný firewall) inštalátor do firewallu nezasahuje — tam ipsum zostáva zoznamom pre dashboard a mapu útokov a pravidlo DROP sa v prípade záujmu pridá ručne (minimálny variant s iptables … --match-set ipsum … -j DROP — vyššie). Pri automatickej inštalácii netreba robiť nič ručne.

13. Inštalácia CrowdSec

Moderná náhrada za Fail2ban s kolektívnym threat intelligence: bany od komunity plus vlastné pravidlá. Na aplikovanie banov na firewall vyžaduje samostatný bouncer.

curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash sudo apt install crowdsec sudo systemctl enable --now crowdsec # Bouncer pre iptables/nftables: sudo apt install crowdsec-firewall-bouncer-iptables # Overiť stav: sudo systemctl status crowdsec sudo cscli decisions list sudo cscli bouncers list

Stav „Nespustené“ v paneli = služba je nainštalovaná, ale nie je aktívna (monitor ju kontroluje cez systemctl is-active crowdsec). Spustiť: sudo systemctl enable --now crowdsec; pri páde pozri sudo journalctl -u crowdsec -n 30. To isté pravidlo platí pre akúkoľvek službu v stave „Nespustené“ (Suricata, Falco, Monit, MySQL).

„0 scenárov“ alebo „0 bouncerov“ na dashboarde. CrowdSec je hneď po inštalácii takmer prázdny — bez kolekcií nič nedetekuje a bez zaregistrovaného bouncera sa bany na firewall neaplikujú. Doinštalujte základné kolekcie a uistite sa, že bouncer je v zozname:

# Základné kolekcie (Linux + SSH + webový server): sudo cscli collections install crowdsecurity/linux crowdsecurity/sshd crowdsecurity/base-http-scenarios sudo systemctl reload crowdsec # Bouncer musí byť v zozname a v stave aktívneho pripojenia: sudo cscli bouncers list

V logu bouncera stream halted / bany sa neaplikujú. Ide o osirotený api-kľúč: bouncer bol odstránený z cscli bouncers list, ale jeho starý kľúč ostal v /etc/crowdsec/bouncers/*.yaml. Preregistrujte bouncer a zapíšte čerstvý kľúč:

sudo cscli bouncers add fw-bouncer # vypíše nový api_key # zapíšte tento kľúč do api_key: v /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml sudo systemctl restart crowdsec-firewall-bouncer

Automatická inštalácia (profil „Plná ochrana“) sama nainštaluje kolekcie a zaregistruje firewall-bouncer — ručne je to potrebné len pri ručnej inštalácii alebo po ručnom zásahu do CrowdSec.

14. Inštalácia AIDE

AIDE (Advanced Intrusion Detection Environment) vytvorí snímku súborového systému a pri každej kontrole nahlási zmeny v /etc, /bin, /usr. Po inštalácii je nutné inicializovať databázu (aideinit).

sudo apt install aide # Inicializácia databázy (5–15 minút): sudo aideinit sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db # Ubuntu 24.04: adresár /var/lib/aide sa vytvorí v režime 700 (vlastník _aide), # a panel (www-data) databázu nevidí → zobrazuje „Neinicializovaná“. # Sprístupnite adresár na prechod (súbory databázy zostávajú 600): sudo chmod 755 /var/lib/aide # Prvá kontrola SO ZÁPISOM do logu, ktorý číta monitor. # Na Ubuntu/Debian aide vyžaduje explicitný --config (inak „missing configuration“; # binárka aide.wrapper sa v nových verziách nedodáva): sudo bash -c 'aide --config /etc/aide/aide.conf --check > /var/log/aide/aide.log 2>&1'

Počas aideinit terminál 5–15 minút stojí na riadku Running aide --init... — je to normálne (hashovanie celého súborového systému, záťaž disku). Neprerušujte Ctrl+C. Ak proces „visí“, ale nič nezapisuje — možno čaká na odpoveď na skrytú výzvu Overwrite existing aide.db.new [Yn]? (stlačte Y). Aktivitu overíte z inej relácie: pgrep -af aide.

Chyba aideinit: „21_aide_spamassassin … printf: invalid number“ (return code 20) — známa chyba konfiguračného snippetu AIDE v Ubuntu 22.04. Databáza sa nevytvorí. Odstráňte chybný snippet a zopakujte:

sudo mv /etc/aide/aide.conf.d/21_aide_spamassassin /etc/aide/21_aide_spamassassin.disabled sudo aideinit sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Stavy na dashboarde. „Neinicializovaná“ = panel nevidí súbor databázy: buď sa aideinit nespustil, alebo (Ubuntu 24.04) sa adresár /var/lib/aide vytvoril v režime 700 a je nedostupný pre www-data — vyrieši sa cez sudo chmod 755 /var/lib/aide (pozri blok vyššie). „Bez kontrol“ = databáza existuje, ale kontrola sa ešte nevykonala — nie je to chyba. Výsledky monitor číta z /var/log/aide/aide.log.

Pravidelná kontrola → log pre panel. Štandardný /etc/cron.daily/aide na nových Ubuntu/Debian nemusí zapisovať /var/log/aide/aide.log v potrebnej podobe (a aide.wrapper v nich už nie je). Spoľahlivejšie je pridať vlastný cron s explicitným --config — zapisuje log ako root v režime 644 a monitor ho číta bez ďalších skupín:

# sudo crontab -e — denná kontrola o 02:00: 0 2 * * * /usr/bin/aide --config /etc/aide/aide.conf --check > /var/log/aide/aide.log 2>&1 # Spustiť teraz, bez čakania na plán: sudo bash -c 'aide --config /etc/aide/aide.conf --check > /var/log/aide/aide.log 2>&1'

Automatická inštalácia už toto všetko robí: chmod 755 /var/lib/aide a cron kontroly o 02:00 — ručne nie je potrebné nič.

Prvú inicializáciu vykonajte na čistom serveri — pred inštaláciou webových aplikácií. Po legitímnych zmenách databázu znova vytvorte: sudo aideinit && sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db.

15. Inštalácia ClamAV

Antivírusový skener pre Linux. Obzvlášť užitočný na kontrolu /var/www na prítomnosť PHP shellov a škodlivého kódu.

sudo apt install clamav clamav-daemon sudo systemctl enable --now clamav-daemon # Aktualizovať databázu signatúr: sudo freshclam # Manuálne prehľadať priečinok: sudo clamscan -r /var/www --infected

Démon clamd po enable --now hlási „Neaktívny“? Tri typické príčiny:

1. V konfigurácii zostal riadok Example — clamd sa odmieta spustiť, kým tam je:

sudo sed -i '/^Example/d' /etc/clamav/clamd.conf sudo systemctl restart clamav-daemon

2. Nie je stiahnutá databáza signatúr — clamd sa bez nej nespustí:

sudo systemctl stop clamav-freshclam sudo freshclam sudo systemctl start clamav-freshclam sudo systemctl restart clamav-daemon

3. Len sa načítava — clamd nahráva do pamäte ~8 mil. signatúr 30–60 s. Počkajte a skontrolujte: systemctl is-active clamav-daemon (stav activating → ešte sa načítava).

Diagnostika: sudo journalctl -u clamav-daemon -n 30 --no-pager.

Na dashboarde „Skontrolovaných súborov: 0“ / „Posledné skenovanie: —“? Démon clamd len drží signatúry v pamäti, sám podľa plánu nič neskenuje. Panel zobrazuje výsledky plánovaného skenu, preto je potrebný cron, ktorý skenuje a zapisuje log. Automatická inštalácia nainštaluje obálku /usr/local/bin/clamav-scan.sh a cron o 01:30 — po prvom spustení sa naplní „Skontrolovaných súborov“ a „Posledné skenovanie“. Spustiť hneď bez čakania na plán: sudo /usr/local/bin/clamav-scan.sh.

16. Inštalácia Linux Malware Detect (maldet)

Linux Malware Detect (LMD) — skener škodlivého softvéru pre webové hrozby: PHP shelly, webové backdoory, sťahovače. Používa engine ClamAV a dopĺňa ho vlastnými signatúrami.

wget https://www.rfxn.com/downloads/maldetect-current.tar.gz tar -xzf maldetect-current.tar.gz dir=$(ls -d maldetect-*/ | head -1) && cd "$dir" && sudo bash install.sh && cd ~ rm -rf maldetect-* maldetect-current.tar.gz # Aktualizovať signatúry: sudo maldet -u # Skenovať /var/www: sudo maldet -a /var/www

LMD a ClamAV spolu fungujú výborne. Posledný report: maldet --report.

Pri inštalácii sa môže objaviť riadok update-rc.d: error: unable to read /etc/init.d/maldet — je neškodný. maldet nepoužíva init.d, aktualizácia signatúr a skeny sa spúšťajú cez /etc/cron.daily/maldet. Ak nižšie vidíte installation completed — všetko sa nainštalovalo.

Na stránke sa pri LMD píše „Nenainštalované“, hoci je nainštalovaný? maldet sa neinštaluje cez apt, ale do /usr/local/maldetect, a pri zapnutom open_basedir sa jeho prítomnosť overuje cez shell — pozri časť „Stránka je prázdna, hoci na serveri sú dáta“.

17. Inštalácia Suricata

Sieťový systém detekcie prienikov: analyzuje prevádzku na úrovni paketov a pozná tisíce signatúr útokov. Dopĺňa ModSecurity (ten pracuje na úrovni HTTP, Suricata na úrovni TCP/IP).

sudo add-apt-repository ppa:oisf/suricata-stable sudo apt update && sudo apt install suricata # Stiahnuť aktuálne pravidlá: sudo suricata-update sudo systemctl enable --now suricata

Suricata je „Aktívna“, no dashboard nezobrazuje upozornenia / počet udalostí je 0? Suricata zapisuje /var/log/suricata/eve.json pod root v režime 750 na adresár a webový server (www-data) ho nedokáže prečítať. Sprístupnite adresár na prechod — súbory vnútri zostávajú chránené:

sudo chmod o+rx /var/log/suricata

Automatická inštalácia to urobí sama — ručne to netreba.

18. Inštalácia Falco

Zachytáva systémové volania cez eBPF/kernel module a odhaľuje anomálie v reálnom čase: shell z nginx, čítanie /etc/passwd webovým procesom, zápis do /bin atď.

curl -fsSL https://falco.org/repo/falcosecurity-packages.asc > /tmp/falco.asc gpg --dearmor < /tmp/falco.asc | sudo tee /usr/share/keyrings/falco-archive-keyring.gpg > /dev/null sudo chmod 644 /usr/share/keyrings/falco-archive-keyring.gpg && rm /tmp/falco.asc echo "deb [signed-by=/usr/share/keyrings/falco-archive-keyring.gpg] https://download.falco.org/packages/deb stable main" \ | sudo tee /etc/apt/sources.list.d/falcosecurity.list sudo apt update && sudo apt install falco sudo systemctl enable --now falco

Monitor číta udalosti Falco cez journalctl -u falco (bez sudo — cez skupinu systemd-journal). Uistite sa, že www-data je v tejto skupine — pozri „Nastavenie sudo“ (bod 2) na stránke manuálnej inštalácie.

„0 udalostí za 24 hodín“ je normálny stav, nie chyba. Falco je event-driven: mlčí, kým je všetko v poriadku, a udalosť zapíše len pri anomálii (shell z webového procesu, čítanie /etc/passwd, zápis do systémových adresárov). Nula kritických za deň na pokojnom serveri je zdravý stav.

Pre dashboard je spoľahlivejší výstup do súboru. Čítanie cez journalctl vyžaduje práva na žurnál; aby dashboard videl udalosti stabilne, automatická inštalácia zapne u Falco file_output → /var/log/falco/falco.log a službe nastaví UMask=0022 (log číta webový server). Pri novej inštalácii to netreba nastavovať ručne.

19. Inštalácia ModSecurity (WAF)

ModSecurity — webový firewall (WAF) pre Apache alebo Nginx. Blokuje útoky na úrovni aplikácie: SQL injekcie, XSS, prechádzanie ciest, skenery.

# Apache: sudo apt install libapache2-mod-security2 sudo a2enmod security2 # Sada pravidiel OWASP Core Rule Set: sudo apt install modsecurity-crs # POVINNÉ: bez tohto súboru je engine pravidiel vypnutý sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf sudo sed -i 's/^SecRuleEngine DetectionOnly/SecRuleEngine On/' /etc/modsecurity/modsecurity.conf sudo apache2ctl configtest && sudo systemctl reload apache2 # Kontrola: malo by vrátiť 403 curl -s -o /dev/null -w '%{http_code}\n' "https://monitor.example.com/?id=1%20UNION%20SELECT%201,2--"

Samotná inštalácia balíka nič nechráni. Apache načítava konfigurácie riadkom IncludeOptional /etc/modsecurity/*.conf, no balík umiestni iba modsecurity.conf-recommended — pod masku *.conf nespadá. Ak ho neskopírujete do modsecurity.conf, SecRuleEngine zostáva Off: modul je načítaný, pravidlá CRS sú načítané, no prevádzka sa nekontroluje a audit log sa nevytvára. Medzirežim DetectionOnly len zapisuje udalosti do logu, požiadavky neblokuje — dashboard ho zobrazuje žlto.

Prístup dashboardu k audit logu. Log /var/log/apache2/modsec_audit.log patrí rootovi (práva 640), webový používateľ ho neprečíta. Dashboard získava dáta cez obal — vytvorte ho:

sudo tee /usr/local/bin/monitor-modsec >/dev/null <<'EOF' #!/bin/sh echo "ENGINE=$(grep -hE '^SecRuleEngine[[:space:]]+' /etc/modsecurity/*.conf 2>/dev/null | tail -1 | awk '{print $2}')" echo "---LOG---" tail -n 3000 /var/log/apache2/modsec_audit.log 2>/dev/null echo "---RULES---" for f in /etc/modsecurity/crs/rules/*.conf /usr/share/modsecurity-crs/rules/*.conf /etc/modsecurity/custom-rules.conf; do [ -f "$f" ] && { echo "===FILE:$(basename "$f")==="; cat "$f"; } done EOF sudo chown root:root /usr/local/bin/monitor-modsec sudo chmod 755 /usr/local/bin/monitor-modsec # v /etc/sudoers.d/monitor (používateľ = ten, pod ktorým beží PHP-FPM): # www-data ALL=(ALL) NOPASSWD: /usr/local/bin/monitor-modsec

Obal berie poslednú direktívu SecRuleEngine bez odsadenia: odsadené riadky sú vnútri blokov <LocationMatch>/<Directory> (napríklad vypnutie WAF pre phpMyAdmin) a globálny režim neurčujú.
Používateľ v sudoers sa musí zhodovať s používateľom FPM poolu: na bežnom Apache/Debian je to www-data, v HestiaCP pool stránky beží pod vlastníkom stránky (napríklad admin) — overte cez grep -E '^user' /etc/php/*/fpm/pool.d/monitor.example.com.conf.
Ak je stránka za Nginx proxy (HestiaCP), Apache vidí ako klienta samotnú proxy — dashboard berie skutočnú IP adresu útočníka z hlavičky X-Forwarded-For. Do štatistiky sa dostávajú len transakcie so spusteným pravidlom: direktíva SecAuditLogRelevantStatus zapisuje do audit logu ľubovoľné odpovede 4xx/5xx, preto sa tam dostávajú aj bežné 403/500 — dashboard ich za udalosti WAF nepovažuje.
Blok ---RULES--- potrebuje sekcia „Všetky aktívne pravidlá“ — dashboard zobrazuje nielen spustené, ale vôbec všetky načítané pravidlá CRS + vlastné. Tri cesty v cykle for f in … sú typické miesta pre CRS pravidlá a lokálne doplnky; ak máte iné rozloženie (balík ukladá súbory do vlastného adresára, alebo vlastné pravidlá nie sú v /etc/modsecurity/custom-rules.conf), nájdite skutočné cesty príkazom

sudo grep -rl 'IncludeOptional\|^Include ' /etc/apache2/mods-enabled/security2.conf /etc/apache2/conf-enabled/*.conf 2>/dev/null

a doplňte ich do zoznamu. Ak je obal starý (bez tejto sekcie) — sekcia jednoducho zobrazí upozornenie „nedostupné“, zvyšok stránky funguje ako predtým.

20. Inštalácia Auditd

Auditd (Linux Audit Daemon) zaznamenáva systémové volania na úrovni jadra: prihlásenia a odhlásenia, sudo príkazy, neúspešné pokusy o autentifikáciu, zmeny súborov. Monitor zobrazuje prihlásenia, neúspešné pokusy a sudo príkazy za dnešný deň.

sudo apt install auditd audispd-plugins sudo systemctl enable --now auditd # Skontrolovať stav a udalosti: sudo systemctl status auditd sudo ausearch -m USER_LOGIN -ts today

Monitor číta udalosti cez ausearch (/usr/sbin/ausearch) a v prípade potreby z /var/log/audit/audit.log príkazom tail. Oba musia byť v sudoers.

21. Inštalácia Monit

Sleduje služby (nginx, php-fpm, mysql atď.) a pri páde ich reštartuje. Dokáže posielať upozornenia na email.

sudo apt install monit sudo systemctl enable --now monit # Konfigurácie: sudo nano /etc/monit/monitrc ls /etc/monit/conf.d/

Monitor získava zoznam služieb cez monit status. V /etc/monit/monitrc musí byť zapnuté HTTP rozhranie (blok set httpd s allow localhost), inak monit status vráti chybu.

Na dashboarde „0 služieb pod dohľadom“? Dva dôvody. (1) HTTP rozhranie je vypnuté — v monitrc je riadok set httpd zakomentovaný (predvolene je ako # set httpd port 2812 …). Odkomentujte blok a povoľte localhost. (2) Samotné zapnuté httpd nič nesleduje — Monit počíta len to, čo je popísané v check-stanzách; bez nich je zoznam prázdny aj pri fungujúcom rozhraní. Minimálna funkčná konfigurácia:

# /etc/monit/conf.d/00-httpd — HTTP rozhranie pre localhost: set httpd port 2812 use address localhost allow localhost # príklady check-stanz (čo sledovať): check process sshd with pidfile /run/sshd.pid start program = "/usr/bin/systemctl start ssh" stop program = "/usr/bin/systemctl stop ssh" check filesystem rootfs with path / if space usage > 90% then alert

sudo monit -t # skontrolovať syntax (Control file syntax OK) sudo systemctl reload monit sudo monit status

Automatická inštalácia vloží hotový conf.d s httpd na 2812 a sadou kontrol — na novej inštalácii nie je potrebné nič nastavovať ručne.

Služba v stave „S chybami“? Monitor iba zobrazuje stav a zámerne nereštartuje služby z webového panela (bolo by to vzdialené vykonávanie root príkazov v bezpečnostnom paneli). Diagnostika a reštart — cez SSH pomocou Monit:

sudo monit status <service> # príčina chyby sudo monit restart <service> # reštart cez Monit # ak Monit službu nespustí — pozrite jej vlastný unit: sudo systemctl status <unit> --no-pager sudo journalctl -u <unit> -n 50 --no-pager

22. Inštalácia PSAD (detekcia skenovania portov)

PSAD analyzuje záznamy iptables a odhaľuje skenovanie portov a sieťové útoky, pričom každému zdroju priradí úroveň hrozby (1 – 5). Dopĺňa fail2ban a Suricata.

sudo apt install psad # PSAD číta log iptables — treba zapnúť logovanie (UFW to robí sám). # Pre čisté iptables pridajte pravidlá LOG do reťazcov INPUT/FORWARD. sudo psad --sig-update sudo systemctl enable --now psad

Monitor číta údaje cez psad --Status (musí byť v sudoers). Bez logovania iptables bude stránka prázdna — je to normálne, kým nedošlo k žiadnym skenovaniam.

23. AppArmor / SELinux (riadenie prístupu)

Mandatory Access Control obmedzuje, ku ktorým súborom a prostriedkom môže program pristupovať, aj keď bol napadnutý. V Ubuntu/Debian sa štandardne používa AppArmor (zvyčajne je už nainštalovaný a aktívny).

# AppArmor (Ubuntu/Debian): sudo apt install apparmor apparmor-utils sudo systemctl enable --now apparmor sudo aa-status # skontrolovať profily

Monitor číta stav cez aa-status (musí byť v sudoers). Zobrazuje počet profilov v režime enforce/complain a procesy bez profilu.

„Načítaných profilov“ je viac než enforce + complain — to je normálne. V AppArmor 4.x (Ubuntu 24.04 a novšie) pribudol režim unconfined: profil je načítaný do jadra, no nič neobmedzuje. Ubuntu takto označuje desiatky profilov pre programy využívajúce user namespaces (prehliadače, torrent klienty a podobne). Keď takéto profily existujú, karta „Načítaných profilov“ zožltne a zobrazí ich počet — napríklad unconfined: 90 pri 120 načítaných a 26 v enforce. Reálne chránia len profily v enforce; na Ubuntu 22.04 (AppArmor 3.x) tento režim neexistuje a čísla vždy sedia.

sudo aa-status | grep -E "profiles are" # rozdelenie podľa režimov sudo aa-enforce /etc/apparmor.d/profile-name # prepnúť profil do enforce

Prepínať do enforce profily, ktoré Ubuntu zámerne ponechalo v unconfined, sa oplatí len uvážene: nie sú vypnuté omylom, ale preto, že inak by sa narušila činnosť samotných programov. Profily v complain sú iná vec: pravidlá sú tam už napísané, len sa neuplatňujú.

24. Inštalácia debsums (integrita balíkov)

debsums overuje, či sa súbory nainštalovaných balíkov zhodujú s kontrolnými súčtami z repozitára — odhalí podvrhnuté systémové binárky (dopĺňa AIDE). Úplná kontrola trvá 1–2 minúty, preto sa spúšťa cez cron a panel číta výsledok z data/debsums/debsums.log a sám ho triedi do kategórií (dôležité sú len binárky a knižnice).

Úloha patrí do root-cronu (sudo crontab -e). Hotový wrapper debsums-scan.sh sa umiestni do /usr/local/bin/ (chmod +x; pozri prehľad cron-úloh) a sám zapisuje správu do data/debsums/ panela.

sudo apt install debsums # Cron-riadok (denne o 4:30): 30 4 * * * /usr/local/bin/debsums-scan.sh >> /path/to/monitor/logs/cron.log 2>&1

Wrapper debsums-scan.sh si sám nájde data/ panela — cestu netreba zadávať.

Zmeny v /etc/ (konfigurácie) a /usr/share/ (zdroje) na serveri sú obvykle normálne — panel ich označuje inou farbou. Znepokojivé sú zmeny binárok a knižníc (/bin, /sbin, /usr/lib atď.) — kartička „Binárky / knižnice“ zobrazuje práve ich.

25. Nastavenie správ Lynis

Lynis sa spúšťa ručne alebo cez cron. Správa sa musí ukladať do priečinka data/lynis/ projektu — monitor číta súbor lynis-report.dat.

# Jednorazové spustenie (doplňte vlastnú cestu ku koreňu panela): sudo lynis audit system --report-file /path/to/monitor/data/lynis/lynis-report.dat # Denný audit — cron riadok (hotová obálka lynis-scan.sh v /usr/local/bin/, pozri prehľad): 0 3 * * * /usr/local/bin/lynis-scan.sh >> /path/to/monitor/logs/cron.log 2>&1

Po prvom spustení stránka „Audit Lynis“ ihneď zobrazí hardening index, upozornenia a odporúčania.

Tlačidlo „Spustiť audit“ na stránke Lynis. Spustí lynis-scan.sh na pozadí priamo z panela (bez čakania na cron): zobrazí „Skenovanie…“ a po dokončení samo aktualizuje správu. Na to potrebuje webový používateľ riadok v sudoers na spustenie skriptu — inštalátor ho pridáva automaticky do /etc/sudoers.d/monitor. Ak sa panel inštaloval ručne/skôr, dopíšte ho tým istým používateľom, ktorý je už uvedený v súbore:

u=$(sudo awk '/NOPASSWD/ && !/lynis-scan/ {print $1; exit}' /etc/sudoers.d/monitor) [ -n "$u" ] && echo "$u ALL=(ALL) NOPASSWD: /usr/local/bin/lynis-scan.sh" | sudo tee -a /etc/sudoers.d/monitor sudo visudo -c && sudo chmod 440 /etc/sudoers.d/monitor

26. Nastavenie správ Logwatch

Logwatch musí ukladať denné správy do priečinka data/logwatch/ projektu vo formáte .txt. Monitor zobrazuje poslednú správu a archív.

# Denne (6:00) — cron-riadok (hotový wrapper logwatch_daily.sh v /usr/local/bin/, pozri prehľad): 0 6 * * * /usr/local/bin/logwatch_daily.sh >> /path/to/monitor/logs/cron.log 2>&1

27. Sieťový monitor (vstavaný)

Sieťový monitor nevyžaduje inštaláciu — je to vstavaná stránka dashboardu. Zobrazuje sieťový stav servera z lokálnych zdrojov:

rozhrania a prevádzka — z /proc/net/dev;
stav liniek (UP/DOWN) a IP — cez ip;
spojenia a načúvajúce porty — cez ss;
sieťové udalosti jadra za 24 h — cez journalctl -k.

Prvé tri zdroje fungujú bez sudo, preto sú rozhrania, prevádzka, spojenia a porty viditeľné okamžite. Blok „Udalosti jadra“ používa journalctl -k — číta sa cez skupinu systemd-journal („Nastavenie sudo“, bod 2), sudo nie je potrebné. Overte, či je všetko dostupné web používateľovi:

# Kontrola pod www-data (pod ním beží PHP): sudo -u www-data bash -c 'cat /proc/net/dev' sudo -u www-data bash -c 'ip -o link show' sudo -u www-data bash -c 'ss -s' sudo -u www-data journalctl -k --no-pager -n 5

Blok „Sieťové udalosti jadra“ zobrazuje udalosti sieťového zásobníka jadra (zmena linky up/down, chyby nosnej, „network unreachable“). Záznamy firewallu UFW BLOCK sem nepatria — sú na stránkach „Firewall UFW“ a „Mapa útokov“. Prázdny blok so zelenou fajkou = za deň neboli žiadne sieťové výpadky.

28. Disk a SMART

Vstavaná stránka zobrazuje tri veci:

Súborové systémy — zaplnenie oddielov (df); škála sčervenie pri ≥90 %;
Úložiská — zoznam diskov (lsblk), len skutočné (loop/snap sú skryté);
Zdravie (SMART) — stav disku a atribúty (smartctl).

Miesto a zoznam zariadení fungujú okamžite, bez nastavovania. Pre SMART je potrebný balík smartmontools. Webový proces nemá priamy prístup k diskovým zariadeniam, preto sa SMART načítava cez cron do súboru data/disk/smart.txt a dashboard ho číta.

Úloha patrí do root-cronu (sudo crontab -e). Hotový obal smart-scan.sh sa umiestni do /usr/local/bin/ (chmod +x; pozri prehľad cron-úloh) a sám zapisuje do data/disk/ dashboardu.

sudo apt install smartmontools # Cron-riadok (každých 30 minút): */30 * * * * /usr/local/bin/smart-scan.sh >> /path/to/monitor/logs/cron.log 2>&1

Obal smart-scan.sh si sám nájde data/ dashboardu — cestu nie je potrebné zadávať. Vnútri lsblk -e7,11 vylučuje loop/cdrom.

Na virtuálnych diskoch (QEMU/KVM a podobných) je zvyčajne dostupný len všeobecný stav „zdravie: OK“, pričom teplota, prevádzkové hodiny a prealokované sektory môžu byť prázdne — to je normálne. Na fyzickom serveri sa zobrazujú všetky atribúty.

29. Výkon (CPU/RAM/sieť/disk)

Stránka zobrazuje históriu záťaže servera za posledných 24 hodín — Load Average, vyťaženie CPU a čakanie na I/O, RAM/Swap, sieťovú prevádzku (príjem/odosielanie), diskové I/O (čítanie/zápis), zaplnenie disku a inode, otvorené súborové deskriptory a MySQL pripojenia, plus aktuálny počet TCP pripojení a procesov.

Údaje zbiera cron/collect_metrics.php — raz za 5 minút zapíše jeden „surový“ snímok počítadiel (/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') do tabuľky DB system_metrics; percentá a rýchlosti stránka počíta sama z rozdielu medzi susednými snímkami (zaplnenie disku/inode/deskriptorov/MySQL pripojenia — okamžité hodnoty, bez prepočtu). Sudo nie je potrebné — zdroje sa čítajú bez práv root. Body staršie ako 24 hodín sa pri každom zápise automaticky mažú.

# Cron-riadok (každých 5 minút): */5 * * * * /usr/local/bin/collect-metrics-all.sh >> /path/to/monitor/logs/cron.log 2>&1

Obálka collect-metrics-all.sh (pozri prehľad cron-úloh) sama nájde všetky nainštalované inštancie panela na serveri a spustí cron/collect_metrics.php každej z nich pod menom vlastníka stránky.

Kým kolektor neprebehne aspoň dvakrát (prvých ~10 minút po inštalácii), stránka zobrazuje „údaje sa zbierajú“ — grafy potrebujú aspoň jednu dvojicu susedných bodov, aby vypočítali rýchlosti a percentá.

Upozornenia na záťaž (sekcia „Nastavenia“ → „Upozornenia na záťaž“) — pri prekročení prahu CPU/RAM/disku/inode panel pošle upozornenie do Telegramu/E-mailu (rovnaké kanály ako denný report — zapínať ich pre alerty zvlášť netreba), a ešte jedno — keď sa metrika vráti do normálu. Počas držania prahu opakovane nespamuje: ďalšie upozornenie príde až po cykle „obnovené → znova prekročené“.

Prahy kontroluje ten istý collect_metrics.php pri každom spustení (raz za 5 minút) — samostatný cron netreba. Stav „už upozornené / ešte nie“ sa ukladá v data/alerts_state.json, prahy — v nastaveniach panela.

30. Mapa útokov (GeoIP)

Stránka „Mapa útokov“ určuje krajinu podľa IP príkazom geoiplookup. Bez balíka GeoIP sa krajiny neurčia a body na mape sa nezobrazia:

sudo apt install geoip-bin geoip-database # Kontrola: geoiplookup 8.8.8.8

Sudo nie je potrebné — databázu /usr/share/GeoIP/GeoIP.dat číta každý, výsledky sa ukladajú do vyrovnávacej pamäte v tmp/geoip_cache.json. Samotná mapa (Leaflet + dlaždice OpenStreetMap) sa načítava v prehliadači — na počítači, kde je otvorený dashboard, je potrebné pripojenie na internet.

31. Externá expozícia, aktualizácie a automatické aktualizácie

Dve zabudované karty dashboardu, ktoré neukazujú „zap./vyp.“ nástroja, ale skutočnú zabezpečenosť servera. Nič netreba inštalovať, čítajú sa lokálne bez sudo.

Externá expozícia — koľko služieb počúva na všetkých rozhraniach (0.0.0.0/[::]) a je dostupných zvonka. Zvýrazní červenou, ak sú navonok vystavené databázy alebo vyrovnávacia pamäť (MySQL, PostgreSQL, Redis, MongoDB, Memcached, Elasticsearch) — to je priama diera (−10 k skóre zabezpečenia). Zdroj: ss -tuln.

Ak je karta červená — uzavrite databázy pred vonkajším svetom: priviažte ich na 127.0.0.1 (bind-address v konfigurácii MySQL/PostgreSQL, bind 127.0.0.1 v Redis) alebo zavrite port v UFW.

„Otvorený port“ ≠ „dostupný zvonka“. Služba počúvajúca na 127.0.0.1 (loopback) je viditeľná len samotnému serveru — zvonka sa k nej nedostanete, aj keď je port „otvorený“. Preto je Postfix na porte 25 priviazaný na loopback bezpečný: automatické nastavenie zapíše inet_interfaces = loopback-only (plus neutrálny smtpd_banner — uzavrie upozornenie Lynis MAIL-8818 o odhalení verzie). Karta „Externá expozícia“ počíta ako navonok iba to, čo počúva na 0.0.0.0/[::]; loopback služby sa tam nedostanú.

Lynis MAIL-8818 ručne (ak ste poštu inštalovali sami): v /etc/postfix/main.cf nastavte smtpd_banner = $myhostname ESMTP (bez verzie a OS) a inet_interfaces = loopback-only, potom sudo systemctl restart postfix.

Bezpečnostné aktualizácie — koľko bezpečnostných záplat čaká na inštaláciu a či je po aktualizácii jadra potrebný reštart (−5 k skóre zabezpečenia pri dostupných záplatách). Zdroj: /usr/lib/update-notifier/apt-check, súbor /var/run/reboot-required. Podrobný zoznam — na stránke „Bezpečnostné aktualizácie“.

# Nainštalovať aktualizácie: sudo apt update && sudo apt upgrade # Skontrolovať, čo počúva navonok: ss -tuln | grep -E '0\.0\.0\.0|\[::\]'

Karta aktualizácií funguje na Ubuntu/Debian (update-notifier-common). Ak apt-check chýba — monitor počíta záplaty cez apt-get -s upgrade.

Automatické bezpečnostné aktualizácie (unattended-upgrades) — na stránke „Bezpečnostné aktualizácie“ samostatná karta ukazuje, či je zapnutá automatická inštalácia bezpečnostných záplat a kedy naposledy prebehla. Sudo nie je potrebné — stav sa číta cez apt-config dump.

sudo apt install unattended-upgrades sudo dpkg-reconfigure -plow unattended-upgrades # zapnúť # Skontrolovať, čo je zapnuté: apt-config dump | grep Unattended-Upgrade

32. Zálohovanie

Záloha je hlavná poistka: strata dát je horšia než akékoľvek napadnutie. Potrebujete dve veci — zálohu servera/webov a samostatne zálohu databázy panela (sú tam používatelia, kľúče WebAuthn, nastavenia, licencia).

Možnosť A — HestiaCP: karta Backup u používateľa → tlačidlo na vytvorenie zálohy (alebo podľa plánu v nastaveniach servera). Záloha zahŕňa weby a ich databázy.

Možnosť B — ručne (cron): dump databázy + archív adresára data/ panela:

# root-cron (sudo crontab -e) — denná záloha o 2:30 (doplňte vlastné názvy/cesty): 30 2 * * * mysqldump -u root MY_DB | gzip > /var/backups/monitor-db-$(date +\%F).sql.gz 40 2 * * * tar czf /var/backups/monitor-data-$(date +\%F).tar.gz -C /path/to/monitor data # Mazať archívy staršie ako 14 dní: 0 3 * * * find /var/backups -name 'monitor-*' -mtime +14 -delete

Záloha na tom istom serveri vás zachráni pred chybami, ale nie pred stratou servera. Kopírujte archívy na externé úložisko (iný server, S3, rclone do cloudu). Overte, že obnovenie naozaj funguje.

33. Aktualizácia a prenos panela

Aktualizácia na novú verziu. Najprv si urobte zálohu. Potom nahrajte súbory kódu znova a zachovajte svoje dáta:

prepísať (kód): public/, includes/, assets/, cron/, database/, ako aj koreňové .htaccess (front-controller — smerovanie sa nesmie ponechať zo starej verzie), manifest.json, sw.js;
nedotýkať sa: config.php (dáta DB), data/ (reporty), logs/, tmp/ (relácie a vyrovnávacia pamäť).

# Po nahratí — vyprázdniť cache PHP (ak je opcache zapnutý): sudo systemctl reload php*-fpm

FileZilla hlási SSH_FX_PERMISSION_DENIED — Permission denied. Súbory panela patria používateľovi www-data (tak boli nastavené pri inštalácii), kým SFTP klient sa pripája pod vaším vlastným používateľom, ktorý nemá právo zápisu. Odovzdať celý panel používateľovi www-data „aby to fungovalo“ je práve to, čo vedie k tejto chybe; nižšie sú tri spôsoby, ktorýkoľvek problém vyrieši.

# Variant A (odporúčané) — oddeliť vlastníkov: kód je váš, pracovné priečinky patria webovému serveru. # Webový server nezíska právo zápisu ku KÓDU panela vôbec: sudo chown -R deploy:www-data /path/to/monitor sudo chown -R www-data:www-data /path/to/monitor/data /path/to/monitor/tmp /path/to/monitor/logs sudo find /path/to/monitor -type d -exec chmod 755 {} \; sudo find /path/to/monitor -type f -exec chmod 644 {} \; sudo chmod 750 /path/to/monitor/data /path/to/monitor/tmp /path/to/monitor/logs sudo chmod 640 /path/to/monitor/config.php # Variant B — ACL nad aktuálnymi vlastníkmi (nič nepresúvame): sudo apt install -y acl sudo setfacl -R -m u:deploy:rwX /path/to/monitor sudo setfacl -R -d -m u:deploy:rwX /path/to/monitor # Variant C — cez skupinu www-data. Jednoduchší, ale právo zápisu k súborom # panela získa aj webový server (pri zraniteľnosti v PHP sa kód dá vymeniť): sudo usermod -aG www-data deploy sudo find /path/to/monitor -type d -exec chmod 2775 {} \; sudo find /path/to/monitor -type f -exec chmod 664 {} \; sudo chmod 640 /path/to/monitor/config.php sudo chmod 2750 /path/to/monitor/data /path/to/monitor/tmp /path/to/monitor/logs

Prečo je variant A bezpečný. Panel zapisuje len do troch priečinkov — data/ (reporty), tmp/ (relácie a vyrovnávacia pamäť), logs/; tie zostávajú za www-data. Zvyšok je kód a webový server ho potrebuje len na čítanie, ktoré poskytuje skupina www-data s právami 644. Vedľajší zisk: pri zraniteľnosti v PHP sa súbory panela už nedajú prepísať. Na hostingových paneloch (HestiaCP a podobných) variant A netreba: tam súbory stránky aj tak patria účtu, pod ktorým sa prihlasujete cez SFTP, a webový server ich číta cez skupinu.
Nástraha variantu B: každý ďalší chmod na súboroch resetuje ACL-masku a prístup ticho zmizne. Ak sa po „upratovaní práv“ nahrávanie opäť zasekne na Permission denied — zopakujte obe príkazy setfacl.
Bit 2 vo variante C je setgid: súbory nahrané cez SFTP zostávajú v skupine www-data, inak ich panel nedokáže prepísať. Po variante C sa vo FileZille pripojte nanovo — nová skupina sa prejaví až pri novom prihlásení. Kontrola: id deploy (musí sa objaviť skupina www-data) a ls -ld /path/to/monitor (drwxrwsr-x — písmeno s znamená, že setgid je nastavený).

Prenos na iný server:

Na novom serveri sprevádzkujte stránku + HTTPS (pozri stránku manuálnej inštalácie).
Skopírujte všetky súbory panela spolu s config.php, data/.
Preneste DB: mysqldump na starom → import na novom; upravte dáta DB v config.php.
Zopakujte na novom serveri: sudoers, členstvo v skupine adm, cron-úlohy.
Licencia je viazaná na doménu — ak je doména rovnaká, kľúč bude fungovať ďalej.

34. Obnovenie prístupu (stratený kľúč, heslo, blokovanie IP)

Ak sa nemôžete prihlásiť — všetko sa dá opraviť priamo v databáze na serveri. Otvorte databázu (názov je z config.php):

sudo mysql MY_DB

Stratený kľúč WebAuthn (neprejde druhý faktor) — vypnite 2FA, prihláste sa heslom a zaregistrujte nový kľúč:

UPDATE users SET webauthn_enabled = 0;

Zabudnuté heslo — nastavte nový hash (vygenerujte ho na serveri a doplňte):

# Vygenerovať hash nového hesla: php -r "echo password_hash('NEW_PASSWORD', PASSWORD_BCRYPT), \"\n\";" # V databáze (vložte získaný hash): # UPDATE users SET password = '$2y$10$...' WHERE username = 'admin';

Zablokovali ste si prístup IP-filtrom — vypnite obmedzenie:

UPDATE settings SET value = '0' WHERE name = 'ip_restriction_enabled';

Prístup k databáze máte vždy: sudo mysql na serveri, prípadne phpMyAdmin / sekcia databázy v paneli hostingu. Po obnovení znova zapnite WebAuthn a IP-filter.

35. Všetky cron úlohy na jednom mieste

Súhrn úloh je v root cron serveri (pridávajú sa cez sudo crontab -e). Ponechajte len riadky tých nástrojov, ktoré používate; cesty upravte podľa svojho servera.

# Serverový cron monitora (root) — vpíšte cez: sudo crontab -e # 01:30 — sken ClamAV na nebezpečných cestách (web, home, temp) → karty „Skontrolovaných súborov“ a „Posledné skenovanie“ 30 1 * * * /usr/local/bin/clamav-scan.sh >> /path/to/monitor/logs/cron.log 2>&1 # 02:00 — kontrola integrity súborov AIDE (potrebný explicitný --config) 0 2 * * * /usr/bin/aide --config /etc/aide/aide.conf --check > /var/log/aide/aide.log 2>&1 # pri štarte — obnoviť práva /var/lib/aide (balíkový tmpfiles súbor # aide-common.conf ich resetuje na 0700 a panel prestane vidieť databázu) @reboot chmod 755 /var/lib/aide # 03:00 — bezpečnostný audit Lynis 0 3 * * * /usr/local/bin/lynis-scan.sh >> /path/to/monitor/logs/cron.log 2>&1 # 04:00 — aktualizácia blokovacieho zoznamu ipsum (level 1) 0 4 * * * /usr/local/bin/load-ipsum.sh >> /path/to/monitor/logs/cron.log 2>&1 # sadu ipsum pri štarte zdvíha služba ipsum-load.service (PRED firewallom, inak # UFW nevidí sadu v before.rules) — nie je to cron. Tu je len denný refresh vyššie. # 06:00 — report Logwatch 0 6 * * * /usr/local/bin/logwatch_daily.sh >> /path/to/monitor/logs/cron.log 2>&1 # každých 30 min — kontrola diskov SMART */30 * * * * /usr/local/bin/smart-scan.sh >> /path/to/monitor/logs/cron.log 2>&1 # 04:30 — integrita balíkov debsums 30 4 * * * /usr/local/bin/debsums-scan.sh >> /path/to/monitor/logs/cron.log 2>&1 # 08:00 — plánovaný report na Email a Telegram 0 8 * * * /usr/local/bin/daily-report-all.sh >> /path/to/monitor/logs/cron.log 2>&1 # každú hodinu — obnova zoznamov balíkov (pre kartu „Bezpečnostné aktualizácie“) 0 * * * * /usr/bin/apt-get update -qq >/dev/null 2>&1 # každých 5 min — snímka zdrojov (CPU/RAM/sieť/disk) pre stránku „Výkon“ */5 * * * * /usr/local/bin/collect-metrics-all.sh >> /path/to/monitor/logs/cron.log 2>&1

Podrobnosti ku každej sú v príslušných sekciách. Zálohovacie úlohy (predchádzajúca sekcia) sa pridávajú do toho istého cronu. Po úpravách skontrolujte: sudo crontab -l a či je cron služba aktívna.

Čas cronu = časové pásmo servera, nie TIMEZONE z config.php. Konštanta TIMEZONE ovplyvňuje len PHP (ako panel zobrazuje dátumy), ale cron démon spúšťa úlohy podľa systémového času OS. Ak sa pásmo servera nezhoduje s vaším, report „08:00“ príde v inom čase. Príklad: server je v inom pásme (Europe/London, UTC+1), a vy v Bratislave (UTC+2) → report „08:00“ vám príde o 09:00. Skontrolujte a v prípade potreby nastavte pásmo systému na svoje:

# Skontrolovať aktuálne pásmo servera: timedatectl # Nastaviť svoje pásmo (príklad) a reštartovať cron: sudo timedatectl set-timezone Europe/Bratislava sudo systemctl restart cron

Potom sa riadok 0 8 * * * spustí o 08:00 miestneho času. Inak by ste museli posúvať samotný cron, no pri prechode na zimný/letný čas sa posun opäť rozíde — preto je správnejšie nastaviť pásmo systému.

Hotové obalové skripty. Ich pracovné kópie a vzor crontabu (crontab.txt) sú v priečinku system/ vedľa projektu, mimo public_html. Toto nie je súčasť webu — nie je potrebné ich nahrávať do webového koreňa; umiestnite ich na server na systémové cesty (ako v crontabe vyššie):

lynis-scan.sh → /usr/local/bin/ (chmod +x) — spúšťa lynis audit system, počas skenu nastaví príznak /tmp/lynis-running a skopíruje lynis-report.dat do data/lynis/ panela;
logwatch_daily.sh → /usr/local/bin/ (chmod +x) — vytvára denný report Logwatch (sshd, fail2ban, sudo, postfix) do data/logwatch/;
smart-scan.sh → /usr/local/bin/ (chmod +x) — sníma stav diskov (smartctl) do data/disk/;
debsums-scan.sh → /usr/local/bin/ (chmod +x) — kontroluje integritu balíkov (debsums) do data/debsums/;
clamav-scan.sh → /usr/local/bin/ (chmod +x) — antivírusový sken ClamAV na nebezpečných cestách (web, home, temp); zapisuje súhrn do /var/log/clamav/scan.log, odkiaľ ho číta stránka ClamAV (riadok 01:30 v crontabe vyššie);
load-ipsum.sh → /usr/local/bin/ (chmod +x) — aktualizuje ipset sadu ipsum (level 1) na mieste, bez narušenia aktívnych pravidiel firewallu (riadok 04:00 v crontabe vyššie);
daily-report-all.sh → /usr/local/bin/ (chmod +x) — spúšťa report cron/daily_report.php panela (riadok 08:00 v crontabe vyššie);
daily_report.php — už je súčasťou panela (cron/daily_report.php), spúšťa sa cez daily-report-all.sh, samostatne ho netreba inštalovať;
collect-metrics-all.sh → /usr/local/bin/ (chmod +x) — spúšťa cron/collect_metrics.php panela (stránka „Výkon“, riadok */5 v crontabe vyššie); collect_metrics.php už je súčasťou panela, samostatne ho netreba inštalovať;
crontab.txt (system/cron/) — vzor úloh; potrebné riadky vpíšte cez sudo crontab -e.

Cesta ku skriptu v crontabe sa musí zhodovať s tým, kam ste ho umiestnili.

Ako umiestniť skript do /usr/local/bin/. Priamo z FileZilly tam nezapíšete — priečinok patrí root a SFTP-klient dostane SSH_FX_PERMISSION_DENIED. Postup je takýto: najprv nahrať súbor do /tmp (tam píšu všetci), potom ho jedným príkazom presunúť na miesto:

# vo FileZille: do poľa „Vzdialená lokalita“ zadať /tmp a nahrať tam skript, # potom cez SSH (install rovno nastaví vlastníka a práva, chown/chmod netreba): sudo install -o root -g root -m 755 /tmp/lynis-scan.sh /usr/local/bin/lynis-scan.sh rm -f /tmp/lynis-scan.sh # kontrola: súbor je na mieste, práva rwxr-xr-x, syntax neporušená bash -n /usr/local/bin/lynis-scan.sh && ls -l /usr/local/bin/lynis-scan.sh

Nepomýľte si priečinky: potrebný je /tmp v koreni servera — nie /var/tmp ani tmp/ vnútri samotného panela (posledný patrí www-data a je zatvorený pred vaším používateľom). V strome FileZilly je /tmp vetva najvyššej úrovne, vedľa var, nie vnútri neho.

Inštalovali ste server automatickým nastavením? Tieto obaly a ich cron úlohy sú už nainštalované skriptom (v /usr/local/bin/, log — /var/log/arciveo-cron.log) — ručne nemusíte robiť nič.

Kde skripty hľadajú panel. Obaly sú doménovo neutrálne: inštalácie panela nájdu prehľadaním /home/*/web/*/public_html a /var/www/* a reporty ukladajú do ich data/. Ak je panel na inej ceste — pridajte ju do riadku for app in … vnútri skriptov, inak sa reporty Lynis/SMART/debsums/Logwatch do panela nedostanú.

cron.log a prístupové práva. Súbor logs/cron.log ako prvý vytvorí root cron — bude patriť root a záložka „Cron log“ v paneli ho nebude môcť ani prečítať, ani vyčistiť. Vytvorte súbor vopred v mene webového používateľa (vlastník priečinka webu; v HestiaCP je to účet, napr. admin) — potom bude root cron len dopisovať bez zmeny vlastníka:

# vytvoriť vopred pod webovým používateľom (pred pridaním cron riadkov): sudo -u OWNER touch /path/to/monitor/logs/cron.log # ak cron.log už vytvoril root cron — odovzdať webovému používateľovi: sudo chown OWNER:OWNER /path/to/monitor/logs/cron.log sudo chmod 644 /path/to/monitor/logs/cron.log

Zistiť vlastníka priečinka: stat -c %U /path/to/monitor.

Správa z panela. V sekcii „Systém“ je stránka „Crontab“ — úlohy môžete prezerať a pridávať bez SSH. Panel upravuje len úlohy pridané cezeň samotný (samostatný blok v root-crontabe, označený služobnými komentármi); všetko, čo už je v crontabe (zoznam vyššie), je tam zobrazené v zozname „Ostatné úlohy servera“ len na čítanie s tlačidlom „Kopírovať do editora“ — to len prenesie plán/príkaz do formulára na pridanie, pôvodný riadok nemení. Ak chcete existujúcu úlohu „previesť“ pod správu panela — skopírujte ju do editora, uložte a potom starý riadok odstráňte ručne (sudo crontab -e), inak sa bude vykonávať dvakrát.

Jednorazové nastavenie na serveri. Stránka potrebuje privilegovaný obalový skript — nie holý sudo crontab (to by bola priama eskalácia na root pre každého, kto získa prístup k relácii panela), ale úzky skript s dvomi príkazmi (list/set), ktorý sa dotýka len svojho bloku medzi služobnými komentármi. Nainštalujte raz:

sudo install -m 0755 -o root -g root /dev/stdin /usr/local/sbin/arciveo-cron <<'ARCIVEO_CRON_EOF' #!/bin/bash set -euo pipefail BEGIN='# >>> ARCIVEO-CRON-MANAGED (edited from the panel; do not edit by hand) >>>' END='# <<< ARCIVEO-CRON-MANAGED <<<' cmd=${1:-} case "$cmd" in list) [ "$#" -eq 1 ] || { echo "usage: ${0##*/} list" >&2; exit 2; } crontab -l -u root 2>/dev/null || true ;; set) [ "$#" -eq 1 ] || { echo "usage: ${0##*/} set (body on stdin)" >&2; exit 2; } body=$(cat) if grep -qF "$BEGIN" <<<"$body" || grep -qF "$END" <<<"$body"; then echo "invalid body: markers not allowed" >&2; exit 2 fi current=$(crontab -l -u root 2>/dev/null || true) tmp=$(mktemp); trap 'rm -f "$tmp"' EXIT { if grep -qF "$BEGIN" <<<"$current"; then awk -v b="$BEGIN" '{print} $0==b{exit}' <<<"$current" else [ -n "$current" ] && printf '%s\n' "$current" echo "$BEGIN" fi printf '%s\n' "$body" echo "$END" if grep -qF "$END" <<<"$current"; then awk -v e="$END" 'f{print} $0==e{f=1}' <<<"$current" fi } > "$tmp" crontab -u root "$tmp" ;; *) echo "usage: ${0##*/} <list|set>" >&2; exit 2 ;; esac ARCIVEO_CRON_EOF echo "www-data ALL=(ALL) NOPASSWD: /usr/local/sbin/arciveo-cron" | sudo tee -a /etc/sudoers.d/monitor sudo visudo -c

Webový používateľ sa môže líšiť od www-data — skontrolujte, pod kým beží PHP-FPM pool webu (ps -o user= -C php-fpm), a doplňte ho do sudoers riadku.

Nový súbor sa nahral pod nesprávnym vlastníkom — stránka odpovedá „Access denied.“. Ak sa súbor public/crontab_monitor.php nahral cez FTP/SFTP pod iným systémovým používateľom (napríklad root) než ostatné súbory webu, webový server ho nebude môcť prečítať. Porovnajte vlastníka a práva so susedným súborom a zosúlaďte ich:

ls -la public/crontab_monitor.php public/ssl_monitor.php sudo chown OWNER:OWNER public/crontab_monitor.php sudo chmod 644 public/crontab_monitor.php

36. Nástroj je nainštalovaný, ale zobrazuje sa „Nenainštalované“

Monitor zisťuje prítomnosť nástrojov cez dpkg-query — databázu balíkov APT. Ak nástroj nie je nainštalovaný cez apt (ručne, zo snap-u alebo zo zdrojov), dpkg ho nevidí.

# Overiť cez dpkg: dpkg -l fail2ban | grep '^ii' dpkg -l auditd | grep '^ii' # Nájsť cestu k binárke: which ufw fail2ban-client auditctl # Test sudo pod www-data: sudo -u www-data sudo fail2ban-client status sudo -u www-data sudo ufw status verbose

37. Riešenie problémov (500, žiadne dáta)

Chyba 500 — skontrolujte logy PHP, nginx a samotného monitora:

tail -50 /var/log/nginx/error.log tail -50 /var/log/php*-fpm.log # Logy monitora: tail -50 logs/monitor_$(date +%Y-%m-%d).log # Práva na priečinky: ls -la data/ tmp/ logs/

Panel na hostingovom paneli (HestiaCP, ISPmanager, cPanel)? Tam PHP nebeží pod www-data, ale pod účtom používateľa (napríklad admin — vlastník adresára stránky). Všetky sudo-pravidlá a členstvo v skupinách (adm, systemd-journal) treba nastaviť na tohto používateľa, inak moduly pri bežiacich službách zobrazia „Neaktívny / 0“. Skutočného používateľa PHP zistíte: ps -o user= -C php-fpm | sort -u alebo vlastník adresára stránky stat -c '%U' /path/to/monitor. Vo všetkých príkazoch nižšie ho potom dosaďte namiesto www-data. Automatická inštalácia web-používateľa určí sama a nastaví naň sudoers.

Dáta sa nezobrazujú — takmer vždy ide o nenastavené sudo-práva. Skontrolujte konkrétny príkaz pod web-používateľom (nahraďte www-data svojím). Prepínač -n = bez hesla, ako u PHP — ak si pýta heslo, znamená to, že pravidlo v sudoers chýba:

sudo -u www-data sudo -n fail2ban-client status sudo -u www-data sudo -n ufw status verbose sudo -u www-data sudo -n ipset list -t ipsum sudo -u www-data sudo -n /usr/sbin/ausearch -m USER_LOGIN -ts today sudo -u www-data sudo -n /usr/sbin/aa-status sudo -u www-data sudo -n /usr/sbin/psad --Status sudo -u www-data journalctl -u falco --no-pager -n 5

Modul píše „Neaktívny“ / „0“, hoci nástroj funguje (napríklad sudo aa-status v termináli zobrazuje profily, ale stránka „AppArmor“ — „Neaktívny“). Príčina: web-používateľ nemá sudo-právo na príkaz tohto modulu. Skontrolujte ho zo zoznamu vyššie: ak si pýta heslo — pridajte chýbajúci riadok do /etc/sudoers.d/monitor („Nastavenie sudo“). Časté „nové“ príkazy: /usr/sbin/aa-status (MAC), /usr/sbin/psad --Status (PSAD).

Ak je konkrétna stránka (Falco, ModSecurity, Auditd, otvorené porty UFW) prázdna — porovnajte so zoznamom v sekcii o sudo: pravdepodobne nie je povolený apache2ctl, ausearch, aa-status alebo ss, prípadne web-používateľ nie je v skupinách adm/systemd-journal (odtiaľ sa čítajú logy fail2ban/auth/modsec a journalctl — Falco a udalosti jadra).

38. Stránka je prázdna, hoci údaje na serveri sú

Príznak: na serveri údaje sú (cez shell viditeľné), no stránka zobrazuje „žiadne údaje“ alebo nesprávny stav — napríklad AIDE hlási „Neinicializované“, hoci databáza je vytvorená.

Príčinou je open_basedir: mnohé panely a hostingy obmedzujú fond PHP-FPM na adresár domény, takže PHP funkcie file_exists(), file_get_contents(), filemtime() na systémových cestách (/var/lib/aide, /var/log, /proc…) sú blokované. Monitor to obchádza tak, že takéto cesty číta štandardnými systémovými príkazmi (cat, test, stat).

# Je súbor viditeľný cez shell (takto číta monitor): sudo -u www-data bash -lc 'test -e /var/lib/aide/aide.db && echo VISIBLE || echo NO' # Aktuálna hodnota open_basedir pre fond domény: grep -ri open_basedir /etc/php/*/fpm/pool.d/ 2>/dev/null

Ak shell súbor „vidí“ (VISIBLE), no stránka nie — je to open_basedir. Správnym riešením je čítanie systémovými príkazmi (už zavedené pre AIDE a Sieťový monitor). Rozširovať open_basedir na /var, /proc nie je potrebné a je menej bezpečné.

39. SSL stránka nefunguje

Monitor kontroluje certifikáty priamym pripojením k doménam cez port 443. Ak je doména zo samotného servera nedostupná alebo je port blokovaný firewallom, kontrola neprebehne.

# Overiť certifikát ručne: echo | openssl s_client -connect monitor.example.com:443 2>/dev/null \ | openssl x509 -noout -dates # Overiť dostupnosť: curl -I https://monitor.example.com

Domény monitor preberá automaticky z konfigurácií Nginx (/etc/nginx/sites-enabled/, /etc/nginx/conf.d/) a Apache (/etc/apache2/sites-enabled/) plus aktuálny hostiteľ z HTTP_HOST.

Automatické zisťovanie subdomén. Subdomény sa zisťujú automaticky z verejných logov Certificate Transparency a overujú sa cez sieť — aj keď sú umiestnené na iných serveroch. Ručne netreba nič pridávať.

40. Vidno len jednu DB z viacerých

Monitor sa pripája k MySQL pod používateľom z config.php, ktorý má prístup len k svojej databáze. MySQL zobrazuje v information_schema iba databázy s oprávneniami — preto ostatné nie sú viditeľné.

Aby monitor videl všetky DB, prideľte tomuto používateľovi právo len na čítanie (raz od root; doplňte meno používateľa z config.php):

sudo mysql -u root GRANT SELECT, PROCESS, SHOW DATABASES ON *.* TO 'DB_USER'@'localhost'; FLUSH PRIVILEGES; EXIT;

SELECT ON *.* dáva iba právo na čítanie — nič sa nedá zmeniť, zmazať ani vytvoriť, čo je pre monitorovanie bezpečné.

Bez tohto GRANT panel vidí len svoju databázu — nejde o chybu, ale o obmedzenie práv. Žiadny sudo mysql panel nepoužíva: zoznam databáz získava cez svoje vlastné PDO-pripojenie.

41. PostgreSQL sa nezobrazuje na stránke „Databáza“

PostgreSQL vyžaduje prístup na úrovni používateľa postgres, ktorý webový používateľ panela nemá. Otvárať z PHP široký sudo psql nie je bezpečné — namiesto toho panel volá úzku obálku bez parametrov, ktorá iba vypíše verziu, počet spojení a zoznam databáz s veľkosťami. Vytvorte ju:

sudo tee /usr/local/bin/monitor-pgstat >/dev/null <<'EOF' #!/bin/sh # Arciveo Monitor - read-only PostgreSQL version, connections and per-database size sudo -u postgres psql -tAc "SELECT version();" | grep -oE 'PostgreSQL [0-9.]+' echo "---" sudo -u postgres psql -tAc "SELECT count(*) FROM pg_stat_activity;" echo "---" sudo -u postgres psql -tAc "SELECT datname || '|' || pg_size_pretty(pg_database_size(datname)) FROM pg_database WHERE datistemplate = false;" EOF sudo chown root:root /usr/local/bin/monitor-pgstat sudo chmod 755 /usr/local/bin/monitor-pgstat # v /etc/sudoers.d/monitor (používateľ = ten, pod ktorým beží PHP-FPM): # www-data ALL=(ALL) NOPASSWD: /usr/local/bin/monitor-pgstat

Ak PostgreSQL nepoužívate — odstráňte riadok monitor-pgstat zo sudoers (krok 13 manuálnej inštalácie) a samotný skript nevytvárajte: karta PostgreSQL zostane jednoducho neaktívna.

42. Spustil sa alert — čo robiť

Panel ukazuje, čo sa deje; nižšie nájdete, čo robiť v typických situáciách. Základný princíp: nepanikáriť, porovnať s legitímnou aktivitou (vaše akcie, aktualizácie, zálohy) a reagovať podľa závažnosti.

Mapa útokov / veľa banov fail2ban — to je norma pre každý server v internete (boty neustále skúšajú SSH/web). Hlavné je, aby bany fungovali. Uistite sa, že prihlásenie cez SSH je len kľúčom (heslo je vypnuté) a vaša IP je v ignoreip.
ModSecurity zablokoval požiadavky — WAF odráža útoky na web, to je jeho úloha. Ak sa blokuje váš legitímny prenos (falošné spustenie) — nájdite rule id v detailoch a pridajte výnimku do konfigurácie CRS.
AIDE: zmenené súbory — porovnajte zoznam s tým, čo ste robili (aktualizácia balíkov, úprava konfigurácií — norma). Zmeny systémových binárok, ktorých ste sa nedotkli, sú dôvodom na obozretnosť. Po legitímnych zmenách aktualizujte databázu AIDE.
debsums: zmenené binárky/knižnice (mimo /etc, mimo /usr/share) — potenciálna podvrhnutie. Overte balík: debsums PACKAGE_NAME, pri pochybnostiach ho preinštalujte (apt install --reinstall).
ClamAV / maldet: nájdená hrozba — skontrolujte súbor v karanténe, neotvárajte ho. Ak ide o web shell v adresári webu — izolujte server a hľadajte bod vstupu (zraniteľný plugin, únik prístupov).
Falco: kritické udalosti (spustenie shellu v kontajneri, prístup k citlivým súborom) — rozoberte udalosť: čí proces, čo ho spustilo. Často ide o legitímnu administrátorskú aktivitu.
Externá expozícia: červeno databáza/cache — okamžite zatvorte: priviažte službu na 127.0.0.1 alebo zatvorte port v UFW. To je reálna diera.
SSL vyprší / vypršal — obnovte certifikát (Let's Encrypt sa obnovuje sám; ak nie — skontrolujte certbot renew alebo nastavenia v paneli).
Bezpečnostné aktualizácie čakajú — nainštalujte: sudo apt update && sudo apt upgrade; po aktualizácii jadra reštartujte server.

Príznaky skutočného prieniku (neznáme procesy/používatelia, zmenené binárky, odchádzajúci spam, neznáme cron úlohy): odpojte server od externého prístupu, urobte zálohu na analýzu a ak sú dáta kritické, postavte čistý server z dôveryhodnej zálohy — spoľahlivo vyčistiť rootkit je náročné.

Kde začať