Toto je návod na inštaláciu, konfiguráciu a údržbu Arcivéo Security Monitor. Sekcie sú rozdelené do skupín: všeobecný prehľad, nasadenie panela, pripojenie bezpečnostných nástrojov, zabudované moduly a diagnostika. Príkazy môžete skopírovať tlačidlom vpravo.
Inštalácia panela je na samostatných krokových stránkach. Vyberte spôsob:
Arcivéo Security 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ť.
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.
Dva rytmy práce. Stránky panela sa pýtajú nástrojov v okamihu otvorenia — vždy vidíte aktuálny stav. Okrem toho bežia na pozadí úlohy podľa rozvrhu (cron):
Úplný zoznam úloh je v kapitole „Všetky cron úlohy na jednom mieste“.
Skóre začína na maxime a znižuje sa za každý zistený problém:
PermitRootLogin yes) — −20PasswordAuthentication yes) — −10X11Forwarding, MaxAuthTries nad 3 alebo sshd_config čitateľný pre všetky účty — −5TRACE alebo chýba hlavička Strict-Transport-Security či X-Frame-Options — −5Výsledok: 80+ = Chránený, 60–79 = Pozor, <60 = Ohrozený.
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é.
Kanály sú štyri: Telegram, Email, webhook a push v prehliadači. Sú na sebe nezávislé — zapnite ktorékoľvek, pokojne všetky štyri. Rovnakými kanálmi chodí denná bezpečnostná správa, upozornenia na záťaž aj nálezy senzora udalostí; nastavujú sa raz, tu, v sekcii „Nastavenia“.
Telegram. Potrebujete token bota a chat id:
@BotFather → /newbot → dostanete token v tvare 123456:ABC....@userinfobot, alebo otvorte https://api.telegram.org/bot<TOKEN>/getUpdates a nájdite "chat":{"id":...}.Email. Dva spôsoby na výber v „Nastavenia“ → Email:
re_...) a overenú doménu odosielateľa.Webhook. Jediná adresa prijímajúca POST pokryje Slack, Discord, Mattermost, n8n aj vlastnú obsluhu. „Nastavenia“ → Webhook: vložte adresu a zapnite prepínač.
{"text": …}, do Discordu {"content": …} (Discord odmieta správy dlhšie ako 2000 znakov, text sa preto skracuje);text, event, severity, source, count, host, ts — text správy netreba znova rozoberať.Push upozornenia. Správa príde priamo do prehliadača, a ak je panel pridaný na domovskú obrazovku telefónu, ako bežné upozornenie aplikácie — bez bota a bez poštového servera medzi tým. „Nastavenia“ → Push upozornenia: zapnite prepínač a na každom zariadení, ktoré má upozornenia dostávať, stlačte „Pripojiť toto zariadenie“. Počítadlo „Pripojené zariadenia“ ukazuje, koľko ich je.
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“.
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):
my.arciveo.com → sekcia „Licencie“ / „Aktivácia licencie“ — skopírujte kód ARCIVEO-….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ť“.Panel kryptograficky overuje kľúč: podpis, viazanie na doménu a platnosť.
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.
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. 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.
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.
Panel je chránený prihlásením heslom a, ak je zapnutý, IP filtrom. Programu nevyhovuje ani jedno, preto majú externé systémy vlastný vstup — dve adresy len na čítanie zabezpečené tokenom. Token na serveri nič nemení: dajú sa ním získať iba ukazovatele.
Zapnutie — „Nastavenia“ → „API len na čítanie“: prepínač „Zapnúť API“; token sa vytvorí automaticky pri prvom uložení. Tlačidlo „Nový token“ vydá iný a v tej istej chvíli odstrihne všetkých, ktorí používali predchádzajúci.
/api/status.php — JSON: bezpečnostné skóre, stav modulov, posledné meranie záťaže vrátane najnáročnejších procesov a bezpečnostné udalosti za posledných 24 hodín;/api/metrics.php — tie isté čísla v textovom formáte Prometheus (metriky arciveo_*: arciveo_security_score, arciveo_fail2ban_banned, arciveo_cpu_busy_pct a ďalšie).Ak váš klient nevie nastaviť hlavičku, token sa prijíma aj ako parameter — ?token=…. Rátajte s tým, že v tejto podobe skončí v prístupovom logu webového servera, hlavička je preto vhodnejšia.
Prometheus. Hotový blok pre scrape_configs:
api disabled — API je v nastaveniach vypnuté. Odmietnuté požiadavky sa zapisujú do logu aplikácie spolu s IP odosielateľa, takže hádanie tokenu je vidieť na stránke „Logy aplikácie“.
Panel sa inštaluje na každý server zvlášť a na otázku „ako sa darí tomuto stroju“ odpovedá dobre. Na otázku „ako sa darí všetkým mojim strojom“ neodpovedá — preto môže každý panel posielať krátky prehľad do zákazníckeho účtu, kde sú servery vidieť v jednom zozname.
Čo si vziať v zákazníckom účte my.arciveo.com → sekcia „Moje servery“: vydáva sa tam token (v tvare fk_…) a je uvedená adresa príjemcu https://my.arciveo.com/api/fleet.php. Token je jeden na účet — rovnaký pre všetky vaše servery.
Čo nastaviť v paneli — „Nastavenia“ → „Prehľad serverov“: adresa príjemcu, token, názov servera (ako bude v zozname podpísaný; ak necháte prázdne, vezme sa doména panela) a prepínač „Posielať prehľad“. Tlačidlo „Odoslať teraz“ overí spojenie okamžite, bez čakania na rozvrh.
Ďalej prehľad odchádza cronom, každých 15 minút:
Čo presne odchádza: názov a doména servera, operačný systém, čas behu, verzia PHP; bezpečnostné skóre; stav modulov (UFW, počet jailov Fail2ban, bany za dnešok, či bežia CrowdSec, Suricata a Falco, hrozby ClamAV, zmeny AIDE, index Lynis, čakajúce aktualizácie, či je nutný reštart, dni do vypršania certifikátu, počet nebezpečne otvorených portov); posledné meranie záťaže (load, CPU, RAM, disk, inody); počítadlá udalostí za posledných 24 hodín a posledná kritická udalosť. Logy, heslá ani obsah súborov prehľad neobsahuje.
sudo crontab -l) a čo odpovie tlačidlo „Odoslať teraz“. Chyby odosielania sa zapisujú do logu aplikácie so značkou FLEET — tam je vidieť, či bol odmietnutý token (HTTP 401), alebo či vôbec nevzniklo spojenie.
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á.
ufw enable vždy povoľte SSH (ufw allow OpenSSH), inak stratíte prístup k serveru.
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ť.
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.
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:
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“):
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:
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“.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.
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:
@reboot. Zároveň príkaz create … -exist nastaví limit maxelem 300000 (predvolene 65536 — level 1 sa nezmestí, nastane „Hash is full“):
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.
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.
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).
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ľúč:
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).
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.
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:
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.
/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:
chmod 755 /var/lib/aide a cron kontroly o 02:00 — ručne nie je potrebné nič.
sudo aideinit && sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db.
Antivírusový skener pre Linux. Obzvlášť užitočný na kontrolu /var/www na prítomnosť PHP shellov a škodlivého kódu.
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:
2. Nie je stiahnutá databáza signatúr — clamd sa bez nej nespustí:
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).
sudo journalctl -u clamav-daemon -n 30 --no-pager.
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.
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.
maldet --report.
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.
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“.
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).
/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é:
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ď.
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.
/etc/passwd, zápis do systémových adresárov). Nula kritických za deň na pokojnom serveri je zdravý stav.
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.
ModSecurity — webový firewall (WAF) pre Apache alebo Nginx. Blokuje útoky na úrovni aplikácie: SQL injekcie, XSS, prechádzanie ciest, skenery.
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:
SecRuleEngine bez odsadenia: odsadené riadky sú vnútri blokov <LocationMatch>/<Directory> (napríklad vypnutie WAF pre phpMyAdmin) a globálny režim neurčujú.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.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.---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.
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ň.
ausearch (/usr/sbin/ausearch) a v prípade potreby z /var/log/audit/audit.log príkazom tail. Oba musia byť v sudoers.
Sleduje služby (nginx, php-fpm, mysql atď.) a pri páde ich reštartuje. Dokáže posielať upozornenia na email.
monit status. V /etc/monit/monitrc musí byť zapnuté HTTP rozhranie (blok set httpd s allow localhost), inak monit status vráti chybu.
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:
conf.d s httpd na 2812 a sadou kontrol — na novej inštalácii nie je potrebné nič nastavovať ručne.
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.
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.
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).
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.
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ú.
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.
Wrapper debsums-scan.sh si sám nájde data/ panela — cestu netreba zadávať.
/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.
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.
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:
Logwatch musí ukladať denné správy do priečinka data/logwatch/ projektu vo formáte .txt. Monitor zobrazuje poslednú správu a archív.
Sieťový monitor nevyžaduje inštaláciu — je to vstavaná stránka dashboardu. Zobrazuje sieťový stav servera z lokálnych zdrojov:
/proc/net/dev;ip;ss;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:
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.
Vstavaná stránka zobrazuje tri veci:
df); škála sčervenie pri ≥90 %;lsblk), len skutočné (loop/snap sú skryté);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.
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.
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. Predvolené je okno 24 hodín: tlačidlá hore ho prepnú na 7 dní alebo 30 dní.
Ú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.
Dve hĺbky uchovávania. „Surové“ päťminútové snímky žijú jeden deň (plus hodina rezervy, aby najstarší bod grafu mal ešte predchodcu na výpočet). Každá dokončená hodina sa zloží do jediného riadka; tento hodinový rad sa uchováva 30 dní a práve ten čítajú pohľady „7 dní“ a „30 dní“. Mesiac histórie tak stojí približne 720 riadkov namiesto zhruba 8600.
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.
Najnáročnejšie procesy. Pod grafmi sú dve tabuľky s piatimi procesmi, ktoré najviac zaťažujú CPU:
Obe tabuľky vždy opisujú posledných 24 hodín, aj keď grafy ukazujú mesiac: snímku procesov nesú iba päťminútové riadky a tie sa neuchovávajú dlhšie ako deň.
ps, PHP skript zberu a reťaz cron/sudo nad ním) sa zo zoznamu vylučujú — inak by stáli na čele každej snímky: ps v okamihu spustenia ukazuje takmer 100 % CPU. Ostatné cron úlohy spustené v tej istej minúte sa naopak zobrazia — presne kvôli tomu tabuľka existuje.
Upozornenia na záťaž (sekcia „Nastavenia“ → „Upozornenia na záťaž“) — pri prekročení prahu pre CPU/RAM/disk/inody pošle panel upozornenie všetkými zapnutými kanálmi (Telegram, Email, webhook, push — tými istými ako denná správa; pre upozornenia netreba zapínať nič zvlášť) a ďalšie, len čo sa metrika vráti do normálu. Kým prah trvá, nespamuje: ďalšie upozornenie príde až po cykle „vrátilo sa do normálu → znova prekročené“.
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.
Denná správa odpovedá na otázku „ako sa serveru darí“. Senzor odpovedá na inú — „čo sa práve stalo“. Každých 5 minút sa spýta rýchlych zdrojov a zaznamená len to, čo sa od predchádzajúcej kontroly zmenilo; stránka „Bezpečnostné udalosti“ v ponuke zobrazuje zoznam nálezov.
Pomalých kontrol — Lynis, debsums, aktualizácie balíkov, platnosť SSL — sa senzor nedotýka: ich čísla sa aj tak menia raz denne a zostávajú v réžii dennej správy.
Čo si všíma — deväť zdrojov:
[Priority: 1] dvíha nález na kritický;FOUND v zázname kontroly;root (kritické) a prihlásenie z adresy, ktorá sa dosiaľ neobjavila (varovanie);Nástroj, ktorý nie je nainštalovaný alebo ktorého záznam panel neprečíta, jednoducho mlčí — to nie je chyba ani udalosť.
data/secwatch_state.json) a prvý priechod len túto značku zapíše. Inak by po zapnutí sledovania prišlo upozornenie na všetko, čo záznamy nazbierali za mesiace.
Nastavenie — „Nastavenia“ → „Sledovanie udalostí“:
23-7, počas ktorého sa varovania neodosielajú.Upozornenia chodia rovnakými kanálmi ako denná správa (Telegram, Email, webhook, push) — nič ďalšie zapínať netreba. Všetky nálezy sa zapisujú do zoznamu bez ohľadu na to, či upozornenie odišlo, a uchovávajú sa 90 dní.
Zoznam udalostí. Filtre: obdobie (24 hodín, 7, 30 alebo 90 dní), závažnosť a zdroj; zobrazuje sa posledných 500 záznamov. Tlačidlo „Skontrolovať teraz“ spustí presne ten istý priechod ako cron — hodí sa hneď po nastavení, aby ste nečakali päť minút; uvedie aj dôvod, keď žiadne upozornenie neodišlo („pod prahom závažnosti“, „tiché hodiny“, „nie je nastavený žiadny kanál upozornení“). Červené počítadlo pri položke ponuky je počet kritických udalostí za posledných 24 hodín.
Karta adresy. Kliknutie na riadok v zozname udalostí alebo v bloku Súvisiace adresy otvorí všetko, čo je o jednej adrese známe: časovú os jej udalostí, krajinu a na prvom riadku záver. Riadok zoznamu otvorí kartu, ak sa udalosť týka práve jednej adresy; ak ich uvádza viac, odkazmi sú samotné adresy v riadku. Závery sú štyri:
Pod časovou osou je blok Čo sa v tom istom čase dialo na serveri: udalosti, ktoré adresu vôbec nemajú. AIDE nevie, kto súbor zmenil, ClamAV nevie, kto priniesol nakazený. Zobrazené sú tie, ktoré spadajú do aktivity adresy a šiestich hodín po nej. Práve prihlásenie spolu s tým, čo nasledovalo, odlišuje pokus od skutočného prístupu.
Rozvrh. Úloha patrí do crontabu roota (sudo crontab -e), posunutá o 2 minúty oproti zberu metrík, aby obe neštartovali naraz:
php cron/security_watch.php. Wrapper nájde všetky inštalácie panela na serveri a spustí kontrolu v mene vlastníka webu — presne s tými právami sudo, ktoré panel používa z webu. Priame volanie z crontabu roota by vytvorilo stavový súbor data/secwatch_state.json vlastnený používateľom root a tlačidlo „Skontrolovať teraz“ by prestalo fungovať.
Stránka „Webový server“ rozoberá prístupový log a ukazuje, koľko bolo požiadaviek, aká časť skončila chybou a kto ich posielal. ModSecurity odpovedá na otázku „čo bolo zablokované“, táto stránka na otázku „čo vôbec na web prišlo“.
Čo je vidieť: počet požiadaviek, RPS, podiel chýb, samostatné počítadlo 5xx a objem odoslaných dát; graf požiadaviek po hodinách; rozloženie kódov 2xx/3xx/4xx/5xx; časté adresy, časté IP, časté chyby (kód plus cesta) a klienti (User-Agent). Obdobie: 24 hodín alebo 7 dní.
Zdrojom je prístupový log vo formáte combined, hodí sa teda Nginx aj Apache a žiadny ďalší modul nie je potrebný. Panel hľadá log medzi štandardnými súbormi:
/var/log/nginx/access.log/var/log/apache2/access.log/var/log/apache2/other_vhosts_access.log/var/log/httpd/access_logOkrem nich panel prehľadáva súbory *access*.log a *requests*.log v adresároch /var/log/nginx/, /var/log/apache2/ a /var/log/httpd/. Nájde sa tak aj log, ktorý web zapisuje do vlastného súboru direktívou CustomLog — napríklad arciveo-monitor_requests.log, ktorý vytvára inštalátor Arcivéo.
Číta sa len jeden log: keď Nginx stojí pred Apache, sčítanie dvoch logov by počítalo každú požiadavku dvakrát. Berie sa prvý log zo zoznamu vyššie, do ktorého sa zapisovalo za posledný deň (súbory nájdené podľa masky sa skúšajú po ňom, od najčerstvejších); ak sa za deň nezapisovalo do žiadneho, berie sa najčerstvejší neprázdny. Log vyprázdnený logrotate alebo zostávajúci po vypnutom webovom serveri preto nezakryje ten živý. Číta sa posledný úsek logu (3 MB) a výsledok sa ukladá do vyrovnávacej pamäte na 5 minút — na vyťaženom webe preto zvolené obdobie nemusí byť pokryté celé; skutočný záber je uvedený nad grafom.
adm a webový používateľ v nej nie je. Inštalátor Arcivéo ho do tejto skupiny pridá; po ručnej inštalácii pomôže malý wrapper od roota, ktorému je dovolená jediná vec — vypísať log (stránka ModSecurity funguje rovnako). Wrapper vyberá log podľa rovnakých pravidiel ako panel. Príkaz sa vypisuje priamo na stránke; tu je tiež. Vložte ho celý — ide o jediný príkaz:
Webový používateľ sa môže od www-data líšiť — overte, pod ktorým používateľom beží PHP-FPM pool webu (ps -o user= -C php-fpm), a doplňte ho do riadka sudoers. Ak názov logu neobsahuje ani access, ani requests, doplňte jeho cestu na začiatok riadka L=… vo vnútri wrappera.
Pokusy o známe exploity. Panel porovnáva požiadavky z logu so signatúrami približne dvadsiatich rozšírených exploitov: PHP-CGI, prechod adresármi v Apache, PHPUnit, Log4Shell, chyby routerov, kamier a VPN brán. Pri každom pokuse odpovie, či môže na tomto serveri fungovať, a opiera sa o fakty: nainštalované verzie Apache a PHP, prítomnosť Javy a kód, ktorým server odpovedal na požiadavku na súbor. Červenou je označené len to, čo naozaj môže fungovať.
Zabezpečenie webového servera. Panel sa dopytuje na každý web servera cez 127.0.0.1 a zisťuje, čo dostane návštevník: či je vidieť verziu webového servera a PHP, či je zapnutá metóda TRACE a či sú prítomné ochranné hlavičky Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy a Content-Security-Policy. Weby sa berú z adresy, na ktorej je panel otvorený, a zo súborov virtuálnych hostiteľov, ak ich panel môže čítať. Výsledok sa obnovuje každých 10 minút.
Ak niečo chýba, pod tabuľkou sa objaví jeden príkaz. Vytvorí samostatný súbor zz-arciveo-hardening.conf a webový server znova načíta až po úspešnom teste konfigurácie; hlavičky, ktoré web už posiela sám, sa nezdvojujú. CSP sa neponúka ako jeden riadok: pravidlá sa zostavujú pre konkrétny web, inak prestane načítavať vlastné skripty, štýly a písma. Vrátenie zmeny na Apache:
ServerSignature) sa neoznačuje, ak je verzia webového servera už skrytá: bez verzie ukazuje iba názov servera a názov hostiteľa.
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:
/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.
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.
127.0.0.1 (bind-address v konfigurácii MySQL/PostgreSQL, bind 127.0.0.1 v Redis) alebo zavrite port v UFW.
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ú.
/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“.
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.
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:
Aktualizácia na novú verziu. Najprv si urobte zálohu. Potom nahrajte súbory kódu znova a zachovajte svoje dáta:
public/, includes/, assets/, cron/, database/, ako aj koreňové .htaccess (front-controller — smerovanie sa nesmie ponechať zo starej verzie), manifest.json, sw.js;config.php (dáta DB), data/ (reporty), logs/, tmp/ (relácie a vyrovnávacia pamäť).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.
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.
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.
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:
config.php, data/.mysqldump na starom → import na novom; upravte dáta DB v config.php.adm, cron-úlohy.Panel už beží a na tom istom serveri je potrebná ešte jedna webová stránka — s vlastnou doménou vedľa monitora. Po automatickom nastavení je server bežný Apache + PHP-FPM, takže stránka potrebuje tri veci: vlastný adresár, vlastný vhost a vlastný certifikát. Panela sa pritom nedotýkame: sleduje celý server, druhá inštancia pre druhú doménu nie je potrebná.
site2.example.com je adresa novej stránky. Môže to byť samostatná doména (mycompany.com) aj subdoména (shop.mycompany.com) — pre Apache v tom nie je rozdiel, líšia sa len DNS záznam (krok 1) a vydanie certifikátu (krok 5). site2 je len krátky názov stránky: tak sa volajú adresár /var/www/site2 a konfiguračný súbor site2.conf. S doménou nijako nesúvisí, Apache berie adresu výhradne z ServerName; názov môže byť akýkoľvek — pre shop.mycompany.com sa napríklad hodí shop: adresár /var/www/shop, konfigurácia shop.conf.
1. DNS. V paneli DNS u registrátora domény vytvorte záznam A na IP tohto servera:
Po niekoľkých minútach overte: dig +short site2.example.com musí vrátiť IP servera.
2. Adresár stránky.
3. Vhost. Blok sa vkladá do terminálu celý — cesta k soketu PHP-FPM sa zistí sama:
4. Zapnite stránku a pred znovunačítaním overte konfiguráciu:
5. SSL. certbot už automatické nastavenie nainštalovalo; DNS musí v tejto chvíli smerovať na server:
Tretia a ďalšie domény sa pridávajú rovnako — zopakujte kroky 1–5 so zmenenou doménou a adresárom.
Host nezodpovedá žiadnemu ServerName (prístup cez IP alebo cudzia doména nasmerovaná na váš server), Apache vydá abecedne prvú zapnutú stránku z /etc/apache2/sites-enabled/. Štandardný 000-default automatické nastavenie vypína, takže túto „službu“ drží vhost panela (arciveo-monitor.conf) — na stránky otvárané pod vlastným menom to nemá vplyv. Ak sa má cez IP otvárať iná stránka, pomenujte jej súbor tak, aby bol abecedne prvý (napríklad 000-site2.conf).
site2_error.log a site2_access.log v /var/log/apache2/.
.htaccess (front controller) a vnorená stránka by vracala niečo iné, než očakávate. Držte stránky vedľa seba: /var/www/monitor, /var/www/site2.
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):
Stratený kľúč WebAuthn (neprejde druhý faktor) — vypnite 2FA, prihláste sa heslom a zaregistrujte nový kľúč:
Zabudnuté heslo — nastavte nový hash (vygenerujte ho na serveri a doplňte):
Zablokovali ste si prístup IP-filtrom — vypnite obmedzenie:
sudo mysql na serveri, prípadne phpMyAdmin / sekcia databázy v paneli hostingu. Po obnovení znova zapnite WebAuthn a IP-filter.
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.
sudo crontab -l a či je cron služba aktívna.
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:
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.
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ť;security-watch-all.sh → /usr/local/bin/ (chmod +x) — spúšťa cron/security_watch.php panela v mene vlastníka webu (stránka „Bezpečnostné udalosti“, riadok 2-57/5 v crontabe vyššie); security_watch.php je už súčasťou panela a netreba ho inštalovať zvlášť;fleet-push-all.sh → /usr/local/bin/ (chmod +x) — posiela prehľad servera do zákazníckeho účtu cez cron/fleet_push.php panela (riadok 3,18,33,48 vyššie);crontab.txt (system/cron/) — vzor úloh; potrebné riadky vpíšte cez sudo crontab -e./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:
/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.
/usr/local/bin/, log — /var/log/arciveo-cron.log) — ručne nemusíte robiť nič.
/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ú.
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:
stat -c %U /path/to/monitor.
sudo crontab -e), inak sa bude vykonávať dvakrát.
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:
www-data — skontrolujte, pod kým beží PHP-FPM pool webu (ps -o user= -C php-fpm), a doplňte ho do sudoers riadku.
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:
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í.
Chyba 500 — skontrolujte logy PHP, nginx a samotného monitora:
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 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).
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).
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).
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é.
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.
/etc/nginx/sites-enabled/, /etc/nginx/conf.d/) a Apache (/etc/apache2/sites-enabled/) plus aktuálny hostiteľ z HTTP_HOST.
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 panel nepoužíva: zoznam databáz získava cez svoje vlastné PDO-pripojenie.
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:
monitor-pgstat zo sudoers (krok 13 manuálnej inštalácie) a samotný skript nevytvárajte: karta PostgreSQL zostane jednoducho neaktívna.
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.
ignoreip./etc, mimo /usr/share) — potenciálna podvrhnutie. Overte balík: debsums PACKAGE_NAME, pri pochybnostiach ho preinštalujte (apt install --reinstall).127.0.0.1 alebo zatvorte port v UFW. To je reálna diera.certbot renew alebo nastavenia v paneli).sudo apt update && sudo apt upgrade; po aktualizácii jadra reštartujte server.