Toto je průvodce instalací, konfigurací a údržbou nástroje Arcivéo Security Monitor. Sekce jsou rozděleny do skupin: obecný přehled, nasazení panelu, připojení bezpečnostních nástrojů, vestavěné moduly a diagnostika. Příkazy lze kopírovat tlačítkem vpravo.
Instalace panelu je popsána na samostatných stránkách krok za krokem. Vyberte způsob:
Arcivéo Security Monitor — dashboard zabezpečení serveru. Sbírá data z nainstalovaných nástrojů (Fail2ban, UFW, Lynis, ModSecurity, AIDE, ClamAV, Auditd, CrowdSec, Suricata, Falco aj.) a zobrazuje je v jednotném rozhraní s dashboardem, mapou útoků a podrobnými stránkami ke každému nástroji.
Monitor není aktivní ochranný prostředek — sám o sobě útoky neblokuje. Jeho úkolem je agregovat informace z již běžících nástrojů a přehledně je zobrazit.
Monitor pracuje pouze lokálně — musí být nainstalován na stejném serveru, který sleduje. Žádné SSH ani vzdálené API neexistuje.
Všechny příkazy (fail2ban-client, ufw status, ipset list atd.) spouští panel pod uživatelem webového serveru (obvykle www-data, na hostingových panelech účet webu) s úzkou sadou práv sudo — jen pro konkrétní nástroje, bez obecného přístupu root. Výsledky se parsují a zobrazují v prohlížeči.
Dva rytmy práce. Stránky panelu se dotazují nástrojů ve chvíli otevření — vždy vidíte aktuální stav. Kromě toho běží na pozadí úlohy podle plánu (cron):
Úplný seznam úloh je v kapitole „Všechny cron úlohy na jednom místě“.
Skóre začíná na maximu a snižuje se za každý zjištěný problém:
PermitRootLogin yes) — −20PasswordAuthentication yes) — −10X11Forwarding, MaxAuthTries nad 3 nebo sshd_config čitelný pro všechny účty — −5TRACE nebo chybí hlavička Strict-Transport-Security či X-Frame-Options — −5Výsledek: 80+ = Zabezpečeno, 60–79 = Pozor, <60 = Ohroženo.
WebAuthn — standard ověření bez hesla pomocí hardwarového klíče. Podporuje YubiKey, Touch ID, Face ID, Windows Hello, Passkey.
Po přihlášení heslem systém vyžádá potvrzení pomocí zaregistrovaného klíče. I když heslo unikne — bez fyzického klíče nebo biometrie se nelze přihlásit.
Nastavení otevřete v postranní nabídce v sekci Klíče WebAuthn a klikněte na „Zaregistrovat klíč“. Zaregistrujte si rovnou dva klíče: pokud se jediný klíč ztratí nebo poškodí, přihlášení do panelu jím nebude možné.
Kanály jsou čtyři: Telegram, Email, webhook a push v prohlížeči. Jsou na sobě nezávislé — zapněte kterékoli, klidně všechny čtyři. Stejnými kanály chodí denní bezpečnostní zpráva, upozornění na zatížení i nálezy senzoru událostí; nastavují se jednou, zde, v sekci „Nastavení“.
Telegram. Potřebujete token bota a chat id:
@BotFather → /newbot → dostanete token ve tvaru 123456:ABC....@userinfobot, nebo otevřete https://api.telegram.org/bot<TOKEN>/getUpdates a najděte "chat":{"id":...}.Email. Na výběr jsou dva způsoby v „Nastavení“ → Email:
re_...) a ověřenou doménu odesílatele.Webhook. Jediná adresa přijímající POST pokryje Slack, Discord, Mattermost, n8n i vlastní obsluhu. „Nastavení“ → Webhook: vložte adresu a zapněte přepínač.
{"text": …}, do Discordu {"content": …} (Discord odmítá zprávy delší než 2000 znaků, text se proto zkracuje);text, event, severity, source, count, host, ts — text zprávy není nutné znovu rozebírat.Push oznámení. Zpráva přijde přímo do prohlížeče, a je-li panel přidaný na domovskou obrazovku telefonu, jako běžné oznámení aplikace — bez bota a bez poštovního serveru mezi tím. „Nastavení“ → Push oznámení: zapněte přepínač a na každém zařízení, které má oznámení dostávat, stiskněte „Připojit toto zařízení“. Počitadlo „Připojená zařízení“ ukazuje, kolik jich je.
Stav hlášení: „POZOR“ nebo „OK“. Nadpis se změní na „POZOR“ jen při skutečném problému nebo čekající akci: nalezena hrozba ClamAV, změny souborů v AIDE, kritické události Falco (Emergency/Alert/Critical za posledních 24 h), spadlá služba v Monit, je nutný restart, vyprší SSL (≤14 dní) nebo čekají bezpečnostní aktualizace. Provozní šum — SSH pokusy o prolomení od botů, IP zabanované fail2ban, alerty Suricata, varování Lynis a už odražené požadavky ModSecurity — stav nezvyšuje, takže tato čísla v hlášení sama o sobě neznamenají „POZOR“.
Podrobné moduly monitoringu (Lynis, UFW, ModSecurity, mapa útoků, AIDE, ClamAV aj.) se otevřou, pokud máte platnou licenci. Bez ní fungují dashboard, nastavení a účet, ale moduly zobrazují kartu „Vyžadována licence“.
Po nákupu v účtu máte aktivační kód ve tvaru ARCIVEO-XXXX-XXXX-XXXX-XXXX. Ten je potřeba „aktivovat“ na doménu vašeho panelu — tím se kód promění v podepsaný licenční soubor (blok [license]), který vložíte do panelu.
Jak aktivovat (3 kroky):
my.arciveo.com → sekce „Licence“ / „Aktivace licence“ — zkopírujte kód ARCIVEO-….monitor.example.com). Klikněte na aktivovat — systém vygeneruje licenční soubor navázaný na tuto doménu a zobrazí jej v poli s tlačítkem „Kopírovat“.Panel klíč kryptograficky ověřuje: podpis, navázání na doménu a dobu platnosti.
APP_URL v config.php a zadejte pouze název hostitele — bez https:// a bez prefixu www. Aktivace je jednorázová: kód se promění v licenci pro zadanou doménu a znovu se neaktivuje — při chybě v doméně klíč vašemu panelu nebude odpovídat a kód bude spotřebován. Doménu proto zadávejte pozorně.
Všechny základní parametry panelu jsou uvedeny v jednom souboru config.php v kořenovém adresáři (vedle složky public/) jako běžné konstanty define(). Soubor se vytvoří při instalaci; upravovat ho ručně je potřeba jen zřídka — hlavně při změně domény, přenosu nebo připojení k jiné databázi. Po každé úpravě restartujte PHP-FPM (jinak se kvůli OPcache změny neuplatní).
Do zvýrazněných míst doplňte své hodnoty; zbytek nechte tak, jak je:
Databáze. Údaje pro připojení k MySQL/MariaDB:
DB_HOST — hostitel databáze, téměř vždy localhost;DB_NAME — název databáze panelu;DB_USER — uživatel DB (přístup jen k vlastní databázi);DB_PASS — heslo tohoto uživatele;DB_CHARSET — kódování připojení, ponechte utf8mb4.Aplikace.
APP_URL — úplná adresa panelu (např. https://monitor.example.com). Musí se shodovat s doménou, na kterou je licence aktivovaná — jinak bude klíč odmítnut (viz oddíl „Licence“);TIMEZONE — časové pásmo PHP: ovlivňuje pouze to, jak panel zobrazuje datum a čas. Na dobu spuštění úloh cron nemá vliv — tam platí pásmo systému (viz „Všechny úlohy cron“).Doba platnosti relace. SESSION_LIFETIME — časový limit nečinnosti relace v sekundách (plovoucí: obnovuje se při aktivitě). Výchozí hodnota 28800 = 8 hodin; po této době nečinnosti panel vyzve k opětovnému přihlášení. Například 3600 = 1 hodina, 86400 = den.
Protokolování chyb. Chyby se návštěvníkům nikdy nezobrazují, ale zapisují se do logs/php_errors.log — jsou vidět na stránce „Protokoly aplikace“. Tyto řádky (display_errors=0, log_errors=1, cesta error_log) obvykle není potřeba měnit — nastavení je zadáno přímo v souboru a nezávisí na php.ini.
public/) a webový kořen (DocumentRoot) tohoto panelu je právě kořen panelu, nikoli public/. Samotný soubor „neuniká“: v kořenovém .htaccess je pro něj nastaven výslovný zákaz (Require all denied) — server vrací 403. I bez tohoto pravidla by zdrojový kód neunikl: je to PHP — server ho vykonává, nevrací jako text. Pro jistotu: nezveřejňujte ho ve veřejných repozitářích a neposílejte ho podpoře se skutečným heslem. Oprávnění souboru — 640.
Panel je chráněn přihlášením heslem a, pokud je zapnutý, IP filtrem. Programu nevyhovuje ani jedno, proto mají externí systémy vlastní vstup — dvě adresy pouze pro čtení zabezpečené tokenem. Token na serveru nic nemění: dá se jím pouze získat ukazatele.
Zapnutí — „Nastavení“ → „API pouze pro čtení“: přepínač „Zapnout API“; token se vytvoří automaticky při prvním uložení. Tlačítko „Nový token“ vydá jiný a v tutéž chvíli odstřihne všechny, kdo používali předchozí.
/api/status.php — JSON: bezpečnostní skóre, stav modulů, poslední měření zatížení včetně nejnáročnějších procesů a bezpečnostní události za posledních 24 hodin;/api/metrics.php — táž čísla v textovém formátu Prometheus (metriky arciveo_*: arciveo_security_score, arciveo_fail2ban_banned, arciveo_cpu_busy_pct a další).Pokud váš klient neumí nastavit hlavičku, token se přijímá i jako parametr — ?token=…. Počítejte s tím, že v této podobě skončí v přístupovém logu webového serveru, hlavička je proto vhodnější.
Prometheus. Hotový blok pro scrape_configs:
api disabled — API je v nastavení vypnuté. Odmítnuté požadavky se zapisují do protokolu aplikace spolu s IP odesílatele, takže hádání tokenu je vidět na stránce „Protokoly aplikace“.
Panel se instaluje na každý server zvlášť a na otázku „jak se daří tomuto stroji“ odpovídá dobře. Na otázku „jak se daří všem mým strojům“ neodpovídá — proto může každý panel posílat krátký přehled do zákaznického účtu, kde jsou servery vidět v jednom seznamu.
Co si vzít v zákaznickém účtu my.arciveo.com → sekce „Moje servery“: vydává se tam token (ve tvaru fk_…) a je uvedena adresa příjemce https://my.arciveo.com/api/fleet.php. Token je jeden na účet — stejný pro všechny vaše servery.
Co nastavit v panelu — „Nastavení“ → „Přehled serverů“: adresa příjemce, token, název serveru (jak bude v seznamu podepsán; necháte-li prázdné, vezme se doména panelu) a přepínač „Posílat přehled“. Tlačítko „Odeslat nyní“ ověří spojení okamžitě, bez čekání na plán.
Dál přehled odchází cronem, každých 15 minut:
Co přesně odchází: název a doména serveru, operační systém, doba běhu, verze PHP; bezpečnostní skóre; stav modulů (UFW, počet jailů Fail2ban, bany za dnešek, zda běží CrowdSec, Suricata a Falco, hrozby ClamAV, změny AIDE, index Lynis, čekající aktualizace, zda je nutný restart, dny do vypršení certifikátu, počet nebezpečně otevřených portů); poslední měření zatížení (load, CPU, RAM, disk, inody); počitadla událostí za posledních 24 hodin a poslední kritická událost. Protokoly, hesla ani obsah souborů přehled neobsahuje.
sudo crontab -l) a co odpoví tlačítko „Odeslat nyní“. Chyby odesílání se zapisují do protokolu aplikace se značkou FLEET — tam je vidět, zda byl odmítnut token (HTTP 401), nebo zda vůbec nevzniklo spojení.
UFW (Uncomplicated Firewall) — jednoduché rozhraní k nftables/iptables. Uzavře všechny příchozí porty kromě výslovně povolených. Stránka „Firewall UFW“ zobrazuje stav a pravidla.
ufw enable nezapomeňte povolit SSH (ufw allow OpenSSH), jinak přijdete o přístup k serveru.
deny se nepovažuje za dostupný zvenčí.
Skipping adding existing rule — to není chyba. UFW tím oznamuje, že přesně takové pravidlo už existuje, a znovu ho nepřidává. Při opakovaném spuštění automatického nastavení (je idempotentní) jde o běžné hlášení — není třeba na ně reagovat.
Automaticky blokuje IP adresu po překročení počtu neúspěšných pokusů o přihlášení. Analyzuje logy SSH, nginx, Apache a dalších služeb.
Základní instalace je výše. Zde je funkční konfigurace, která dává desítky aktivních jailů a tisíce blokování: obecné nastavení, klíčové jaily a automatický ban škodlivých IP ze seznamu ipsum.
Soubor /etc/fail2ban/jail.local — obecné nastavení a nejdůležitější jaily:
ignoreip nezapomeňte zapsat svou IP a důvěryhodné sítě, jinak si můžete zablokovat sám sebe. Po úpravách: sudo fail2ban-client reload.
Automatické načítání blok-listu ipsum — do root cronu (sudo crontab -e): level 1 (100+ tisíc IP) se načítá do sady ipsum, která se odřezává na firewallu (podrobněji v sekci „Blok-list IPset“):
ipsum — právě ji čte dashboard (karta „IPset ipsum“). Úrovně: levels/1.txt — maximální pokrytí, levels/3.txt — přesnější (3+ zdroje).
Proč je „Monitor bezpečnosti“ rozdělen do dvou zón. Ochrana funguje na dvou úrovních a dashboard je nemíchá:
sshd, apache-*, nginx-* apod.) a zlomyslní recidivisté (jail recidive — ti, kdo už byli několikrát zabanováni). Jsou to IP, které se k vám skutečně dobývaly — jsou na mapě útoků a na „Časové ose“.ipset ipsum, odřezávaný na firewallu pravidlem DROP. Tyto adresy se vašeho serveru z větší části ani nedotkly — jsou odříznuty předem; počítadlo „IPset ipsum“ ukazuje, kolik jich bylo preventivně odříznuto.Rozdíl je jednoduchý: reaktivní — „tito zaútočili a dostali ban“, preventivní — „tito byli zablokováni ještě před pokusem“. Dříve se do recidive uměle nahnal list-3 ipsum (odtud staré dělení „seznamoví recidivisté“); nyní jsou v recidive jen skuteční recidivisté a prevence je celá na firewallu.
ipsum — veřejný seznam škodlivých IP, aktualizovaný denně. Monitor zobrazuje počet načtených adres na dashboardu a mapě útoků a zohledňuje jej ve Skóre bezpečnosti (−10, pokud sada není načtena).
Minimální varianta bez fail2ban — samostatná sada ipsum s blokováním přes iptables:
@reboot. Zároveň příkaz create … -exist nastaví limit maxelem 300000 (výchozích 65536 — level 1 se nevejde, objeví se „Hash is full“):
ipsum a pokud firewall spravuje instalátor (čistý VPS — profily „Plná“/„Odlehčená“), připojí sadu k UFW pravidlem DROP — provoz z těchto IP se reálně blokuje. Pravidlo je za ESTABLISHED,RELATED, takže stávající spojení (včetně vašeho SSH) se nepřeruší — blokují se jen nová připojení ze seznamu. Sada se obnovuje při spuštění služby ipsum-load.service před firewallem (jinak by se UFW nezvedl) a aktualizuje se cronem ve 04:00. Na již nakonfigurovaném serveru (panel, vlastní firewall) instalátor do firewallu nezasahuje — tam ipsum zůstává seznamem pro dashboard a mapu útoků a pravidlo DROP se v případě potřeby přidá ručně (minimální varianta s iptables … --match-set ipsum … -j DROP — výše). Při automatické instalaci není třeba nic dělat ručně.
Moderní náhrada Fail2ban s kolektivní threat intelligence: bany od komunity plus vlastní pravidla. Pro aplikaci banů na firewall vyžaduje samostatný bouncer.
systemctl is-active crowdsec). Spuštění: sudo systemctl enable --now crowdsec; při pádu se podívejte na sudo journalctl -u crowdsec -n 30. Totéž platí pro jakoukoli službu ve stavu „Neběží“ (Suricata, Falco, Monit, MySQL).
stream halted / bany se neaplikují. Jde o osiřelý api-klíč: bouncer byl odstraněn z cscli bouncers list, ale jeho starý klíč zůstal v /etc/crowdsec/bouncers/*.yaml. Zaregistrujte bouncer znovu a zapište čerstvý klíč:
AIDE (Advanced Intrusion Detection Environment) vytvoří snímek souborového systému a při každé kontrole hlásí změny v /etc, /bin, /usr. Po instalaci je nutná inicializace databáze (aideinit).
aideinit terminál 5–15 minut stojí na řádku Running aide --init... — to je normální (hashování celého FS, zátěž disku). Nepřerušujte Ctrl+C. Pokud proces „visí“, ale nic nevypisuje — možná čeká na odpověď na skrytý dotaz Overwrite existing aide.db.new [Yn]? (stiskněte Y). Aktivitu ověříte z jiné relace: pgrep -af aide.
aideinit: „21_aide_spamassassin … printf: invalid number“ (return code 20) — známý bug konfiguračního snippetu AIDE v Ubuntu 22.04. Databáze se nevytvoří. Vyřaďte poškozený snippet a zopakujte:
aideinit nespustil, nebo (Ubuntu 24.04) je adresář /var/lib/aide vytvořen v režimu 700 a nedostupný pro www-data — vyřeší sudo chmod 755 /var/lib/aide (viz blok výše). „Bez kontrol“ = databáze existuje, ale kontrola ještě neproběhla — to není chyba. Výsledky čte monitor z /var/log/aide/aide.log.
/etc/cron.daily/aide na nových Ubuntu/Debian nemusí zapisovat /var/log/aide/aide.log v požadované podobě (a aide.wrapper v nich už není). Spolehlivější je přidat vlastní cron s explicitním --config — ten zapisuje log pod rootem v režimu 644 a monitor jej čte bez dalších skupin:
chmod 755 /var/lib/aide a cron kontroly ve 02:00 — ručně není potřeba nic.
sudo aideinit && sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db.
Antivirový skener pro Linux. Zvlášť užitečný pro kontrolu /var/www na PHP shelly a škodlivý kód.
enable --now? Tři typické příčiny:
1. V konfiguraci zůstal řádek Example — clamd se odmítá spustit, dokud tam je:
2. Není stažena databáze signatur — clamd se bez ní nespustí:
3. Prostě se načítá — clamd nahrává ~8 mil. signatur do paměti 30–60 s. Počkejte a zkontrolujte: systemctl is-active clamav-daemon (stav activating → ještě nahrává).
sudo journalctl -u clamav-daemon -n 30 --no-pager.
clamd jen drží signatury v paměti, sám podle plánu nic neskenuje. Panel zobrazuje výsledky plánované kontroly, proto je potřeba cron, který skenuje a zapisuje log. Automatická instalace nasadí wrapper /usr/local/bin/clamav-scan.sh a cron v 01:30 — po prvním spuštění se doplní „Zkontrolováno souborů“ a „Poslední kontrola“. Spustit hned, bez čekání na plán: sudo /usr/local/bin/clamav-scan.sh.
Linux Malware Detect (LMD) — skener škodlivého softwaru zaměřený na webové hrozby: PHP shelly, webové backdoory, downloadery. Využívá jádro ClamAV a doplňuje jej vlastními signaturami.
maldet --report.
update-rc.d: error: unable to read /etc/init.d/maldet — je neškodný. maldet nepoužívá init.d, aktualizace signatur a skeny se spouští přes /etc/cron.daily/maldet. Pokud níže vidíte installation completed — vše se nainstalovalo.
apt, ale do /usr/local/maldetect, a při zapnutém open_basedir se jeho přítomnost ověřuje přes shell — viz sekce „Stránka je prázdná, i když data na serveru jsou“.
Síťový systém detekce průniků: analyzuje provoz na úrovni paketů a zná tisíce signatur útoků. Doplňuje ModSecurity (ten pracuje na úrovni HTTP, Suricata na úrovni TCP/IP).
/var/log/suricata/eve.json pod uživatelem root v režimu 750 na adresář a webový server (www-data) jej nemůže přečíst. Otevřete adresář pro průchod — soubory uvnitř zůstávají chráněné:
Zachytává systémová volání přes eBPF/kernel module a odhaluje anomálie v reálném čase: shell z nginx, čtení /etc/passwd webovým procesem, zápis do /bin atd.
journalctl -u falco (bez sudo — přes skupinu systemd-journal). Ujistěte se, že www-data je v této skupině — viz „Nastavení sudo“ (bod 2) na stránce ruční instalace.
/etc/passwd, zápis do systémových adresářů). Nula kritických událostí za den na klidném serveru je zdravý stav.
journalctl vyžaduje oprávnění k žurnálu; aby panel viděl události stabilně, automatická instalace zapíná u Falco file_output → /var/log/falco/falco.log a službě nastavuje UMask=0022 (log čte webový server). Při nové instalaci to není třeba nastavovat ručně.
ModSecurity — webový firewall (WAF) pro Apache nebo Nginx. Blokuje útoky na úrovni aplikace: SQL injection, XSS, průchod adresáři, skenery.
IncludeOptional /etc/modsecurity/*.conf, ale balíček dodává jen modsecurity.conf-recommended — pod masku *.conf nespadá. Pokud ho nezkopírujete do modsecurity.conf, zůstává SecRuleEngine na Off: modul je načtený, pravidla CRS jsou načtená, ale provoz se nekontroluje a audit log se nevytváří. Přechodný režim DetectionOnly pouze zapisuje události do logu, aniž by požadavky blokoval — panel ho zobrazuje žlutě.
Přístup panelu k audit logu. Log /var/log/apache2/modsec_audit.log patří rootovi (práva 640), webový uživatel jej nepřečte. Panel získává data přes obalovací skript — vytvořte jej:
SecRuleEngine bez odsazení: odsazené řádky jsou uvnitř bloků <LocationMatch>/<Directory> (například vypnutí WAF pro phpMyAdmin) a globální režim neurčují.www-data, v HestiaCP běží pool webu pod vlastníkem webu (například admin) — zkontrolujte grep -E '^user' /etc/php/*/fpm/pool.d/monitor.example.com.conf.X-Forwarded-For. Do statistik se dostanou jen transakce s uplatněným pravidlem: direktiva SecAuditLogRelevantStatus zapisuje do audit logu jakékoli odpovědi 4xx/5xx, takže se tam dostanou i běžné 403/500 — panel je za události WAF nepovažuje.---RULES--- potřebuje sekce „Všechna aktivní pravidla“ — panel zobrazuje nejen uplatněná, ale vůbec všechna načtená pravidla CRS + vlastní. Tři cesty v cyklu for f in … jsou typická místa pro pravidla CRS a lokální doplňky; pokud máte jiné rozložení (balíček ukládá soubory do svého adresáře, nebo vlastní pravidla neleží v /etc/modsecurity/custom-rules.conf), najděte reálné cesty příkazem sudo grep -rl 'IncludeOptional\|^Include ' /etc/apache2/mods-enabled/security2.conf /etc/apache2/conf-enabled/*.conf 2>/dev/null a doplňte je do seznamu. Pokud je obalovací skript starý (bez této sekce) — sekce jen zobrazí varování „nedostupné“, zbytek stránky funguje jako dříve.
Auditd (Linux Audit Daemon) zaznamenává systémová volání na úrovni jádra: přihlášení a odhlášení, sudo příkazy, neúspěšné pokusy o autentizaci, změny souborů. Monitor zobrazuje dnešní přihlášení, neúspěšné pokusy a sudo příkazy.
ausearch (/usr/sbin/ausearch) a v případě potřeby ze souboru /var/log/audit/audit.log příkazem tail. Oba musí být v sudoers.
Sleduje služby (nginx, php-fpm, mysql atd.) a při jejich pádu je restartuje. Umí posílat upozornění na e-mail.
monit status. V souboru /etc/monit/monitrc musí být zapnuté HTTP rozhraní (blok set httpd s allow localhost), jinak monit status vrátí chybu.
monitrc je řádek set httpd zakomentovaný (výchozí podoba je # set httpd port 2812 …). Odkomentujte blok a povolte localhost. (2) Samotné zapnuté httpd nic nesleduje — Monit počítá jen to, co je popsáno v check stanzách; bez nich je seznam prázdný i při funkčním rozhraní. Minimální funkční konfigurace:
conf.d s httpd na portu 2812 a sadou kontrol — na nové instalaci není potřeba nic nastavovat ručně.
PSAD analyzuje protokol iptables a odhaluje skenování portů a síťové útoky, přičemž každému zdroji přiřadí úroveň hrozby (1–5). Doplňuje fail2ban a Suricata.
psad --Status (musí být v sudoers). Bez logování iptables bude stránka prázdná — to je normální, dokud neproběhlo žádné skenování.
Mandatory Access Control omezuje, k jakým souborům a prostředkům může program přistupovat, i když byl napaden. V Ubuntu/Debian se ve výchozím nastavení používá AppArmor (obvykle je již nainstalován a aktivní).
aa-status (musí být v sudoers). Zobrazuje počet profilů v režimu enforce/complain a procesy bez profilu.
„Načtených profilů“ je více než enforce + complain — to je v pořádku. V AppArmor 4.x (Ubuntu 24.04 a novější) přibyl režim unconfined: profil je načten v jádře, ale nic neomezuje. Ubuntu takto označuje desítky profilů pro programy využívající user namespaces (prohlížeče, torrentové klienty a podobně). Když takové profily existují, karta „Načtených profilů“ zežloutne a zobrazí jejich počet — například unconfined: 90 při 120 načtených a 26 v enforce. Reálně chrání jen profily v enforce; na Ubuntu 22.04 (AppArmor 3.x) tento režim není a čísla vždy sedí.
unconfined, se vyplatí jen s rozmyslem: nejsou vypnuté omylem, ale proto, že jinak se naruší fungování samotných programů. Profily v complain jsou jiná věc: tam jsou pravidla už napsaná a jen se neuplatňují.
debsums ověřuje, že soubory nainstalovaných balíčků odpovídají kontrolním součtům z repozitáře — odhalí podvržené systémové binárky (doplňuje AIDE). Úplná kontrola trvá 1–2 minuty, proto se spouští přes cron a panel čte výsledek z data/debsums/debsums.log a sám jej rozdělí do kategorií (podstatné jsou jen binárky a knihovny).
Úloha patří do root-cronu (sudo crontab -e). Hotový obal debsums-scan.sh se umístí do /usr/local/bin/ (chmod +x; viz přehled cron-úloh) a sám zapíše zprávu do data/debsums/ panelu.
Obal debsums-scan.sh si sám najde data/ panelu — cestu není třeba zadávat.
/etc/ (konfigurace) a /usr/share/ (zdroje) na serveru bývají obvykle v pořádku — panel je označí zvláštní barvou. Znepokojivé jsou změny binárek a knihoven (/bin, /sbin, /usr/lib apod.) — karta „Binárky / knihovny“ ukazuje právě je.
Lynis se spouští ručně nebo přes cron. Report se musí ukládat do složky data/lynis/ projektu — monitor čte soubor lynis-report.dat.
lynis-scan.sh na pozadí přímo z panelu (bez čekání na cron): zobrazí „Skenování…“ a po dokončení samo aktualizuje report. K tomu potřebuje webový uživatel řádek v sudoers pro spuštění skriptu — instalátor jej přidá automaticky do /etc/sudoers.d/monitor. Pokud jste panel instalovali ručně/dříve, dopište jej týmž uživatelem, který už je v souboru uveden:
Logwatch musí ukládat denní reporty do složky data/logwatch/ projektu ve formátu .txt. Monitor zobrazuje poslední report a archiv.
Síťový monitor nevyžaduje instalaci — je to vestavěná stránka panelu. Zobrazuje síťový stav serveru z lokálních zdrojů:
/proc/net/dev;ip;ss;journalctl -k.První tři zdroje fungují bez sudo, takže rozhraní, provoz, spojení a porty jsou vidět ihned. Blok „Události jádra“ používá journalctl -k — čte se přes skupinu systemd-journal („Nastavení sudo“, bod 2), sudo není potřeba. Ověření, že vše je dostupné webovému uživateli:
UFW BLOCK sem nepatří — jsou na stránkách „Brána firewall UFW“ a „Mapa útoků“. Prázdný blok se zeleným zaškrtnutím = za posledních 24 h nedošlo k žádnému síťovému výpadku.
Vestavěná stránka zobrazuje tři věci:
df); ukazatel zčervená při ≥90 %;lsblk), pouze reálné (loop/snap jsou skryté);smartctl).Místo a seznam zařízení fungují ihned, bez nastavení. Pro SMART je potřeba balíček smartmontools. Webový proces nemá přímý přístup k diskovým zařízením, proto se SMART snímá přes cron do souboru data/disk/smart.txt a dashboard jej čte.
Úloha patří do root-cronu (sudo crontab -e). Hotový wrapper smart-scan.sh se umístí do /usr/local/bin/ (chmod +x; viz přehled cron-úloh) a sám zapisuje do data/disk/ dashboardu.
Wrapper smart-scan.sh si sám najde data/ dashboardu — cestu není nutné zadávat. Uvnitř lsblk -e7,11 vylučuje loop/cdrom.
Stránka zobrazuje historii zatížení serveru za posledních 24 hodin — Load Average, vytížení CPU a čekání na I/O, RAM/Swap, síťový provoz (příjem/odesílání), diskové I/O (čtení/zápis), zaplnění disku a inodů, otevřené souborové deskriptory a MySQL připojení, plus aktuální počet TCP připojení a procesů. Výchozí je okno 24 hodin: tlačítka nahoře je přepnou na 7 dnů nebo 30 dnů.
Data sbírá cron/collect_metrics.php — jednou za 5 minut zapíše jeden „surový“ snímek čítačů (/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 tabulky DB system_metrics; procenta a rychlosti si stránka počítá sama z rozdílu mezi sousedními snímky (zaplnění disku/inodů/deskriptorů/MySQL připojení jsou okamžité hodnoty, bez přepočtu). Sudo není potřeba — zdroje se čtou bez práv roota.
Dvě hloubky uchovávání. „Surové“ pětiminutové snímky žijí jeden den (plus hodina rezervy, aby nejstarší bod grafu měl ještě předchůdce pro výpočet). Každá dokončená hodina se složí do jediného řádku; tato hodinová řada se uchovává 30 dnů a právě ji čtou pohledy „7 dnů“ a „30 dnů“. Měsíc historie tak stojí zhruba 720 řádků místo přibližně 8600.
Obal collect-metrics-all.sh (viz přehled cron úloh) sám najde všechny nainstalované instance panelu na serveru a spustí cron/collect_metrics.php každé z nich jménem vlastníka webu.
Nejnáročnější procesy. Pod grafy jsou dvě tabulky s pěti procesy, které nejvíce vytěžují CPU:
Obě tabulky vždy popisují posledních 24 hodin, i když grafy ukazují měsíc: snímek procesů nesou pouze pětiminutové řádky a ty se neuchovávají déle než den.
ps, PHP skript sběru a řetěz cron/sudo nad ním) se ze seznamu vylučují — jinak by stály v čele každého snímku: ps ve chvíli spuštění ukazuje téměř 100 % CPU. Ostatní cron úlohy spuštěné ve stejnou minutu se naopak objeví — přesně kvůli tomu tabulka existuje.
Upozornění na zatížení (sekce „Nastavení“ → „Upozornění na zatížení“) — při překročení prahu pro CPU/RAM/disk/inody pošle panel oznámení všemi zapnutými kanály (Telegram, Email, webhook, push — stejnými jako u denní zprávy; pro upozornění není třeba zapínat nic zvlášť) a další, jakmile se metrika vrátí do normálu. Dokud práh trvá, nespamuje: další oznámení přijde až po cyklu „vrátilo se do normálu → znovu překročeno“.
collect_metrics.php při každém spuštění (jednou za 5 minut) — samostatný cron není potřeba. Stav „již upozorněno / ještě ne“ se ukládá do data/alerts_state.json, prahy — v nastavení panelu.
Denní zpráva odpovídá na otázku „jak se serveru daří“. Senzor odpovídá na jinou — „co se právě stalo“. Každých 5 minut se dotáže rychlých zdrojů a zaznamená jen to, co se od předchozí kontroly změnilo; stránka „Bezpečnostní události“ v nabídce zobrazuje seznam nálezů.
Pomalých kontrol — Lynis, debsums, aktualizace balíčků, platnost SSL — se senzor nedotýká: jejich čísla se stejně mění jednou denně a zůstávají v gesci denní zprávy.
Čeho si všímá — devět zdrojů:
[Priority: 1] zvedá nález na kritický;FOUND v protokolu kontroly;root (kritické) a přihlášení z adresy, která se dosud neobjevila (varování);Nástroj, který není nainstalovaný nebo jehož protokol panel nepřečte, prostě mlčí — to není chyba ani událost.
data/secwatch_state.json) a první průchod jen tuto značku zapíše. Jinak by po zapnutí sledování přišlo oznámení o všem, co protokoly nasbíraly za měsíce.
Nastavení — „Nastavení“ → „Sledování událostí“:
23-7, kdy se varování neodesílají.Oznámení chodí stejnými kanály jako denní zpráva (Telegram, Email, webhook, push) — nic dalšího zapínat netřeba. Všechny nálezy se zapisují do seznamu bez ohledu na to, zda oznámení odešlo, a uchovávají se 90 dnů.
Seznam událostí. Filtry: období (24 hodin, 7, 30 nebo 90 dnů), závažnost a zdroj; zobrazuje se posledních 500 záznamů. Tlačítko „Zkontrolovat nyní“ spustí přesně tentýž průchod jako cron — hodí se hned po nastavení, abyste nečekali pět minut; uvede také důvod, když žádné oznámení neodešlo („pod prahem závažnosti“, „tiché hodiny“, „není nastaven žádný kanál oznámení“). Červené počitadlo u položky nabídky je počet kritických událostí za posledních 24 hodin.
Karta adresy. Kliknutí na řádek v seznamu událostí nebo v bloku Související adresy otevře vše, co je o jedné adrese známo: časovou osu jejích událostí, zemi a na prvním řádku závěr. Řádek seznamu otevře kartu, pokud se událost týká právě jedné adresy; je-li jich více, odkazem jsou samotné adresy uvnitř řádku. Závěry jsou čtyři:
Pod časovou osou je blok Co se ve stejnou dobu dělo na serveru: události, které adresu vůbec nemají. AIDE neví, kdo soubor změnil, ClamAV neví, kdo přinesl nakažený. Zobrazeny jsou ty, které spadají do aktivity adresy a šesti hodin po ní. Právě spojení přihlášení s tím, co následovalo, odlišuje pokus od skutečného přístupu.
Plán. Úloha patří do crontabu roota (sudo crontab -e), posunutá o 2 minuty oproti sběru metrik, aby obě nestartovaly zároveň:
php cron/security_watch.php. Wrapper najde všechny instalace panelu na serveru a spustí kontrolu jménem vlastníka webu — s přesně těmi právy sudo, která panel používá z webu. Přímé volání z crontabu roota by vytvořilo stavový soubor data/secwatch_state.json vlastněný root a tlačítko „Zkontrolovat nyní“ by přestalo fungovat.
Stránka „Webový server“ rozebírá přístupový log a ukazuje, kolik bylo požadavků, jaká část skončila chybou a kdo je posílal. ModSecurity odpovídá na otázku „co bylo zablokováno“, tato stránka na otázku „co vůbec na web přišlo“.
Co je vidět: počet požadavků, RPS, podíl chyb, samostatné počitadlo 5xx a objem odeslaných dat; graf požadavků po hodinách; rozložení kódů 2xx/3xx/4xx/5xx; časté adresy, časté IP, časté chyby (kód plus cesta) a klienty (User-Agent). Období: 24 hodin nebo 7 dnů.
Zdrojem je přístupový log ve formátu combined, hodí se tedy jak Nginx, tak Apache a žádný další modul není potřeba. Panel hledá log mezi standardními soubory:
/var/log/nginx/access.log/var/log/apache2/access.log/var/log/apache2/other_vhosts_access.log/var/log/httpd/access_logKromě nich panel prohledává soubory *access*.log a *requests*.log v adresářích /var/log/nginx/, /var/log/apache2/ a /var/log/httpd/. Najde se tak i log, který web zapisuje do vlastního souboru direktivou CustomLog — například arciveo-monitor_requests.log, který vytváří instalátor Arcivéo.
Čte se jen jeden log: když Nginx stojí před Apache, sečtení dvou logů by počítalo každý požadavek dvakrát. Bere se první log ze seznamu výše, do kterého se zapisovalo za poslední den (soubory nalezené podle masky se zkoušejí po něm, od nejčerstvějších); pokud se za den nezapisovalo do žádného, bere se nejčerstvější neprázdný. Log vyprázdněný logrotate nebo zbylý po vypnutém webovém serveru proto nezakryje ten živý. Čte se poslední úsek logu (3 MB) a výsledek se ukládá do cache na 5 minut — na vytíženém webu proto zvolené období nemusí být pokryté celé; skutečný záběr je uveden nad grafem.
adm a webový uživatel v ní není. Instalátor Arcivéo jej do této skupiny přidá; po ruční instalaci pomůže malý wrapper od roota, kterému je dovolena jediná věc — vypsat log (stránka ModSecurity funguje stejně). Wrapper vybírá log podle stejných pravidel jako panel. Příkaz se vypisuje přímo na stránce; zde je také. Vložte jej celý — jde o jediný příkaz:
Webový uživatel se může od www-data lišit — ověřte, pod kterým uživatelem běží PHP-FPM pool webu (ps -o user= -C php-fpm), a doplňte jej do řádku sudoers. Pokud název logu neobsahuje ani access, ani requests, doplňte jeho cestu na začátek řádku L=… uvnitř wrapperu.
Pokusy o známé exploity. Panel porovnává požadavky z logu se signaturami zhruba dvaceti rozšířených exploitů: PHP-CGI, průchod adresáři v Apache, PHPUnit, Log4Shell, chyby routerů, kamer a VPN bran. U každého pokusu odpoví, zda může na tomto serveru fungovat, a opírá se o fakta: nainstalované verze Apache a PHP, přítomnost Javy a kód, kterým server odpověděl na dotaz na soubor. Červeně je označeno jen to, co skutečně může fungovat.
Zabezpečení webového serveru. Panel se dotáže každého webu na serveru přes 127.0.0.1 a zjistí, co dostane návštěvník: zda je vidět verze webového serveru a PHP, zda je zapnutá metoda TRACE a zda jsou k dispozici ochranné hlavičky Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy a Content-Security-Policy. Weby se berou z adresy, na které je panel otevřen, a ze souborů virtuálních hostitelů, pokud je panel může číst. Výsledek se obnovuje každých 10 minut.
Pokud něco chybí, pod tabulkou se objeví jeden příkaz. Vytvoří samostatný soubor zz-arciveo-hardening.conf a webový server znovu načte až po úspěšném testu konfigurace; hlavičky, které web už posílá sám, se nezdvojují. CSP se nenabízí jako jeden řádek: zásady se sestavují pro konkrétní web, jinak přestane načítat vlastní skripty, styly a písma. Vrácení změny na Apache:
ServerSignature) se neoznačuje, pokud je verze webového serveru už skrytá: bez verze ukazuje jen název serveru a název hostitele.
Stránka „Mapa útoků“ určuje zemi podle IP příkazem geoiplookup. Bez balíčku GeoIP se země neurčí a body se na mapě neobjeví:
/usr/share/GeoIP/GeoIP.dat čtou všichni, výsledky se ukládají do mezipaměti v tmp/geoip_cache.json. Samotná mapa (Leaflet + dlaždice OpenStreetMap) se načítá v prohlížeči — na počítači, kde je otevřený dashboard, je potřeba internet.
Dvě vestavěné karty dashboardu, které nezobrazují „zap/vyp“ nástroje, ale skutečné zabezpečení serveru. Nevyžadují instalaci, čtou se lokálně bez sudo.
Vnější expozice — kolik služeb naslouchá na všech rozhraních (0.0.0.0/[::]) a je dostupných zvenčí. Zvýrazní červeně, pokud jsou navenek vystaveny databáze nebo cache (MySQL, PostgreSQL, Redis, MongoDB, Memcached, Elasticsearch) — to je přímá díra (−10 ke Skóre zabezpečení). Zdroj: ss -tuln.
127.0.0.1 (bind-address v konfiguraci MySQL/PostgreSQL, bind 127.0.0.1 v Redis) nebo zavřete port v UFW.
127.0.0.1 (loopback) je viditelná jen samotnému serveru — zvenčí se k ní nedostanete, i když je port „otevřený“. Proto je Postfix na portu 25 navázaný na loopback bezpečný: automatické nastavení nastaví inet_interfaces = loopback-only (plus neutrální smtpd_banner — uzavírá poznámku Lynis MAIL-8818 o odhalení verze). Karta „Vnější expozice“ počítá jako vnější jen to, co naslouchá na 0.0.0.0/[::]; loopback služby se do ní nezahrnují.
/etc/postfix/main.cf nastavte smtpd_banner = $myhostname ESMTP (bez verze a OS) a inet_interfaces = loopback-only, poté sudo systemctl restart postfix.
Bezpečnostní aktualizace — kolik bezpečnostních záplat čeká na instalaci a zda je po aktualizaci jádra potřeba restart (−5 ke Skóre zabezpečení, pokud jsou k dispozici záplaty). Zdroj: /usr/lib/update-notifier/apt-check, soubor /var/run/reboot-required. Podrobný seznam — na stránce „Bezpečnostní aktualizace“.
update-notifier-common). Pokud apt-check chybí — monitor počítá záplaty přes apt-get -s upgrade.
Automatické bezpečnostní aktualizace (unattended-upgrades) — na stránce „Bezpečnostní aktualizace“ samostatná karta ukazuje, zda je zapnutá automatická instalace bezpečnostních záplat a kdy proběhla naposledy. Sudo není potřeba — stav se čte přes apt-config dump.
Záloha je hlavní pojistka: ztráta dat je horší než jakýkoli průnik. Potřebujete dvě věci — zálohu serveru/webů a zvlášť zálohu databáze panelu (jsou v ní uživatelé, klíče WebAuthn, nastavení, licence).
Varianta A — HestiaCP: záložka Backup u uživatele → tlačítko vytvoření zálohy (nebo dle plánu v nastavení serveru). Záloha zahrnuje weby a jejich databáze.
Varianta B — ručně (cron): dump databáze + archiv adresáře data/ panelu:
Aktualizace na novou verzi. Nejprve si vytvořte zálohu. Poté znovu nahrajte soubory kódu a zachovejte svá data:
public/, includes/, assets/, cron/, database/ a také kořenové .htaccess (front-controller — směrování nelze ponechat ze staré verze), manifest.json, sw.js;config.php (údaje k DB), data/ (reporty), logs/, tmp/ (relace a cache).SSH_FX_PERMISSION_DENIED — Permission denied. Soubory panelu patří uživateli www-data (tak byly nastaveny při instalaci), zatímco SFTP klient se připojuje pod vaším vlastním uživatelem, který nemá právo zápisu. Dát www-data celý panel „aby to fungovalo“ — právě to vede k této chybě; níže jsou tři způsoby, kterýkoli problém vyřeší.
data/ (reporty), tmp/ (relace a cache), logs/; ty zůstávají uživateli www-data. Zbytek je kód a webový server jej potřebuje jen ke čtení, které umožňuje skupina www-data s právy 644. Vedlejší výhoda: při zranitelnosti v PHP už soubory panelu nepřepíšete. Na hostingových panelech (HestiaCP a podobných) varianta A není potřeba: tam soubory webu tak jako tak patří účtu, pod kterým se přihlašujete přes SFTP, a webový server je čte přes skupinu.
chmod na souborech resetuje ACL masku a přístup tiše zmizí. Pokud po „úklidu v právech“ nahrávání znovu narazí na Permission denied — zopakujte oba příkazy setfacl.
2 ve variantě C je setgid: soubory nahrané přes SFTP zůstávají ve skupině www-data, jinak je panel nedokáže přepsat. Po variantě C se ve FileZille připojte znovu — nová skupina se projeví až při novém přihlášení. Kontrola: id deploy (musí se objevit skupina www-data) a ls -ld /path/to/monitor (drwxrwsr-x — písmeno s znamená, že setgid je nastaven).
Přenos na jiný server:
config.php, data/.mysqldump na starém → import na novém; upravte údaje k DB v config.php.adm, cron úlohy.Panel už běží a na témže serveru je potřeba ještě jeden web — s vlastní doménou vedle monitoru. Po automatickém nastavení je server běžný Apache + PHP-FPM, web tedy potřebuje tři věci: vlastní adresář, vlastní vhost a vlastní certifikát. Panelu se přitom nedotýkáme: sleduje celý server, druhá instance pro druhou doménu není potřeba.
site2.example.com je adresa nového webu. Může to být jak samostatná doména (mycompany.com), tak subdoména (shop.mycompany.com) — pro Apache v tom není rozdíl, liší se jen DNS záznam (krok 1) a vydání certifikátu (krok 5). site2 je jen krátký název webu: tak se jmenují adresář /var/www/site2 a konfigurační soubor site2.conf. S doménou nijak nesouvisí, Apache bere adresu výhradně z ServerName; název může být jakýkoli — pro shop.mycompany.com se například hodí shop: adresář /var/www/shop, konfigurace shop.conf.
1. DNS. V panelu DNS u registrátora domény vytvořte záznam A na IP tohoto serveru:
Za několik minut ověřte: dig +short site2.example.com musí vrátit IP serveru.
2. Adresář webu.
3. Vhost. Blok se vkládá do terminálu celý — cesta k soketu PHP-FPM se zjistí sama:
4. Zapněte web a před znovunačtením ověřte konfiguraci:
5. SSL. certbot už automatické nastavení nainstalovalo; DNS musí v tuto chvíli směřovat na server:
Třetí a další domény se přidávají stejně — zopakujte kroky 1–5 se změněnou doménou a adresářem.
Host neodpovídá žádnému ServerName (přístup přes IP nebo cizí doména nasměrovaná na váš server), Apache vydá abecedně první zapnutý web z /etc/apache2/sites-enabled/. Standardní 000-default automatické nastavení vypíná, takže tuto „službu“ drží vhost panelu (arciveo-monitor.conf) — na weby otevírané pod vlastním jménem to nemá vliv. Pokud se má přes IP otevírat jiný web, pojmenujte jeho soubor tak, aby byl abecedně první (například 000-site2.conf).
site2_error.log a site2_access.log v /var/log/apache2/.
.htaccess (front controller) a vnořený web by vracel něco jiného, než očekáváte. Držte weby vedle sebe: /var/www/monitor, /var/www/site2.
Pokud se nemůžete přihlásit — vše se opraví přímo v databázi na serveru. Otevřete databázi (název — z config.php):
Ztracený klíč WebAuthn (neprojde druhý faktor) — vypněte 2FA, přihlaste se heslem a zaregistrujte nový klíč:
Zapomněli jste heslo — nastavte nový hash (vygenerujte ho na serveru a doplňte):
Zablokovali jste se IP filtrem — vypněte omezení:
sudo mysql na serveru, nebo phpMyAdmin / sekce databází v panelu hostingu. Po obnovení znovu zapněte WebAuthn a IP filtr.
Souhrn úloh je v root cronu serveru (přidávají se přes sudo crontab -e). Ponechte jen řádky nástrojů, které používáte; cesty upravte podle svého serveru.
sudo crontab -l a že je služba cron aktivní.
TIMEZONE z config.php. Konstanta TIMEZONE ovlivňuje jen PHP (jak panel zobrazuje data), ale cron démon spouští úlohy podle systémového času OS. Pokud se pásmo serveru neshoduje s vaším, report „08:00“ přijde v jinou dobu. Příklad: server je v jiném pásmu (Europe/London, UTC+1) a vy v Praze (UTC+2) → report „08:00“ vám přijde v 09:00 podle vás. Zkontrolujte a v případě potřeby srovnejte pásmo systému se svým:
0 8 * * * spustí v 08:00 místního času. Jinak byste museli posouvat samotný cron, ale při přechodu na zimní/letní čas by se posun zase rozešel — proto je správnější nastavit pásmo systému.
crontab.txt) jsou ve složce system/ vedle projektu, mimo public_html. Toto není součást webu — do webového kořene je nahrávat netřeba; umístěte je na server podle systémových cest (jako v crontabu výše):
lynis-scan.sh → /usr/local/bin/ (chmod +x) — spouští lynis audit system, po dobu skenu nastaví příznak /tmp/lynis-running a zkopíruje lynis-report.dat do data/lynis/ panelu;logwatch_daily.sh → /usr/local/bin/ (chmod +x) — vytváří denní report Logwatch (sshd, fail2ban, sudo, postfix) do data/logwatch/;smart-scan.sh → /usr/local/bin/ (chmod +x) — snímá stav disků (smartctl) do data/disk/;debsums-scan.sh → /usr/local/bin/ (chmod +x) — kontroluje integritu balíčků (debsums) do data/debsums/;clamav-scan.sh → /usr/local/bin/ (chmod +x) — antivirový sken ClamAV v nebezpečných cestách (web, home, temp); zapisuje souhrn do /var/log/clamav/scan.log, odkud jej čte stránka ClamAV (řádek 01:30 v crontabu výše);load-ipsum.sh → /usr/local/bin/ (chmod +x) — aktualizuje ipset sadu ipsum (level 1) na místě, aniž by narušil aktivní pravidla firewallu (řádek 04:00 v crontabu výše);daily-report-all.sh → /usr/local/bin/ (chmod +x) — spouští report cron/daily_report.php panelu (řádek 08:00 v crontabu výše);daily_report.php — už je součástí panelu (cron/daily_report.php), spouští se přes daily-report-all.sh, samostatně jej instalovat netřeba;collect-metrics-all.sh → /usr/local/bin/ (chmod +x) — spouští cron/collect_metrics.php panelu (stránka „Výkon“, řádek */5 v crontabu výše); collect_metrics.php už je součástí panelu, samostatně jej instalovat netřeba;security-watch-all.sh → /usr/local/bin/ (chmod +x) — spouští cron/security_watch.php panelu jménem vlastníka webu (stránka „Bezpečnostní události“, řádek 2-57/5 v crontabu výše); security_watch.php je již součástí panelu a není třeba jej instalovat zvlášť;fleet-push-all.sh → /usr/local/bin/ (chmod +x) — posílá přehled serveru do zákaznického účtu prostřednictvím cron/fleet_push.php panelu (řádek 3,18,33,48 výše);crontab.txt (system/cron/) — vzor úloh; potřebné řádky vložte přes sudo crontab -e./usr/local/bin/. Přímo z FileZilly tam zapsat nelze — adresář patří root a SFTP klient dostane SSH_FX_PERMISSION_DENIED. Postup je takový: nejprve nahrajte soubor do /tmp (tam zapisují všichni), poté jej přesuňte na místo jedním příkazem:
/tmp v kořeni serveru — ne /var/tmp ani tmp/ uvnitř samotného panelu (ten patří www-data a je pro vašeho uživatele uzavřený). Ve stromu FileZilly je /tmp větev nejvyšší úrovně, vedle var, ne uvnitř ní.
/usr/local/bin/, log — /var/log/arciveo-cron.log) — ručně není třeba nic dělat.
/home/*/web/*/public_html a /var/www/* a reporty ukládají do jejich data/. Pokud panel leží na jiné cestě — přidejte ji do řádku for app in … uvnitř skriptů, jinak se reporty Lynis/SMART/debsums/Logwatch do panelu nedostanou.
logs/cron.log vytvoří první root cron — bude patřit root a záložka „Log cronu“ v panelu jej nebude moci přečíst ani vyčistit. Vytvořte soubor předem jménem webového uživatele (vlastník adresáře webu; na HestiaCP je to účet, např. admin) — pak bude root cron jen dopisovat, aniž by měnil vlastníka:
stat -c %U /path/to/monitor.
sudo crontab -e), jinak se bude provádět dvakrát.
sudo crontab (to by byla přímá eskalace na root pro každého, kdo získá přístup k relaci panelu), ale úzký skript se dvěma příkazy (list/set), který se dotýká jen svého bloku mezi servisními komentáři. Nainstalujte jednou:
www-data — zkontrolujte, pod kým běží PHP-FPM pool webu (ps -o user= -C php-fpm), a doplňte jej do řádku sudoers.
public/crontab_monitor.php nahrán přes FTP/SFTP pod jiným systémovým uživatelem (například root) než ostatní soubory webu, webový server jej nedokáže přečíst. Porovnejte vlastníka a práva se sousedním souborem a uveďte do souladu:
Monitor zjišťuje přítomnost nástrojů pomocí dpkg-query — databáze balíčků APT. Pokud nástroj není nainstalován přes apt (ručně, ze snapu nebo ze zdrojových kódů), dpkg jej nevidí.
Chyba 500 — zkontrolujte logy PHP, nginx a samotného monitoru:
www-data, ale pod uživatelským účtem (např. admin — vlastník adresáře webu). Všechna sudo pravidla a členství ve skupinách (adm, systemd-journal) je nutné nastavit na tohoto uživatele, jinak moduly u běžících služeb zobrazí „Neaktivní / 0“. Reálného uživatele PHP zjistíte: ps -o user= -C php-fpm | sort -u nebo vlastníka adresáře webu stat -c '%U' /path/to/monitor. Dále ve všech příkazech níže jej dosaďte místo www-data. Automatická instalace webového uživatele určí sama a sudoers nastaví na něj.
Data se nezobrazují — téměř vždy jde o nenastavená sudo práva. Zkontrolujte konkrétní příkaz jménem webového uživatele (nahraďte www-data svým). Přepínač -n = bez hesla, stejně jako PHP — pokud vyžaduje heslo, pravidlo v sudoers chybí:
sudo aa-status v terminálu profily zobrazí, ale stránka „AppArmor“ — „Neaktivní“). Příčina: webový uživatel nemá sudo právo na příkaz tohoto modulu. Ověřte jej ze seznamu výše: pokud vyžaduje heslo — doplňte chybějící řádek do /etc/sudoers.d/monitor („Nastavení sudo“). Časté „nové“ příkazy: /usr/sbin/aa-status (MAC), /usr/sbin/psad --Status (PSAD).
apache2ctl, ausearch, aa-status nebo ss, případně webový uživatel není ve skupinách adm/systemd-journal (odtud se čtou logy fail2ban/auth/modsec a journalctl — Falco a události jádra).
Příznak: na serveru data existují (přes shell jsou vidět), ale stránka zobrazuje „žádná data“ nebo špatný stav — například AIDE hlásí „Neinicializováno“, ačkoli databáze je vytvořena.
Příčinou je open_basedir: mnoho panelů a hostingů omezuje pool PHP-FPM na adresář domény, takže PHP funkce file_exists(), file_get_contents(), filemtime() jsou pro systémové cesty (/var/lib/aide, /var/log, /proc…) blokovány. Monitor to obchází tím, že takové cesty čte standardními systémovými příkazy (cat, test, stat).
open_basedir. Správným řešením je čtení systémovými příkazy (u AIDE a Síťového monitoru už zavedeno). Rozšiřovat open_basedir na /var, /proc není potřeba a je to méně bezpečné.
Monitor kontroluje certifikáty připojením k doménám přímo přes port 443. Pokud je doména nedostupná ze samotného serveru nebo je port blokován firewallem, kontrola neproběhne.
/etc/nginx/sites-enabled/, /etc/nginx/conf.d/) a Apache (/etc/apache2/sites-enabled/) plus aktuální host z HTTP_HOST.
Monitor se připojuje k MySQL pod uživatelem z config.php, který má přístup jen ke své databázi. MySQL zobrazuje v information_schema pouze databáze s příslušnými oprávněními — proto ostatní nejsou vidět.
Aby monitor viděl všechny databáze, udělte tomuto uživateli oprávnění jen ke čtení (jednou pod root; doplňte jméno uživatele z config.php):
sudo mysql dashboard nepoužívá: seznam databází získává přes vlastní připojení PDO.
PostgreSQL vyžaduje přístup na úrovni uživatele postgres, kterého webový uživatel panelu nemá. Otevírat z PHP široký sudo psql není bezpečné — panel místo toho volá úzkou obálku bez parametrů, která pouze vypíše verzi, počet spojení a seznam databází s velikostmi. Vytvořte ji:
monitor-pgstat ze sudoers (krok 13 ruční instalace) a samotný skript nevytvářejte: karta PostgreSQL zůstane jen neaktivní.
Dashboard ukazuje, co se děje; níže je co dělat v typických situacích. Obecné pravidlo: nepanikařit, ověřit oproti legitimní aktivitě (vaše akce, aktualizace, zálohy) a reagovat podle závažnosti.
ignoreip./etc, mimo /usr/share) — potenciální podvržení. Ověřte balíček: debsums PACKAGE_NAME, při pochybnostech ho přeinstalujte (apt install --reinstall).127.0.0.1 nebo zavřete port v UFW. To je reálná díra.certbot renew nebo nastavení v dashboardu).sudo apt update && sudo apt upgrade; po aktualizaci jádra server restartujte.