Detta är en guide för installation, konfiguration och underhåll av Arcivéo Monitor. Avsnitten är grupperade: allmän översikt, driftsättning av panelen, anslutning av säkerhetsverktyg, inbyggda moduler och diagnostik. Kommandon kan kopieras med knappen till höger.
Installationen av panelen finns på separata steg-för-steg-sidor. Välj metod:
Arcivéo Monitor — en säkerhetspanel för servern. Samlar in data från installerade verktyg (Fail2ban, UFW, Lynis, ModSecurity, AIDE, ClamAV, Auditd, CrowdSec, Suricata, Falco m.fl.) och visar den i ett enhetligt gränssnitt med dashboard, angreppskarta och detaljsidor för varje verktyg.
Monitor är inte ett aktivt skyddsverktyg — den blockerar inte angrepp på egen hand. Dess uppgift är att aggregera information från redan aktiva verktyg och presentera den på ett överskådligt sätt.
Monitorn körs endast lokalt — den måste installeras på samma server som den övervakar. Ingen SSH eller fjärr-API används.
Alla kommandon (fail2ban-client, ufw status, ipset list osv.) körs av panelen som webbserverns användare (vanligtvis www-data, på hostingpaneler webbplatsens konto) med en snäv uppsättning rättigheter i sudo — enbart för specifika verktyg, utan generell root-åtkomst. Resultaten tolkas och visas i webbläsaren.
Poängen startar på max och sänks för varje upptäckt problem:
PermitRootLogin yes) — −20Resultat: 80+ = Skyddad, 60–79 = Observera, <60 = Hotad.
WebAuthn — standard för lösenordsfri autentisering via en fysisk säkerhetsnyckel. Stöder YubiKey, Touch ID, Face ID, Windows Hello, Passkey.
Efter inloggning med lösenord begär systemet bekräftelse via den registrerade nyckeln. Även om lösenordet läcker går det inte att logga in utan den fysiska nyckeln eller biometrin.
För att ställa in det, öppna WebAuthn-nycklar i sidomenyn och klicka på ”Registrera nyckel”. Registrera två nycklar direkt: om din enda nyckel tappas bort eller går sönder blir det omöjligt att logga in på panelen med den.
Panelen kan skicka säkerhetsrapporter till Telegram och e-post (via knapp och enligt schema). Konfigureras under ”Inställningar”.
Telegram. Du behöver en bot-token och ett chat id:
@BotFather i Telegram → /newbot → få en token i formatet 123456:ABC....@userinfobot, eller öppna https://api.telegram.org/bot<TOKEN>/getUpdates och hitta "chat":{"id":...}.E-post. Två metoder att välja mellan under ”Inställningar” → E-post:
re_...) och en verifierad avsändardomän.Rapportstatus: ”VARNING” eller ”OK”. Rubriken blir ”VARNING” endast vid ett verkligt problem eller en väntande åtgärd: ett hot hittat av ClamAV, filändringar i AIDE, kritiska Falco-händelser (Emergency/Alert/Critical de senaste 24 h), en nedstånen tjänst i Monit, omstart krävs, SSL löper ut (≤14 dagar) eller säkerhetsuppdateringar väntar. Bakgrundsbrus — SSH-forcering av bottar, IP-adresser bannade av fail2ban, Suricata-varningar, Lynis-varningar och redan avvärjda ModSecurity-förfrågningar — höjer inte statusen, så sådana siffror i rapporten betyder inte ”VARNING” i sig.
Detaljerade övervakningsmoduler (Lynis, UFW, ModSecurity, attackkarta, AIDE, ClamAV m.fl.) låses upp när du har en giltig licens. Utan den fungerar instrumentpanelen, inställningarna och kontot, men modulerna visar kortet ”Licens krävs”.
Efter köpet i din kundportal har du en aktiveringskod av typen ARCIVEO-XXXX-XXXX-XXXX-XXXX. Den måste ”aktiveras” för din panels domän — det förvandlar koden till en signerad licensfil (blocket [license]) som du klistrar in i panelen.
Så här aktiverar du (3 steg):
my.arciveo.com → avsnittet ”Licenser” / ”Licensaktivering” — kopiera koden ARCIVEO-….monitor.example.com). Klicka på aktivera — systemet genererar en licensfil kopplad till denna domän och visar den i ett fält med knappen ”Kopiera”.Panelen kontrollerar nyckeln kryptografiskt: signatur, domänkoppling och giltighetstid.
APP_URL i config.php och ange endast värdnamnet — utan https:// och utan prefixet www. Aktiveringen är engångs: koden förvandlas till en licens för den angivna domänen och kan inte aktiveras igen — vid fel i domänen passar nyckeln inte din panel, och koden är förbrukad. Ange därför domänen noggrant.
Alla huvudparametrar för panelen anges i en enda fil, config.php, i roten (bredvid mappen public/) med vanliga define()-konstanter. Filen skapas vid installationen; den behöver sällan redigeras manuellt — främst vid domänbyte, flytt eller anslutning till en annan databas. Efter varje ändring, starta om PHP-FPM (annars tillämpas inte ändringarna på grund av OPcache).
Ange dina egna värden på de markerade ställena; lämna resten som det är:
Databas. Anslutningsuppgifter till MySQL/MariaDB:
DB_HOST — databasvärd, nästan alltid localhost;DB_NAME — namnet på panelens databas;DB_USER — databasanvändare (åtkomst endast till sin egen databas);DB_PASS — lösenordet för denna användare;DB_CHARSET — anslutningens teckenkodning, lämna utf8mb4.Applikation.
APP_URL — panelens fullständiga adress (t.ex. https://monitor.example.com). Måste stämma med domänen som licensen aktiverats för — annars avvisas nyckeln (se avsnittet ”Licens”);TIMEZONE — PHP-tidszon: påverkar bara hur panelen visar datum och tid. Den påverkar inte när cron-jobben körs — där gäller systemets tidszon (se ”Alla cron-jobb”).Sessionstid. SESSION_LIFETIME — timeout för inaktiv session i sekunder (glidande: uppdateras vid aktivitet). Standard är 28800 = 8 timmar; efter så lång tids inaktivitet ber panelen dig logga in igen. Till exempel 3600 = 1 timme, 86400 = ett dygn.
Felloggning. Fel visas aldrig för besökare, utan skrivs till logs/php_errors.log — de syns på sidan ”Applikationsloggar”. Dessa rader (display_errors=0, log_errors=1, sökvägen error_log) behöver vanligtvis inte ändras — inställningarna anges direkt i filen och är oberoende av php.ini.
public/), och för denna panel är webbroten (DocumentRoot) just panelens rot, inte public/. Filen ”läcker” inte i sig själv: i rotens .htaccess finns ett uttryckligt förbud för den (Require all denied) — servern returnerar 403. Även utan denna regel skulle källkoden inte läcka: detta är PHP — servern kör den och skickar den inte som text. För säkerhets skull: lägg inte ut den i offentliga repositorier och skicka den inte till supporten med det riktiga lösenordet. Filens rättigheter — 640.
UFW (Uncomplicated Firewall) är ett enkelt gränssnitt till nftables/iptables. Stänger alla inkommande portar utom de som uttryckligen tillåts. Sidan ”UFW-brandvägg” visar status och regler.
ufw enable måste du tillåta SSH (ufw allow OpenSSH), annars förlorar du åtkomsten till servern.
deny räknas inte som åtkomlig utifrån.
Skipping adding existing rule är inget fel. UFW meddelar så att en exakt likadan regel redan finns och lägger inte till den igen. Vid ny körning av autokonfigurationen (den är idempotent) är detta ett normalt meddelande — inget behöver göras.
Blockerar automatiskt IP-adresser när antalet misslyckade inloggningsförsök överskrids. Analyserar loggar från SSH, nginx, Apache och andra tjänster.
Grundinstallationen finns ovan. Här är en fungerande konfiguration som ger dussintals aktiva jail och tusentals blockeringar: allmänna inställningar, viktiga jail och autoban av skadliga IP från listan ipsum.
Filen /etc/fail2ban/jail.local — allmänna inställningar och de viktigaste jail:
ignoreip, annars kan du banna dig själv. Efter ändringar: sudo fail2ban-client reload.
Automatisk inläsning av blocklistan ipsum — i root-cron (sudo crontab -e): level 1 (100 000+ IP) läses in i uppsättningen ipsum, som filtreras bort i brandväggen (mer i avsnittet ”Blocklista IPset”):
ipsum — det är den dashboarden läser (kortet ”IPset ipsum”). Nivåer: levels/1.txt — maximal täckning, levels/3.txt — mer precist (3+ källor).
Varför ”Säkerhetsmonitor” är uppdelad i två zoner. Skyddet arbetar på två nivåer, och dashboarden blandar dem inte:
sshd, apache-*, nginx-* osv.) och grova återfallsförbrytare (jail recidive — de som redan bannats flera gånger). Detta är IP-adresser som faktiskt försökte ta sig in — de finns på attackkartan och i ”Tidslinjen”.ipset ipsum, som filtreras bort i brandväggen med regeln DROP. De flesta av dessa adresser har aldrig ens rört din server — de stoppas i förväg; räknaren ”IPset ipsum” visar hur många som stoppats preventivt.Skillnaden är enkel: reaktivt — ”dessa attackerade och fick ban”, preventivt — ”dessa blockerades redan före försöket”. Tidigare tvingades list-3 ipsum artificiellt in i recidive (därav den gamla uppdelningen ”list-baserade recidive”); nu innehåller recidive bara verkliga återfallsförbrytare, och preventiv blockering sker helt i brandväggen.
ipsum — en offentlig lista över skadliga IP-adresser som uppdateras dagligen. Monitorn visar antalet inlästa adresser på instrumentpanelen och attackkartan och räknar in det i säkerhetspoängen (−10 om uppsättningen inte är inläst).
Minimal variant utan fail2ban — en separat uppsättning ipsum med blockering via iptables:
@reboot. Samtidigt sätter kommandot create … -exist gränsen maxelem 300000 (standard är 65536 — level 1 får inte plats, det blir ”Hash is full”):
ipsum och, om brandväggen hanteras av installationsprogrammet (ny VPS — profilerna ”Fullständig”/”Förenklad”), ansluter uppsättningen till UFW med en DROP-regel — trafik från dessa IP-adresser blockeras på riktigt. Regeln ligger efter ESTABLISHED,RELATED, så befintliga anslutningar (inklusive din SSH) bryts inte — bara nya anslutningar från listan stoppas. Uppsättningen återställs när tjänsten ipsum-load.service startas före brandväggen (annars skulle UFW inte kunna starta), och uppdateras av cron kl. 04:00. På en redan konfigurerad server (panel, egen brandvägg) rör installationsprogrammet inte brandväggen — där förblir ipsum en lista för instrumentpanelen och attackkartan, och DROP-regeln läggs vid behov till manuellt (den minimala varianten med iptables … --match-set ipsum … -j DROP — ovan). Vid autoinstallation behöver du inte göra något manuellt.
En modern ersättare för Fail2ban med kollektiv threat intelligence: blockeringar från gemenskapen plus egna regler. Kräver en separat bouncer för att tillämpa blockeringar på brandväggen.
systemctl is-active crowdsec). Starta: sudo systemctl enable --now crowdsec; vid krasch kontrollera sudo journalctl -u crowdsec -n 30. Samma regel gäller alla tjänster med statusen ”Inte startad” (Suricata, Falco, Monit, MySQL).
stream halted / blockeringar tillämpas inte. Det är en föräldralös api-nyckel: bouncern togs bort från cscli bouncers list, men dess gamla nyckel finns kvar i /etc/crowdsec/bouncers/*.yaml. Registrera bouncern på nytt och ange en ny nyckel:
AIDE (Advanced Intrusion Detection Environment) tar en ögonblicksbild av filsystemet och rapporterar vid varje kontroll om ändringar i /etc, /bin, /usr. Efter installationen är initiering av databasen obligatorisk (aideinit).
aideinit står terminalen i 5–15 minuter på raden Running aide --init... — det är normalt (hashning av hela filsystemet, belastning på disken). Avbryt inte med Ctrl+C. Om processen ”hänger” men inte skriver något — väntar den kanske på svar på en dold fråga Overwrite existing aide.db.new [Yn]? (tryck Y). Kontrollera aktiviteten från en annan session: pgrep -af aide.
aideinit: ”21_aide_spamassassin … printf: invalid number” (return code 20) — en känd bugg i AIDE:s konfigurationssnutt i Ubuntu 22.04. Databasen skapas inte. Flytta ut den trasiga snutten och försök igen:
aideinit inte körts, eller (Ubuntu 24.04) katalogen /var/lib/aide är skapad med läge 700 och är otillgänglig för www-data — åtgärdas med sudo chmod 755 /var/lib/aide (se blocket ovan). ”Inga kontroller har gjorts” = databasen finns, men kontroll har ännu inte utförts — det är inte ett fel. Resultaten läser monitorn från /var/log/aide/aide.log.
/etc/cron.daily/aide på nyare Ubuntu/Debian skriver kanske inte /var/log/aide/aide.log i rätt form (och aide.wrapper finns inte längre i dem). Det är säkrare att lägga till en egen cron med explicit --config — den skriver loggen som root med läge 644, och monitorn läser den utan extra grupper:
chmod 755 /var/lib/aide och en cron-kontroll kl. 02:00 — inget behöver göras manuellt.
sudo aideinit && sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db.
Antivirusskanner för Linux. Särskilt användbar för att kontrollera /var/www efter PHP-skal och skadlig kod.
enable --now? Tre vanliga orsaker:
1. Raden Example finns kvar i konfigurationen — clamd vägrar starta så länge den finns:
2. Signaturdatabasen är inte nedladdad — clamd startar inte utan den:
3. Den laddar helt enkelt — clamd läser in ~8 miljoner signaturer i minnet på 30–60 sek. Vänta och kontrollera: systemctl is-active clamav-daemon (status activating → laddar fortfarande).
sudo journalctl -u clamav-daemon -n 30 --no-pager.
clamd håller bara signaturerna i minnet, den skannar inget schemalagt av sig själv. Panelen visar resultatet av en schemalagd skanning, så det behövs en cron som skannar och skriver logg. Autoinstallationen lägger in omslaget /usr/local/bin/clamav-scan.sh och en cron kl. 01:30 — efter första körningen fylls ”Filer kontrollerade” och ”Senaste skanning” i. Kör direkt utan att vänta på schemat: sudo /usr/local/bin/clamav-scan.sh.
Linux Malware Detect (LMD) — en skanner för skadlig kod mot webbhot: PHP-skal, webbakdörrar, nedladdare. Använder ClamAV-motorn och kompletterar den med egna signaturer.
maldet --report.
update-rc.d: error: unable to read /etc/init.d/maldet visas — den är ofarlig. maldet använder inte init.d, uppdatering av signaturer och skanningar körs via /etc/cron.daily/maldet. Om installation completed visas nedan — allt installerades.
apt, utan i /usr/local/maldetect, och när open_basedir är aktiverat kontrolleras dess närvaro via shell — se avsnittet ”Sidan är tom trots att data finns på servern”.
Nätverksbaserat intrångsdetekteringssystem: analyserar trafiken på paketnivå och känner till tusentals attacksignaturer. Kompletterar ModSecurity (som arbetar på HTTP-nivå, medan Suricata arbetar på TCP/IP-nivå).
/var/log/suricata/eve.json som root med läget 750 på katalogen, och webbservern (www-data) kan inte läsa den. Öppna katalogen för genomgång – filerna inuti förblir skyddade:
Fångar upp systemanrop via eBPF/kernel-modul och upptäcker avvikelser i realtid: shell från nginx, läsning av /etc/passwd av en webbprocess, skrivning till /bin osv.
journalctl -u falco (utan sudo — via gruppen systemd-journal). Kontrollera att www-data finns i den gruppen — se ”Konfigurera sudo” (p.2) på sidan för manuell installation.
/etc/passwd, skrivning till systemkataloger). Noll kritiska under ett dygn på en lugn server är ett friskt tillstånd.
journalctl kräver rättigheter till loggen; för att panelen ska se händelser stabilt aktiverar autoinstallationen file_output för Falco → /var/log/falco/falco.log och sätter UMask=0022 på tjänsten (loggen läses av webbservern). På en ny installation behöver detta inte konfigureras manuellt.
ModSecurity — en webbrandvägg (WAF) för Apache eller Nginx. Blockerar attacker på applikationsnivå: SQL-injektioner, XSS, sökvägstraversering, skannrar.
IncludeOptional /etc/modsecurity/*.conf, men paketet lägger bara modsecurity.conf-recommended — den matchar inte mönstret *.conf. Om den inte kopieras till modsecurity.conf förblir SecRuleEngine Off: modulen är laddad, CRS-reglerna är laddade, men trafiken kontrolleras inte och ingen granskningslogg skapas. Mellanläget DetectionOnly skriver bara händelser till loggen utan att blockera förfrågningar — panelen visar det i gult.
Panelens åtkomst till granskningsloggen. Loggen /var/log/apache2/modsec_audit.log ägs av root (rättigheter 640) och kan inte läsas av webbanvändaren. Panelen hämtar data via ett omslag — skapa det:
SecRuleEngine-direktivet utan indrag: rader med indrag ligger inne i block <LocationMatch>/<Directory> (t.ex. avstängning av WAF för phpMyAdmin) och bestämmer inte det globala läget.www-data, i HestiaCP körs webbplatsens pool som webbplatsens ägare (t.ex. admin) — kontrollera med grep -E '^user' /etc/php/*/fpm/pool.d/monitor.example.com.conf.X-Forwarded-For. Endast transaktioner där en regel utlösts hamnar i statistiken: direktivet SecAuditLogRelevantStatus skriver alla 4xx/5xx-svar till granskningsloggen, så även vanliga 403/500 hamnar där — panelen räknar dem inte som WAF-händelser.---RULES--- behövs av avsnittet ”Alla aktiva regler” — panelen visar inte bara de utlösta reglerna, utan över huvud taget alla laddade CRS-regler + anpassade. De tre sökvägarna i slingan for f in … är typiska platser för CRS-regler och lokala tillägg; om du har en annan uppsättning (paketet lägger filer i sin egen katalog, eller om anpassade regler inte ligger i /etc/modsecurity/custom-rules.conf) hittar du de verkliga sökvägarna med kommandot sudo grep -rl 'IncludeOptional\|^Include ' /etc/apache2/mods-enabled/security2.conf /etc/apache2/conf-enabled/*.conf 2>/dev/null och lägger in dem i listan. Om omslaget är gammalt (utan detta avsnitt) visar avsnittet bara varningen ”otillgängligt”, resten av sidan fungerar som förut.
Auditd (Linux Audit Daemon) registrerar systemanrop på kärnnivå: inloggningar och utloggningar, sudo-kommandon, misslyckade autentiseringsförsök, filändringar. Monitorn visar inloggningar, misslyckade försök och sudo-kommandon för idag.
ausearch (/usr/sbin/ausearch) och vid behov från /var/log/audit/audit.log med kommandot tail. Båda måste finnas i sudoers.
Övervakar tjänster (nginx, php-fpm, mysql osv.) och startar om dem vid krasch. Kan skicka aviseringar via e-post.
monit status. I /etc/monit/monitrc måste HTTP-gränssnittet vara aktiverat (blocket set httpd med allow localhost), annars returnerar monit status ett fel.
monitrc är raden set httpd bortkommenterad (standard är # set httpd port 2812 …). Avkommentera blocket och tillåt localhost. (2) Ett aktiverat httpd övervakar inget i sig — Monit räknar bara det som beskrivs i check-stanser; utan dem är listan tom även med fungerande gränssnitt. Minimal fungerande konfiguration:
conf.d med httpd på 2812 och en uppsättning kontroller — på en ny installation behöver inget konfigureras manuellt.
PSAD analyserar iptables-loggen och upptäcker portskanning och nätverksattacker genom att tilldela varje källa en hotnivå (1–5). Kompletterar fail2ban och Suricata.
psad --Status (krävs i sudoers). Utan iptables-loggning är sidan tom — det är normalt tills en skanning har inträffat.
Mandatory Access Control begränsar vilka filer och resurser ett program kan komma åt, även om det har blivit hackat. I Ubuntu/Debian används AppArmor som standard (vanligtvis redan installerat och aktivt).
aa-status (krävs i sudoers). Visar antalet profiler i läget enforce/complain och processer utan profil.
Att ”laddade profiler” är fler än enforce + complain är normalt. I AppArmor 4.x (Ubuntu 24.04 och senare) infördes läget unconfined: profilen laddas i kärnan men begränsar ingenting. Ubuntu markerar på så sätt tiotals profiler för program som använder user namespaces (webbläsare, torrent-klienter och liknande). När sådana profiler finns blir kortet ”laddade profiler” bärnstensfärgat och visar deras antal — till exempel unconfined: 90 vid 120 laddade och 26 i enforce. Egentligt skydd ger bara profiler i enforce; på Ubuntu 22.04 (AppArmor 3.x) finns inte detta läge och siffrorna stämmer alltid överens.
unconfined till enforce bör göras endast med eftertanke: de är inte avstängda av misstag, utan för att programmen annars slutar fungera. Profiler i complain är en annan sak: där är reglerna redan skrivna och tillämpas bara inte.
debsums kontrollerar att filerna i installerade paket stämmer överens med kontrollsummorna från förrådet — upptäcker utbytta systembinärer (kompletterar AIDE). En fullständig kontroll tar 1–2 minuter och körs därför via cron, medan panelen läser resultatet från data/debsums/debsums.log och sorterar det själv i kategorier (endast binärer och bibliotek är viktiga).
Uppgiften läggs i root-cron (sudo crontab -e). Den färdiga wrappern debsums-scan.sh placeras i /usr/local/bin/ (chmod +x; se sammanställningen av cron-uppgifter) och skriver själv rapporten till data/debsums/ i panelen.
Wrappern debsums-scan.sh hittar själv panelens data/ — sökvägen behöver inte anges.
/etc/ (konfigurationer) och /usr/share/ (resurser) på servern är oftast normala — panelen markerar dem med en särskild färg. Oroande är ändringar av binärer och bibliotek (/bin, /sbin, /usr/lib osv.) — kortet ”Binärer / bibliotek” visar just dessa.
Lynis körs manuellt eller via cron. Rapporten ska sparas i projektets mapp data/lynis/ — monitorn läser filen lynis-report.dat.
lynis-scan.sh i bakgrunden direkt från panelen (utan att vänta på cron): visar ”Skannar…” och uppdaterar rapporten själv när den är klar. För detta behöver webbanvändaren en sudoers-rad för att köra skriptet — installationsprogrammet lägger till den automatiskt i /etc/sudoers.d/monitor. Om panelen installerats manuellt/tidigare, lägg till den med samma användare som redan anges i filen:
Logwatch ska spara dagliga rapporter i projektmappen data/logwatch/ i formatet .txt. Monitorn visar den senaste rapporten och arkivet.
Nätverksmonitorn kräver ingen installation — det är en inbyggd sida i panelen. Den visar serverns nätverksstatus från lokala källor:
/proc/net/dev;ip;ss;journalctl -k.De tre första källorna fungerar utan sudo, så gränssnitt, trafik, anslutningar och portar syns direkt. Blocket ”Kärnhändelser” använder journalctl -k — det läses via gruppen systemd-journal (”Konfigurera sudo”, p.2), sudo behövs inte. Kontrollera att allt är tillgängligt för webbanvändaren:
UFW BLOCK hamnar inte här — de finns på sidorna ”Brandvägg UFW” och ”Attackkarta”. Ett tomt block med grön bock = inga nätverksfel senaste dygnet.
Den inbyggda sidan visar tre saker:
df); skalan blir röd vid ≥90 %;lsblk), endast riktiga (loop/snap döljs);smartctl).Utrymme och enhetslista fungerar direkt, utan konfiguration. För SMART krävs paketet smartmontools. Webbprocessen har ingen direkt åtkomst till diskenheterna, därför läses SMART av via cron till filen data/disk/smart.txt, och panelen läser den.
Jobbet läggs i root-cron (sudo crontab -e). Det färdiga skalet smart-scan.sh placeras i /usr/local/bin/ (chmod +x; se sammanställningen av cron-jobb) och skriver själv till panelens data/disk/.
Skalet smart-scan.sh hittar själv panelens data/ — sökvägen behöver inte anges. Internt utesluter lsblk -e7,11 loop/cdrom.
Sidan visar serverbelastningens historik för de senaste 24 timmarna — Load Average, CPU-användning och I/O-väntetid, RAM/Swap, nätverkstrafik (mottaget/skickat), disk-I/O (läsning/skrivning), diskfyllnad och inoder, öppna filbeskrivare och MySQL-anslutningar, plus aktuellt antal TCP-anslutningar och processer.
Data samlas in av cron/collect_metrics.php — var 5:e minut skrivs en ”rå” ögonblicksbild av räknarna (/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') till databastabellen system_metrics; procent och hastigheter beräknar sidan själv utifrån skillnaden mellan intilliggande ögonblicksbilder (diskfyllnad/inoder/beskrivare/MySQL-anslutningar är momentana värden, utan omräkning). Sudo krävs inte — källorna läses utan root-rättigheter. Punkter äldre än 24 timmar tas bort automatiskt vid varje skrivning.
Wrappern collect-metrics-all.sh (se sammanställningen av cron-jobb) hittar själv alla installerade panelinstanser på servern och kör cron/collect_metrics.php för var och en som webbplatsens ägare.
Belastningsaviseringar (avsnittet ”Inställningar” → ”Belastningsaviseringar”) — när tröskeln för CPU/RAM/disk/inoder överskrids skickar panelen en avisering till Telegram/Email (samma kanaler som den dagliga rapporten — de behöver inte aktiveras separat för aviseringar), och ytterligare en när mätvärdet återgått till det normala. Den spammar inte upprepat medan tröskeln hålls: nästa avisering kommer först efter cykeln ”återställt → överskridit igen”.
collect_metrics.php vid varje körning (var 5:e minut) — ingen separat cron behövs. Tillståndet ”redan aviserat / inte än” lagras i data/alerts_state.json, trösklarna i panelens inställningar.
Sidan ”Attackkarta” fastställer landet utifrån IP med kommandot geoiplookup. Utan GeoIP-paketet kan länder inte identifieras och inga punkter visas på kartan:
/usr/share/GeoIP/GeoIP.dat kan läsas av alla, resultaten cachas i tmp/geoip_cache.json. Själva kartan (Leaflet + OpenStreetMap-rutor) laddas i webbläsaren – internet krävs på datorn där panelen är öppen.
Två inbyggda dashboardkort som inte visar om ett verktyg är på/av, utan serverns verkliga skyddsnivå. Kräver ingen installation och läses lokalt utan sudo.
Extern exponering — hur många tjänster som lyssnar på alla gränssnitt (0.0.0.0/[::]) och är åtkomliga utifrån. Markeras rött om databaser eller cache exponeras utåt (MySQL, PostgreSQL, Redis, MongoDB, Memcached, Elasticsearch) — det är ett direkt säkerhetshål (−10 på säkerhetspoängen). Källa: ss -tuln.
127.0.0.1 (bind-address i MySQL/PostgreSQL-konfigurationen, bind 127.0.0.1 i Redis) eller stäng porten i UFW.
127.0.0.1 (loopback) syns bara för servern själv — den går inte att nå utifrån, även om porten är ”öppen”. Därför är Postfix på port 25 bunden till loopback säker: autokonfigurationen sätter inet_interfaces = loopback-only (plus ett neutralt smtpd_banner — som avfärdar Lynis-anmärkningen MAIL-8818 om att versionen röjs). Kortet ”Extern exponering” räknar bara det som lyssnar på 0.0.0.0/[::] som utåtvänt; loopback-tjänster ingår inte.
smtpd_banner = $myhostname ESMTP (utan version och OS) och inet_interfaces = loopback-only i /etc/postfix/main.cf, kör sedan sudo systemctl restart postfix.
Säkerhetsuppdateringar — hur många säkerhetspatchar som väntar på installation och om en omstart krävs efter en kärnuppdatering (−5 på säkerhetspoängen om patchar finns). Källa: /usr/lib/update-notifier/apt-check, filen /var/run/reboot-required. Detaljerad lista finns på sidan ”Säkerhetsuppdateringar”.
update-notifier-common). Om apt-check saknas räknar monitorn patcharna via apt-get -s upgrade.
Automatiska säkerhetsuppdateringar (unattended-upgrades) — på sidan ”Säkerhetsuppdateringar” visar ett separat kort om automatisk installation av säkerhetspatchar är aktiverad och när den senast kördes. Sudo behövs inte — statusen läses via apt-config dump.
Säkerhetskopior är den viktigaste försäkringen: dataförlust är värre än vilket intrång som helst. Du behöver två saker — säkerhetskopia av servern/webbplatserna och separat en säkerhetskopia av panelens databas (där finns användare, WebAuthn-nycklar, inställningar och licens).
Alternativ A — HestiaCP: fliken Backup hos användaren → knappen för att skapa en säkerhetskopia (eller schemalagt i serverinställningarna). Säkerhetskopian omfattar webbplatser och deras databaser.
Alternativ B — manuellt (cron): databasdump + arkiv av panelens katalog data/:
Uppdatering till en ny version. Gör först en säkerhetskopia. Ladda sedan upp kodfilerna på nytt och behåll dina data:
public/, includes/, assets/, cron/, database/, samt roten .htaccess (frontkontroller – routningen får inte vara kvar från den gamla versionen), manifest.json, sw.js;config.php (databasuppgifter), data/ (rapporter), logs/, tmp/ (sessioner och cache).SSH_FX_PERMISSION_DENIED — Permission denied. Panelens filer ägs av www-data (så sattes de vid installationen), medan SFTP-klienten ansluter som din egen användare, som inte har skrivrättighet. Att ge www-data hela panelen ”för att det ska fungera” är just det som leder till detta fel; nedan tre sätt, vart och ett löser problemet.
data/ (rapporter), tmp/ (sessioner och cache), logs/; de förblir under www-data. Resten är kod, och webbservern behöver den bara för läsning, vilket gruppen www-data ger med rättigheterna 644. Sidovinst: vid en PHP-sårbarhet går panelens filer inte längre att skriva över. På hostingpaneler (HestiaCP och liknande) behövs inte alternativ A: där ägs webbplatsens filer redan av kontot som du loggar in med via SFTP, och webbservern läser dem via gruppen.
chmod på filerna nollställer ACL-masken, och åtkomsten försvinner tyst. Om uppladdningen efter en ”upprensning av rättigheterna” åter fastnar på Permission denied — kör båda setfacl-kommandona igen.
2 i alternativ C är setgid: filer som laddas upp via SFTP stannar kvar i gruppen www-data, annars kan panelen inte skriva över dem. Efter alternativ C — anslut på nytt i FileZilla: den nya gruppen börjar gälla först vid en ny inloggning. Kontroll: id deploy (gruppen www-data ska dyka upp) och ls -ld /path/to/monitor (drwxrwsr-x — bokstaven s betyder att setgid är satt).
Migrering till en annan server:
config.php, data/.mysqldump på den gamla → import på den nya; uppdatera databasuppgifterna i config.php.adm, cron-jobb.Om du inte kan logga in kan allt åtgärdas direkt i databasen från servern. Öppna databasen (namnet finns i config.php):
Förlorad WebAuthn-nyckel (andra faktorn fungerar inte) — inaktivera 2FA, logga in med lösenord och registrera en ny nyckel:
Glömt lösenord — ange en ny hash (generera den på servern och infoga den):
Låst ute dig själv med IP-filtret — inaktivera begränsningen:
sudo mysql på servern, eller phpMyAdmin / databasavsnittet i hostingpanelen. Aktivera WebAuthn och IP-filtret igen efter återställningen.
Sammanställningen av jobb finns i serverns root-cron (läggs till via sudo crontab -e). Behåll bara raderna för de verktyg du använder; justera sökvägarna för din server.
sudo crontab -l och att cron-tjänsten är aktiv.
TIMEZONE från config.php. Konstanten TIMEZONE påverkar bara PHP (hur panelen visar datum), men cron-demonen kör jobb enligt operativsystemets systemtid. Om serverns tidszon inte matchar din kommer rapporten ”08:00” vid fel tidpunkt. Exempel: servern står i en annan tidszon (Europe/London, UTC+1), medan du är i Stockholm (UTC+2) → rapporten ”08:00” kommer 09:00 hos dig. Kontrollera och ställ vid behov systemets tidszon till din egen:
0 8 * * * kl. 08:00 lokal tid. Annars skulle man behöva förskjuta själva cron, men vid övergång till vinter-/sommartid går förskjutningen isär igen — därför är det bättre att ställa in systemets tidszon.
crontab.txt) ligger i mappen system/ bredvid projektet, utanför public_html. Det är inte en del av webbplatsen — de behöver inte laddas upp till webbroten; placera dem på servern enligt systemsökvägarna (som i crontab ovan):
lynis-scan.sh → /usr/local/bin/ (chmod +x) — kör lynis audit system, sätter flaggan /tmp/lynis-running under skanningen och kopierar lynis-report.dat till panelens data/lynis/;logwatch_daily.sh → /usr/local/bin/ (chmod +x) — skapar en daglig Logwatch-rapport (sshd, fail2ban, sudo, postfix) i data/logwatch/;smart-scan.sh → /usr/local/bin/ (chmod +x) — läser av diskarnas status (smartctl) i data/disk/;debsums-scan.sh → /usr/local/bin/ (chmod +x) — kontrollerar paketintegritet (debsums) i data/debsums/;clamav-scan.sh → /usr/local/bin/ (chmod +x) — ClamAV-antivirusskanning av farliga sökvägar (web, home, temp); skriver en sammanställning till /var/log/clamav/scan.log, varifrån ClamAV-sidan läser den (raden 01:30 i crontab ovan);load-ipsum.sh → /usr/local/bin/ (chmod +x) — uppdaterar ipset-uppsättningen ipsum (level 1) på plats, utan att bryta de aktiva brandväggsreglerna (raden 04:00 i crontab ovan);daily-report-all.sh → /usr/local/bin/ (chmod +x) — kör panelens rapport cron/daily_report.php (raden 08:00 i crontab ovan);daily_report.php — ingår redan i panelen (cron/daily_report.php), körs via daily-report-all.sh, behöver inte installeras separat;collect-metrics-all.sh → /usr/local/bin/ (chmod +x) — kör panelens cron/collect_metrics.php (sidan ”Prestanda”, raden */5 i crontab ovan); collect_metrics.php ingår redan i panelen, behöver inte installeras separat;crontab.txt (system/cron/) — exempel på jobb; skriv in de rader du behöver via sudo crontab -e./usr/local/bin/. Direkt från FileZilla går det inte att skriva dit — katalogen ägs av root, och SFTP-klienten får SSH_FX_PERMISSION_DENIED. Gör så här: ladda först upp filen till /tmp (dit kan alla skriva), och flytta den sedan på plats med ett enda kommando:
/tmp i serverns rot — inte /var/tmp och inte tmp/ inuti själva panelen (den sistnämnda ägs av www-data och är stängd för din användare). I FileZilla-trädet är /tmp en gren på översta nivån, bredvid var, inte inuti den.
/usr/local/bin/, logg — /var/log/arciveo-cron.log) — du behöver inte göra något manuellt.
/home/*/web/*/public_html och /var/www/*, och lägger rapporterna i deras data/. Om panelen ligger på en annan sökväg — lägg till den i raden for app in … inuti skripten, annars når inte rapporterna från Lynis/SMART/debsums/Logwatch panelen.
logs/cron.log skapas först av root-cron — den kommer att ägas av root, och fliken ”Cron-logg” i panelen kan varken läsa eller tömma den. Skapa filen i förväg som webbanvändaren (ägare till webbplatsens katalog; på HestiaCP är det kontot, t.ex. admin) — då lägger root-cron bara till text utan att ändra ägaren:
stat -c %U /path/to/monitor.
sudo crontab -e), annars körs det två gånger.
sudo crontab (det skulle vara en direkt eskalering till root av vem som helst som får åtkomst till panelens session), utan ett smalt skript med två kommandon (list/set) som bara rör sitt eget block mellan tjänstekommentarerna. Installera en gång:
www-data — kontrollera vilken användare webbplatsens PHP-FPM-pool körs under (ps -o user= -C php-fpm) och sätt in den i sudoers-raden.
public/crontab_monitor.php laddades upp via FTP/SFTP under en annan systemanvändare (till exempel root) än övriga webbplatsfiler kan webbservern inte läsa den. Jämför ägare och rättigheter med en intilliggande fil och gör dem enhetliga:
Monitorn identifierar tillgängliga verktyg via dpkg-query — APT:s paketdatabas. Om ett verktyg inte installerats via apt (manuellt, från snap eller från källkod) syns det inte för dpkg.
Fel 500 — kontrollera loggarna för PHP, nginx och själva monitorn:
www-data, utan under användarens konto (t.ex. admin — ägaren av webbplatsens katalog). Alla sudo-regler och gruppmedlemskap (adm, systemd-journal) måste anges för den användaren, annars visar modulerna ”Inte aktiv / 0” trots att tjänsterna körs. Ta reda på PHP:s verkliga användare: ps -o user= -C php-fpm | sort -u eller ägaren av webbplatsens katalog stat -c '%U' /path/to/monitor. Använd sedan den i alla kommandon nedan i stället för www-data. Autoinstallationen identifierar webbanvändaren själv och skriver sudoers för den.
Data visas inte — nästan alltid saknade sudo-behörigheter. Kontrollera det specifika kommandot som webbanvändaren (ersätt www-data med din egen). Flaggan -n = utan lösenord, som PHP — om det ber om lösenord finns regeln inte i sudoers:
sudo aa-status i terminalen visar profiler, men sidan ”AppArmor” visar ”Inaktiv”). Orsak: webbanvändaren saknar sudo-behörighet för den modulens kommando. Kontrollera det från listan ovan: om det ber om lösenord — lägg till den saknade raden i /etc/sudoers.d/monitor (”Konfigurera sudo”). Vanliga ”nya” kommandon: /usr/sbin/aa-status (MAC), /usr/sbin/psad --Status (PSAD).
apache2ctl, ausearch, aa-status eller ss inte tillåtet, eller så är webbanvändaren inte med i grupperna adm/systemd-journal (därifrån läses loggarna för fail2ban/auth/modsec och journalctl — Falco och kärnhändelser).
Symptom: data finns på servern (syns via shell) men sidan visar ”inga data” eller fel status – till exempel skriver AIDE ”Inte initierad” trots att databasen är skapad.
Orsaken är open_basedir: många paneler och webbhotell begränsar PHP-FPM-poolen till domänens katalog, så PHP-funktionerna file_exists(), file_get_contents(), filemtime() blockeras för systemsökvägar (/var/lib/aide, /var/log, /proc…). Monitorn kringgår detta genom att läsa sådana sökvägar med vanliga systemkommandon (cat, test, stat).
open_basedir. Rätt lösning är att läsa med systemkommandon (redan gjort för AIDE och Nätverksmonitorn). Att utöka open_basedir till /var, /proc behövs inte och är mindre säkert.
Monitorn kontrollerar certifikat genom att ansluta direkt till domänerna via port 443. Om domänen inte är nåbar från själva servern eller porten är blockerad av brandväggen — misslyckas kontrollen.
/etc/nginx/sites-enabled/, /etc/nginx/conf.d/) och Apache (/etc/apache2/sites-enabled/) plus den aktuella värden från HTTP_HOST.
Monitorn ansluter till MySQL med användaren från config.php, som bara har åtkomst till sin egen databas. MySQL visar i information_schema endast databaser med behörighet – därför syns inte de övriga.
För att monitorn ska se alla databaser, ge den här användaren enbart läsbehörighet (en gång som root; ange användarnamnet från config.php):
sudo mysql: databaslistan hämtas via dess egen PDO-anslutning.
PostgreSQL kräver åtkomst på nivån för användaren postgres, vilket panelens webbanvändare inte har. Att öppna en bred sudo psql från PHP är osäkert – i stället anropar panelen ett smalt omslag utan parametrar, som bara skriver ut versionen, antalet anslutningar och en lista över databaser med storlekar. Skapa det:
monitor-pgstat från sudoers (steg 13 i den manuella installationen) och skapa inte själva skriptet: PostgreSQL-kortet förblir bara inaktivt.
Panelen visar vad som händer; nedan står vad du ska göra i vanliga situationer. Grundprincipen: håll huvudet kallt, stäm av mot legitim aktivitet (dina åtgärder, uppdateringar, säkerhetskopior) och reagera efter allvarsgrad.
ignoreip./etc, utanför /usr/share) — potentiell manipulation. Kontrollera paketet: debsums PACKAGE_NAME, installera om det vid tvivel (apt install --reinstall).127.0.0.1 eller stäng porten i UFW. Det är ett verkligt hål.certbot renew eller inställningarna i panelen).sudo apt update && sudo apt upgrade; starta om servern efter en kärnuppdatering.