Dette er en veiledning for installasjon, konfigurasjon og vedlikehold av Arcivéo Monitor. Seksjonene er gruppert: generell oversikt, utrulling av panelet, tilkobling av sikkerhetsverktøy, innebygde moduler og diagnostikk. Kommandoene kan kopieres med knappen til høyre.
Installasjonen av panelet finnes på egne trinnvise sider. Velg metode:
Arcivéo Monitor — et sikkerhetspanel for serveren. Det samler inn data fra installerte verktøy (Fail2ban, UFW, Lynis, ModSecurity, AIDE, ClamAV, Auditd, CrowdSec, Suricata, Falco m.fl.) og viser dem i ett enhetlig grensesnitt med dashbord, angrepskart og detaljerte sider for hvert verktøy.
Monitor er ikke et aktivt beskyttelsesverktøy — det blokkerer ikke angrep selv. Oppgaven er å aggregere informasjon fra verktøy som allerede kjører, og presentere den på en oversiktlig måte.
Monitoren fungerer kun lokalt — den må installeres på den samme serveren som den overvåker. Ingen SSH eller eksternt API.
Alle kommandoer (fail2ban-client, ufw status, ipset list osv.) kjører dashbordet som webserverens bruker (vanligvis www-data, på hostingpaneler — nettstedets konto) med et snevert sett rettigheter for sudo — kun til bestemte verktøy, uten generell root-tilgang. Resultatene tolkes og vises i nettleseren.
Scoren starter på maksimum og reduseres for hvert problem som oppdages:
PermitRootLogin yes) — −20Resultat: 80+ = Beskyttet, 60–79 = Advarsel, <60 = Truet.
WebAuthn er en standard for passordløs autentisering med en maskinvarenøkkel. Støtter YubiKey, Touch ID, Face ID, Windows Hello og Passkey.
Etter pålogging med passord ber systemet om bekreftelse via en registrert nøkkel. Selv om passordet lekker, er det umulig å logge inn uten den fysiske nøkkelen eller biometri.
For å sette opp dette åpner du WebAuthn-nøkler i sidemenyen og klikker «Registrer nøkkel». Registrer to nøkler med en gang: hvis den eneste nøkkelen mistes eller går i stykker, blir det umulig å logge inn i dashbordet med den.
Panelet kan sende sikkerhetsrapporten til Telegram og på e-post (med knapp og etter tidsplan). Dette settes opp under «Innstillinger».
Telegram. Du trenger bot-token og chat id:
@BotFather i Telegram → /newbot → få en token av typen 123456:ABC....@userinfobot, eller åpne https://api.telegram.org/bot<TOKEN>/getUpdates og finn "chat":{"id":...}.E-post. To metoder å velge mellom under «Innstillinger» → E-post:
re_...) og et bekreftet avsenderdomene.Rapportstatus: «OBS» eller «OK». Overskriften blir «OBS» bare ved et reelt problem eller en handling som venter: ClamAV har funnet en trussel, filendringer i AIDE, kritiske Falco-hendelser (Emergency/Alert/Critical de siste 24 t), en tjeneste som er nede i Monit, omstart kreves, SSL utløper (≤14 dager) eller sikkerhetsoppdateringer venter. Bakgrunnsstøy — SSH-forsøk fra boter, IP-adresser bannet av fail2ban, Suricata-varsler, Lynis-advarsler og allerede avviste ModSecurity-forespørsler — hever ikke statusen, så slike tall i rapporten betyr ikke «OBS» i seg selv.
De detaljerte overvåkingsmodulene (Lynis, UFW, ModSecurity, angrepskart, AIDE, ClamAV m.fl.) åpnes når du har en gyldig lisens. Uten den fungerer dashbordet, innstillingene og kontoen, mens modulene viser kortet «Lisens kreves».
Etter kjøp har du på kontoen en aktiveringskode på formen ARCIVEO-XXXX-XXXX-XXXX-XXXX. Den må «aktiveres» mot domenet til panelet ditt – det gjør koden om til en signert lisensfil (blokken [license]) som du limer inn i panelet.
Slik aktiverer du (3 trinn):
my.arciveo.com → seksjonen «Lisenser» / «Lisensaktivering» – kopier koden ARCIVEO-….monitor.example.com). Trykk aktiver – systemet genererer en lisensfil knyttet til dette domenet og viser den i et felt med knappen «Kopier».Panelet kontrollerer nøkkelen kryptografisk: signatur, binding til domenet og gyldighetstid.
APP_URL i config.php og oppgi kun vertsnavnet – uten https:// og uten www-prefiks. Aktivering skjer én gang: koden blir til en lisens for det oppgitte domenet og kan ikke aktiveres på nytt – med feil i domenet passer ikke nøkkelen panelet ditt, og koden er brukt opp. Skriv derfor domenet nøye.
Alle hovedparametere for panelet er definert i én fil config.php i rotmappen (ved siden av mappen public/) med vanlige define()-konstanter. Filen opprettes ved installasjon; du trenger sjelden å redigere den manuelt — hovedsakelig ved bytte av domene, flytting eller tilkobling til en annen database. Etter enhver endring start PHP-FPM på nytt (ellers blir ikke endringene tatt i bruk på grunn av OPcache).
Sett inn dine egne verdier i de uthevede feltene; la resten være som det er:
Database. Tilkoblingsdetaljer for MySQL/MariaDB:
DB_HOST — databasevert, nesten alltid localhost;DB_NAME — navnet på panelets database;DB_USER — databasebruker (tilgang kun til egen database);DB_PASS — passordet til denne brukeren;DB_CHARSET — tegnkoding for tilkoblingen, la utf8mb4 stå.Applikasjon.
APP_URL — full adresse til panelet (f.eks. https://monitor.example.com). Må stemme med domenet lisensen er aktivert for — ellers avvises nøkkelen (se avsnittet «Lisens»);TIMEZONE — tidssone for PHP: påvirker bare hvordan panelet viser datoer og klokkeslett. Den påvirker ikke når cron-oppgavene kjøres — der gjelder systemets tidssone (se «Alle cron-oppgaver»).Sesjonstid. SESSION_LIFETIME — tidsavbrudd for inaktiv sesjon i sekunder (glidende: fornyes ved aktivitet). Standard er 28800 = 8 timer; etter denne tiden med inaktivitet ber panelet deg logge inn på nytt. For eksempel 3600 = 1 time, 86400 = ett døgn.
Feillogging. Feil vises aldri for besøkende, men skrives til logs/php_errors.log — de er synlige på siden «Applikasjonslogger». Disse linjene (display_errors=0, log_errors=1, stien error_log) trenger du vanligvis ikke å endre — innstillingene er angitt direkte i filen og avhenger ikke av php.ini.
public/), og for dette panelet er webroten (DocumentRoot) nettopp panelets rotmappe, ikke public/. Filen «lekker» ikke av seg selv: i roten er det i .htaccess et eksplisitt forbud mot den (Require all denied) — serveren returnerer 403. Selv uten denne regelen ville ikke kildekoden lekket: dette er PHP — serveren kjører den, i stedet for å levere den som tekst. For sikkerhets skyld: ikke legg den ut i offentlige kodelagre, og ikke send den til support med et ekte passord. Filrettigheter — 640.
UFW (Uncomplicated Firewall) er et enkelt grensesnitt til nftables/iptables. Det stenger alle innkommende porter unntatt de som eksplisitt er tillatt. Siden «UFW-brannmur» viser status og regler.
ufw enable må du tillate SSH (ufw allow OpenSSH), ellers mister du tilgangen til serveren.
deny-regel, regnes ikke som tilgjengelig utenfra.
Skipping adding existing rule er ikke en feil. UFW melder på denne måten at nøyaktig samme regel allerede finnes, og legger den ikke til på nytt. Ved gjentatt kjøring av autooppsettet (som er idempotent) er dette en normal melding – ingen handling er nødvendig.
Blokkerer automatisk IP-adresser når antallet mislykkede innloggingsforsøk overskrides. Analyserer logger fra SSH, nginx, Apache og andre tjenester.
Grunnleggende installasjon står ovenfor. Her følger en fungerende konfigurasjon som gir dusinvis av aktive jail-er og tusenvis av blokkeringer: felles innstillinger, sentrale jail-er og autoban av skadelige IP-er fra ipsum-lista.
Fila /etc/fail2ban/jail.local — felles innstillinger og de viktigste jail-ene:
ignoreip må du legge inn din egen IP og dine betrodde nett, ellers kan du banne deg selv. Etter endringer: sudo fail2ban-client reload.
Automatisk innlasting av blokklista ipsum — i root-cron (sudo crontab -e): level 1 (100 000+ IP-er) lastes inn i settet ipsum, som avskjæres på brannmuren (mer i avsnittet «Blokklista IPset»):
ipsum — det er nettopp dette dashbordet leser (kortet «IPset ipsum»). Nivåer: levels/1.txt — maksimal dekning, levels/3.txt — mer presist (3+ kilder).
Hvorfor «Sikkerhetsmonitor» er delt i to soner. Beskyttelsen jobber på to nivåer, og dashbordet blander dem ikke:
sshd, apache-*, nginx-* osv.) og notoriske gjengangere (jail-en recidive — de som allerede er bannet flere ganger). Dette er IP-er som faktisk forsøkte å bryte seg inn hos deg — de vises på angrepskartet og «Tidslinjen».ipset ipsum, avskåret på brannmuren med regelen DROP. De fleste av disse adressene har aldri vært i kontakt med serveren din — de kuttes på forhånd; telleren «IPset ipsum» viser hvor mange som er avskåret preventivt.Forskjellen er enkel: reaktivt — «disse angrep og ble bannet», preventivt — «disse ble blokkert før de i det hele tatt forsøkte». Tidligere ble list-3 ipsum kunstig lagt inn i recidive (derav den gamle inndelingen «liste-recidive»); nå er recidive bare ekte gjengangere, mens preventivt kjører helt på brannmuren.
ipsum — en offentlig liste over skadelige IP-er som oppdateres daglig. Monitor viser antall innlastede adresser på dashbordet og angrepskartet og tar det med i sikkerhetsvurderingen (−10 hvis settet ikke er lastet inn).
Den minimale varianten uten fail2ban — et eget sett ipsum med blokkering via iptables:
@reboot. Samtidig setter kommandoen create … -exist grensen maxelem 300000 (standard er 65536 — level 1 får ikke plass og gir «Hash is full»):
ipsum, og hvis brannmuren styres av installasjonsprogrammet (fersk VPS — profilene «Full»/«Lettvekt»), kobles settet til UFW med en DROP-regel — trafikk fra disse IP-ene blir faktisk blokkert. Regelen står etter ESTABLISHED,RELATED, så eksisterende tilkoblinger (inkludert din SSH) brytes ikke — kun nye tilkoblinger fra listen blokkeres. Settet gjenopprettes ved oppstart av tjenesten ipsum-load.service før brannmuren (ellers ville ikke UFW starte opp), og oppdateres av cron kl. 04:00. På en allerede konfigurert server (kontrollpanel, egen brannmur) rører ikke installasjonsprogrammet brannmuren — der forblir ipsum en liste for dashbordet og angrepskartet, mens DROP-regelen kan legges til manuelt ved behov (den minimale varianten med iptables … --match-set ipsum … -j DROP — ovenfor). Ved automatisk installasjon trenger du ikke gjøre noe manuelt.
En moderne erstatning for Fail2ban med kollektiv trusseletterretning: blokkeringer fra fellesskapet pluss egne regler. Krever en egen bouncer for å håndheve blokkeringer i brannmuren.
systemctl is-active crowdsec). Start den: sudo systemctl enable --now crowdsec; ved feil, se sudo journalctl -u crowdsec -n 30. Samme regel gjelder for enhver tjeneste med statusen «Ikke startet» (Suricata, Falco, Monit, MySQL).
stream halted / blokkeringer håndheves ikke. Dette er en foreldreløs api-nøkkel: bounceren ble fjernet fra cscli bouncers list, men den gamle nøkkelen ligger fortsatt i /etc/crowdsec/bouncers/*.yaml. Registrer bounceren på nytt og legg inn en ny nøkkel:
AIDE (Advanced Intrusion Detection Environment) tar et øyeblikksbilde av filsystemet og rapporterer ved hver kontroll om endringer i /etc, /bin, /usr. Etter installasjonen er initialisering av databasen (aideinit) obligatorisk.
aideinit står terminalen 5–15 minutter på linjen Running aide --init... — det er normalt (hashing av hele filsystemet, belastning på disken). Ikke avbryt med Ctrl+C. Hvis prosessen «henger», men ikke skriver noe — venter den kanskje på svar på en skjult forespørsel Overwrite existing aide.db.new [Yn]? (trykk Y). Sjekk aktiviteten fra en annen økt: pgrep -af aide.
aideinit: «21_aide_spamassassin … printf: invalid number» (return code 20) — en kjent feil i AIDE-konfigsnutten i Ubuntu 22.04. Databasen opprettes ikke. Flytt ut den ødelagte snutten og prøv på nytt:
aideinit kjørt, eller (Ubuntu 24.04) er katalogen /var/lib/aide opprettet med rettighetene 700 og utilgjengelig for www-data — løses med sudo chmod 755 /var/lib/aide (se blokken over). «Ingen kontroller er utført» = databasen finnes, men det er ennå ikke utført noen kontroll — det er ikke en feil. Monitor leser resultatene fra /var/log/aide/aide.log.
/etc/cron.daily/aide på nyere Ubuntu/Debian skriver kanskje ikke /var/log/aide/aide.log i riktig format (og aide.wrapper finnes ikke lenger i dem). Det er tryggere å legge til en egen cron-jobb med eksplisitt --config — den skriver loggen som root med rettighetene 644, og Monitor leser den uten ekstra grupper:
chmod 755 /var/lib/aide og cron-kontroll kl. 02:00 — du trenger ikke å gjøre noe manuelt.
sudo aideinit && sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db.
Antivirusskanner for Linux. Spesielt nyttig for å sjekke /var/www for PHP-skjell og skadelig kode.
enable --now? Tre typiske årsaker:
1. Linjen Example står fortsatt i konfigurasjonen — clamd nekter å starte så lenge den er der:
2. Signaturdatabasen er ikke lastet ned — clamd starter ikke uten den:
3. Den holder rett og slett på å laste — clamd laster ~8 mill. signaturer inn i minnet på 30–60 sek. Vent litt og sjekk: systemctl is-active clamav-daemon (status activating → laster fortsatt).
sudo journalctl -u clamav-daemon -n 30 --no-pager.
clamd holder bare signaturene i minnet, den skanner ingenting etter en tidsplan selv. Panelet viser resultatet av en planlagt skanning, så du trenger et cron-jobb som skanner og skriver til logg. Autoinstallasjonen legger inn en wrapper /usr/local/bin/clamav-scan.sh og cron kl. 01:30 — etter første kjøring fylles «Filer sjekket» og «Siste skanning». Kjør umiddelbart uten å vente på tidsplanen: sudo /usr/local/bin/clamav-scan.sh.
Linux Malware Detect (LMD) — en skadevareskanner for webtrusler: PHP-skall, web-bakdører, nedlastere. Bruker ClamAV-motoren og supplerer den med egne signaturer.
maldet --report.
update-rc.d: error: unable to read /etc/init.d/maldet dukke opp — den er harmløs. maldet bruker ikke init.d; oppdatering av signaturer og skanninger kjøres via /etc/cron.daily/maldet. Hvis du ser installation completed nedenfor, er alt installert.
apt, men i /usr/local/maldetect, og når open_basedir er aktivert, sjekkes tilstedeværelsen via shell — se avsnittet «Siden er tom selv om dataene finnes på serveren».
Nettverksbasert system for inntrengingsdeteksjon: analyserer trafikk på pakkenivå og kjenner tusenvis av angrepssignaturer. Utfyller ModSecurity (som jobber på HTTP-nivå, mens Suricata jobber på TCP/IP-nivå).
/var/log/suricata/eve.json som root med modus 750 på katalogen, og webserveren (www-data) kan ikke lese den. Åpne katalogen for gjennomgang – filene inni forblir beskyttet:
Fanger opp systemkall via eBPF/kernel module og oppdager avvik i sanntid: shell fra nginx, lesing av /etc/passwd fra en webprosess, skriving til /bin osv.
journalctl -u falco (uten sudo — via gruppen systemd-journal). Kontroller at www-data er i denne gruppen — se «Oppsett av sudo» (pkt. 2) på siden for manuell installasjon.
/etc/passwd, skriving til systemkataloger). Null kritiske på et døgn på en rolig server er en sunn tilstand.
journalctl krever tilgang til loggen; for at dashbordet skal se hendelser stabilt aktiverer autoinstallasjonen file_output hos Falco → /var/log/falco/falco.log og setter UMask=0022 på tjenesten (loggen leses av webserveren). Ved en ny installasjon trenger du ikke å sette dette opp manuelt.
ModSecurity — en webbrannmur (WAF) for Apache eller Nginx. Blokkerer angrep på applikasjonsnivå: SQL-injeksjoner, XSS, katalogtraversering, skannere.
IncludeOptional /etc/modsecurity/*.conf, mens pakken bare legger inn modsecurity.conf-recommended — som ikke matcher masken *.conf. Kopierer du den ikke til modsecurity.conf, forblir SecRuleEngine Off: modulen er lastet, CRS-reglene er lastet, men trafikken sjekkes ikke og auditloggen opprettes ikke. Mellommodusen DetectionOnly skriver bare hendelser til loggen uten å blokkere forespørsler — panelet viser den med gult.
Panelets tilgang til auditloggen. Loggen /var/log/apache2/modsec_audit.log eies av root (rettigheter 640), og webbrukeren kan ikke lese den. Panelet henter data via en wrapper — opprett den:
SecRuleEngine-direktiv uten innrykk: innrykkede linjer ligger inne i blokker <LocationMatch>/<Directory> (for eksempel avslåing av WAF for phpMyAdmin) og bestemmer ikke den globale modusen.www-data, i HestiaCP kjører nettstedets pool som nettstedseieren (for eksempel admin) — sjekk grep -E '^user' /etc/php/*/fpm/pool.d/monitor.example.com.conf.X-Forwarded-For. Bare transaksjoner der en regel utløste, kommer med i statistikken: direktivet SecAuditLogRelevantStatus skriver alle 4xx/5xx-svar til auditloggen, så vanlige 403/500 havner også der — panelet regner dem ikke som WAF-hendelser.---RULES--- trengs av seksjonen «Alle aktive regler» — panelet viser ikke bare de utløste, men absolutt alle innlastede CRS-regler + egendefinerte. De tre stiene i løkken for f in … er typiske plasseringer for CRS-regler og lokale tillegg; har du en annen oppsett (pakken legger filer i sin egen katalog, eller egendefinerte regler ligger ikke i /etc/modsecurity/custom-rules.conf), finn de reelle stiene med kommandoen sudo grep -rl 'IncludeOptional\|^Include ' /etc/apache2/mods-enabled/security2.conf /etc/apache2/conf-enabled/*.conf 2>/dev/null og sett dem inn i listen. Er wrapperen gammel (uten denne seksjonen) — viser seksjonen bare advarselen «utilgjengelig», resten av siden fungerer som før.
Auditd (Linux Audit Daemon) logger systemkall på kjernenivå: innlogginger og utlogginger, sudo-kommandoer, mislykkede autentiseringsforsøk og filendringer. Monitor viser innlogginger, mislykkede forsøk og sudo-kommandoer i dag.
ausearch (/usr/sbin/ausearch) og ved behov fra /var/log/audit/audit.log med kommandoen tail. Begge må ligge i sudoers.
Overvåker tjenester (nginx, php-fpm, mysql osv.) og starter dem på nytt hvis de faller. Kan sende varsler på e-post.
monit status. I /etc/monit/monitrc må HTTP-grensesnittet være aktivert (blokken set httpd med allow localhost), ellers returnerer monit status en feil.
monitrc er linjen set httpd kommentert ut (som standard står den som # set httpd port 2812 …). Fjern kommentaren fra blokken og tillat localhost. (2) Et aktivert httpd overvåker ikke noe i seg selv — Monit teller bare det som beskrives i check-stanser; uten dem er listen tom selv når grensesnittet kjører. Minimal fungerende konfigurasjon:
conf.d med httpd på 2812 og et sett med sjekker — på en ny installasjon trenger du ikke å sette opp noe manuelt.
PSAD analyserer iptables-loggen og oppdager portskanning og nettverksangrep, og gir hver kilde et trusselnivå (1–5). Utfyller fail2ban og Suricata.
psad --Status (må ligge i sudoers). Uten iptables-logging vil siden være tom — det er normalt så lenge ingen skanninger har forekommet.
Mandatory Access Control begrenser hvilke filer og ressurser et program kan få tilgang til, selv om det er blitt hacket. I Ubuntu/Debian brukes AppArmor som standard (vanligvis allerede installert og aktivt).
aa-status (må ligge i sudoers). Viser antall profiler i modus enforce/complain og prosesser uten profil.
«Profiler lastet» er flere enn enforce + complain — det er normalt. I AppArmor 4.x (Ubuntu 24.04 og nyere) kom det en unconfined-modus: profilen er lastet inn i kjernen, men begrenser ingenting. Ubuntu merker slik titalls profiler for programmer som bruker user namespaces (nettlesere, torrent-klienter og lignende). Når slike profiler finnes, blir kortet «Profiler lastet» ravgult og viser antallet — for eksempel unconfined: 90 ved 120 lastede og 26 i enforce. Bare profiler i enforce gir reell beskyttelse; på Ubuntu 22.04 (AppArmor 3.x) finnes ikke denne modusen, og tallene stemmer alltid.
unconfined over i enforce bør bare gjøres med omtanke: de er ikke slått av ved en feil, men fordi programmene selv ellers slutter å fungere. Profiler i complain er en annen sak: der er reglene allerede skrevet og bare ikke håndhevet.
debsums kontrollerer at filene til installerte pakker stemmer med kontrollsummene fra depotet — avslører utskiftede systembinærfiler (utfyller AIDE). En full kontroll tar 1–2 minutter, derfor kjøres den via cron, og panelet leser resultatet fra data/debsums/debsums.log og sorterer det selv i kategorier (bare binærfiler og biblioteker er viktige).
Oppføringen legges i root-cron (sudo crontab -e). Den ferdige innpakningen debsums-scan.sh legges i /usr/local/bin/ (chmod +x; se oversikten over cron-oppgaver) og skriver selv rapporten til panelets data/debsums/.
Innpakningen debsums-scan.sh finner selv panelets data/ — du trenger ikke oppgi banen.
/etc/ (konfigurasjoner) og /usr/share/ (ressurser) på serveren er vanligvis normale — panelet merker dem med egen farge. Bekymringsfullt er endringer i binærfiler og biblioteker (/bin, /sbin, /usr/lib osv.) — kortet «Binærfiler / biblioteker» viser nettopp disse.
Lynis kjøres manuelt eller via cron. Rapporten må lagres i prosjektmappen data/lynis/ — monitoren leser filen lynis-report.dat.
lynis-scan.sh i bakgrunnen direkte fra panelet (uten å vente på cron): viser «Skanner…» og oppdaterer rapporten selv når den er ferdig. For dette trenger web-brukeren en sudoers-linje for å kjøre skriptet — installasjonsprogrammet legger den til automatisk i /etc/sudoers.d/monitor. Hvis panelet ble installert manuelt/tidligere, legg den til med samme bruker som allerede står i filen:
Logwatch skal lagre daglige rapporter i mappen data/logwatch/ i prosjektet i formatet .txt. Monitor viser den siste rapporten og arkivet.
Nettverksmonitoren krever ingen installasjon — det er en innebygd side i panelet. Den viser serverens nettverkstilstand fra lokale kilder:
/proc/net/dev;ip;ss;journalctl -k.De tre første kildene fungerer uten sudo, så grensesnitt, trafikk, tilkoblinger og porter vises umiddelbart. Blokken «Kjernehendelser» bruker journalctl -k — den leses via gruppen systemd-journal («Oppsett av sudo», pkt. 2), sudo trengs ikke. Kontroller at alt er tilgjengelig for webbrukeren:
UFW BLOCK havner ikke her — de finnes på sidene «UFW-brannmur» og «Angrepskart». Tom blokk med grønn hake = ingen nettverksfeil siste døgn.
Den innebygde siden viser tre ting:
df); skalaen blir rød ved ≥90 %;lsblk), kun reelle (loop/snap er skjult);smartctl).Diskplass og enhetslisten fungerer med én gang, uten oppsett. For SMART trengs pakken smartmontools. Webprosessen har ikke direkte tilgang til diskenhetene, derfor hentes SMART via cron til filen data/disk/smart.txt, og panelet leser den.
Jobben ligger i root-cron (sudo crontab -e). Den ferdige innpakningen smart-scan.sh legges i /usr/local/bin/ (chmod +x; se oversikten over cron-jobber) og skriver selv til panelets data/disk/.
Innpakningen smart-scan.sh finner selv panelets data/ — banen trenger du ikke å angi. Inne i den ekskluderer lsblk -e7,11 loop/cdrom.
Siden viser historikken over serverbelastningen de siste 24 timene — Load Average, CPU-bruk og I/O-venting, RAM/Swap, nettverkstrafikk (mottak/sending), disk-I/O (lesing/skriving), diskfylling og inodes, åpne fildeskriptorer og MySQL-tilkoblinger, pluss gjeldende antall TCP-tilkoblinger og prosesser.
Dataene samles inn av cron/collect_metrics.php — hvert 5. minutt skrives ett «rått» øyeblikksbilde av tellerne (/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') til databasetabellen system_metrics; prosenter og hastigheter regner siden ut selv fra differansen mellom nabosnapshots (diskfylling/inodes/deskriptorer/MySQL-tilkoblinger er øyeblikksverdier, uten omregning). Sudo trengs ikke — kildene leses uten root-rettigheter. Punkter eldre enn 24 timer slettes automatisk ved hver skriving.
Wrapperen collect-metrics-all.sh (se oversikten over cron-oppgaver) finner selv alle installerte panelinstanser på serveren og kjører hver enkelts cron/collect_metrics.php som eier av nettstedet.
Belastningsvarsler (seksjonen «Innstillinger» → «Belastningsvarsler») — når terskelen for CPU/RAM/disk/inodes overskrides, sender panelet et varsel til Telegram/Email (de samme kanalene som den daglige rapporten — de trenger ikke slås på separat for varsler), og enda ett når metrikken har normalisert seg. Det spammer ikke på nytt mens terskelen holdes: neste varsel kommer først etter en syklus «normalisert → overskredet igjen».
collect_metrics.php ved hver kjøring (hvert 5. minutt) — egen cron trengs ikke. Tilstanden «allerede varslet / ennå ikke» lagres i data/alerts_state.json, tersklene i panelinnstillingene.
Siden «Angrepskart» finner landet ut fra IP-adressen med kommandoen geoiplookup. Uten GeoIP-pakken blir ikke landene funnet, og punktene vises ikke på kartet:
/usr/share/GeoIP/GeoIP.dat kan leses av alle, og resultatene bufres i tmp/geoip_cache.json. Selve kartet (Leaflet + fliser fra OpenStreetMap) lastes i nettleseren — det kreves internett på maskinen der dashbordet er åpent.
To innebygde dashbordkort som viser ikke «på/av» for et verktøy, men serverens faktiske sikkerhet. Krever ingen installasjon, leses lokalt uten sudo.
Ekstern eksponering — hvor mange tjenester som lytter på alle grensesnitt (0.0.0.0/[::]) og er tilgjengelige utenfra. Markerer med rødt hvis en database eller cache er eksponert (MySQL, PostgreSQL, Redis, MongoDB, Memcached, Elasticsearch) — det er et direkte sikkerhetshull (−10 på sikkerhetsvurderingen). Kilde: ss -tuln.
127.0.0.1 (bind-address i MySQL/PostgreSQL-konfigurasjonen, bind 127.0.0.1 i Redis) eller steng porten i UFW.
127.0.0.1 (loopback) er kun synlig for serveren selv — den kan ikke nås utenfra, selv om porten er «åpen». Derfor er Postfix på port 25 bundet til loopback trygg: autokonfigurasjonen setter inet_interfaces = loopback-only (pluss et nøytralt smtpd_banner — som lukker Lynis-merknaden MAIL-8818 om versjonseksponering). Kortet «Ekstern eksponering» regner som eksponert kun det som lytter på 0.0.0.0/[::]; loopback-tjenester teller ikke med.
smtpd_banner = $myhostname ESMTP (uten versjon og OS) og inet_interfaces = loopback-only i /etc/postfix/main.cf, og kjør deretter sudo systemctl restart postfix.
Sikkerhetsoppdateringer — hvor mange sikkerhetsoppdateringer som venter på installasjon og om en omstart trengs etter kjerneoppdatering (−5 på sikkerhetsvurderingen hvis det finnes oppdateringer). Kilde: /usr/lib/update-notifier/apt-check, filen /var/run/reboot-required. Detaljert liste — på siden «Sikkerhetsoppdateringer».
update-notifier-common). Hvis apt-check mangler — teller Monitor oppdateringene via apt-get -s upgrade.
Automatiske sikkerhetsoppdateringer (unattended-upgrades) — på siden «Sikkerhetsoppdateringer» viser et eget kort om automatisk installasjon av sikkerhetsoppdateringer er aktivert og når den sist ble kjørt. Sudo trengs ikke — statusen leses via apt-config dump.
Sikkerhetskopi er den viktigste forsikringen: tap av data er verre enn ethvert innbrudd. Du trenger to ting — sikkerhetskopi av server/nettsteder og separat en sikkerhetskopi av panelets database (der ligger brukere, WebAuthn-nøkler, innstillinger og lisensen).
Alternativ A — HestiaCP: fanen Backup hos brukeren → knappen for å lage sikkerhetskopi (eller etter tidsplan i serverinnstillingene). Sikkerhetskopien inkluderer nettsteder og databasene deres.
Alternativ B — manuelt (cron): databasedump + arkiv av panelets katalog data/:
Oppdatering til ny versjon. Ta først en sikkerhetskopi. Last deretter opp kodefilene på nytt, og behold dataene dine:
public/, includes/, assets/, cron/, database/, samt .htaccess i rota (frontkontrolleren — rutingen kan ikke beholdes fra den gamle versjonen), manifest.json, sw.js;config.php (databasedata), data/ (rapporter), logs/, tmp/ (økter og buffer).SSH_FX_PERMISSION_DENIED – Permission denied. Panelets filer eies av www-data (slik ble de satt under installasjonen), mens SFTP-klienten kobler til som din egen bruker, som ikke har skriverettighet. Å gi www-data hele panelet «for at det skal virke» er nettopp det som fører til denne feilen; nedenfor er tre måter, alle løser problemet.
data/ (rapporter), tmp/ (økter og buffer), logs/; de forblir hos www-data. Resten er kode, og nettserveren trenger den kun til lesing, som gruppen www-data gir med rettighetene 644. En sidegevinst: ved en PHP-sårbarhet kan ikke panelets filer lenger overskrives. På hosting-paneler (HestiaCP og lignende) trengs ikke alternativ A: der eies nettstedets filer uansett av kontoen du logger inn med via SFTP, og nettserveren leser dem via gruppen.
chmod på filene nullstiller ACL-masken, og tilgangen forsvinner stille. Hvis opplastingen etter en «opprydding i rettighetene» igjen stopper på Permission denied – kjør begge setfacl-kommandoene på nytt.
2 i alternativ C er setgid: filer som lastes opp via SFTP blir værende i gruppen www-data, ellers kan ikke panelet overskrive dem. Etter alternativ C – koble til på nytt i FileZilla: den nye gruppen trer i kraft først ved en ny innlogging. Kontroll: id deploy (gruppen www-data skal dukke opp) og ls -ld /path/to/monitor (drwxrwsr-x – bokstaven s betyr at setgid er satt).
Flytting til en annen server:
config.php, data/.mysqldump på den gamle → import på den nye; oppdater databasedataene i config.php.adm, cron-jobber.Hvis du ikke får logget inn, kan alt fikses direkte i databasen fra serveren. Åpne databasen (navnet finner du i config.php):
Mistet WebAuthn-nøkkel (den andre faktoren feiler) — slå av 2FA, logg inn med passord og registrer en ny nøkkel:
Glemt passord — sett en ny hash (generer den på serveren og lim den inn):
Låst deg selv ute med IP-filteret — slå av begrensningen:
sudo mysql på serveren, eller phpMyAdmin / databaseseksjonen i hostingpanelet. Etter gjenopprettingen må du slå på WebAuthn og IP-filteret igjen.
Oversikten over jobber ligger i server-cron for root (legges til via sudo crontab -e). Behold bare linjene for verktøyene du bruker, og juster stiene til din egen server.
sudo crontab -l og at cron-tjenesten er aktiv.
TIMEZONE fra config.php. Konstanten TIMEZONE påvirker bare PHP (hvordan panelet viser datoer), men cron-demonen kjører jobbene etter operativsystemets systemtid. Hvis serverens sone ikke stemmer med din, kommer «08:00»-rapporten på feil tidspunkt. Eksempel: serveren står i en annen sone (Europe/London, UTC+1), og du er i Oslo (UTC+2) → «08:00»-rapporten kommer 09:00 for deg. Sjekk og juster ved behov systemets sone til din egen:
0 8 * * * klokka 08:00 lokal tid. Ellers måtte du forskyve selve cron, men ved overgang til vinter-/sommertid ville forskyvningen igjen komme ut av takt — derfor er det riktigere å stille inn systemets sone.
crontab.txt) ligger i mappen system/ ved siden av prosjektet, utenfor public_html. Dette er ikke en del av nettstedet — de skal ikke lastes opp til web-roten; plasser dem på serveren etter systemstiene (som i crontab over):
lynis-scan.sh → /usr/local/bin/ (chmod +x) — kjører lynis audit system, setter flagget /tmp/lynis-running under skanningen og kopierer lynis-report.dat til panelets data/lynis/;logwatch_daily.sh → /usr/local/bin/ (chmod +x) — lager en daglig Logwatch-rapport (sshd, fail2ban, sudo, postfix) i data/logwatch/;smart-scan.sh → /usr/local/bin/ (chmod +x) — henter diskstatus (smartctl) til data/disk/;debsums-scan.sh → /usr/local/bin/ (chmod +x) — sjekker pakkeintegritet (debsums) i data/debsums/;clamav-scan.sh → /usr/local/bin/ (chmod +x) — ClamAV-antivirusskann av utsatte stier (web, home, temp); skriver en oversikt til /var/log/clamav/scan.log, der ClamAV-siden leser den fra (linjen 01:30 i crontab over);load-ipsum.sh → /usr/local/bin/ (chmod +x) — oppdaterer ipset-settet ipsum (level 1) på stedet, uten å bryte de aktive brannmurreglene (linjen 04:00 i crontab over);daily-report-all.sh → /usr/local/bin/ (chmod +x) — kjører panelets rapport cron/daily_report.php (linjen 08:00 i crontab over);daily_report.php — inngår allerede i panelet (cron/daily_report.php), kjøres via daily-report-all.sh, trenger ikke settes opp separat;collect-metrics-all.sh → /usr/local/bin/ (chmod +x) — kjører panelets cron/collect_metrics.php (siden «Ytelse», linjen */5 i crontab over); collect_metrics.php inngår allerede i panelet, trenger ikke settes opp separat;crontab.txt (system/cron/) — eksempel på jobber; skriv inn de linjene du trenger via sudo crontab -e./usr/local/bin/. Du kan ikke skrive dit direkte fra FileZilla — katalogen tilhører root, og SFTP-klienten får SSH_FX_PERMISSION_DENIED. Fremgangsmåten er slik: last først filen opp til /tmp (der kan alle skrive), og flytt den så på plass med én kommando:
/tmp i serverens rot — ikke /var/tmp og ikke tmp/ inne i selve panelet (sistnevnte tilhører www-data og er stengt for din bruker). I FileZilla-treet er /tmp en gren på øverste nivå, ved siden av var, ikke inne i den.
/usr/local/bin/, logg — /var/log/arciveo-cron.log) — du trenger ikke gjøre noe manuelt.
/home/*/web/*/public_html og /var/www/*, og legger rapportene i deres data/. Hvis panelet ligger på en annen sti — legg den til i linjen for app in … inne i skriptene, ellers havner ikke rapportene fra Lynis/SMART/debsums/Logwatch i panelet.
logs/cron.log opprettes først av root-cron — den vil tilhøre root, og fanen «Cron-logg» i panelet kan verken lese eller tømme den. Opprett filen på forhånd som web-brukeren (eier av nettstedskatalogen; på HestiaCP er dette kontoen, f.eks. admin) — da vil root-cron bare skrive til den uten å endre eier:
stat -c %U /path/to/monitor.
sudo crontab -e), ellers kjøres den to ganger.
sudo crontab (det ville vært direkte eskalering til root for hvem som helst som får tilgang til paneløkta), men et smalt skript med to kommandoer (list/set), som bare rører sin egen blokk mellom tjenestekommentarene. Installer én gang:
www-data — sjekk hvilken bruker nettstedets PHP-FPM-pool kjører under (ps -o user= -C php-fpm), og sett den inn i sudoers-linjen.
public/crontab_monitor.php er lastet opp via FTP/SFTP under en annen systembruker (for eksempel root) enn resten av nettstedets filer, kan webserveren ikke lese den. Sammenlign eier og rettigheter med en nabofil og bring dem i samsvar:
Monitor oppdager tilgjengelige verktøy via dpkg-query — pakkedatabasen til APT. Hvis verktøyet ikke er installert via apt (manuelt, fra snap eller fra kildekode), ser ikke dpkg det.
Feil 500 — sjekk loggene til PHP, nginx og selve monitoren:
www-data, men som brukerkontoen (for eksempel admin — eier av nettstedskatalogen). Alle sudo-regler og gruppemedlemskap (adm, systemd-journal) må settes opp for denne brukeren, ellers viser modulene «Ikke aktiv / 0» selv om tjenestene kjører. Finn den faktiske PHP-brukeren: ps -o user= -C php-fpm | sort -u eller eieren av nettstedskatalogen stat -c '%U' /path/to/monitor. Bruk deretter denne i stedet for www-data i alle kommandoene under. Autoinstallasjonen finner nettbrukeren selv og setter opp sudoers for den.
Data vises ikke — nesten alltid manglende sudo-rettigheter. Sjekk den aktuelle kommandoen som nettbruker (bytt ut www-data med din egen). Flagget -n = uten passord, slik som PHP — hvis den ber om passord, finnes ikke regelen i sudoers:
sudo aa-status i terminalen viser profiler, mens siden «AppArmor» viser «Inaktiv»). Årsak: nettbrukeren mangler sudo-rettighet til kommandoen for denne modulen. Sjekk den fra listen over: hvis den ber om passord — legg til den manglende linjen i /etc/sudoers.d/monitor («Sudo-oppsett»). Vanlige «nye» kommandoer: /usr/sbin/aa-status (MAC), /usr/sbin/psad --Status (PSAD).
apache2ctl, ausearch, aa-status eller ss tillatt, eller nettbrukeren er ikke i gruppene adm/systemd-journal (derfra leses loggene til fail2ban/auth/modsec og journalctl — Falco og kjernehendelser).
Symptom: det finnes data på serveren (synlig via shell), men siden viser «ingen data» eller feil status — for eksempel skriver AIDE «Ikke initialisert» selv om databasen er opprettet.
Årsaken er open_basedir: mange paneler og hostinger begrenser PHP-FPM-poolen til domenets katalog, så PHP-funksjonene file_exists(), file_get_contents(), filemtime() blokkeres for systemstier (/var/lib/aide, /var/log, /proc…). Monitor omgår dette ved å lese slike stier med vanlige systemkommandoer (cat, test, stat).
open_basedir. Riktig løsning er lesing via systemkommandoer (allerede gjort for AIDE og Nettverksmonitor). Å utvide open_basedir til /var, /proc er unødvendig og mindre sikkert.
Monitor sjekker sertifikater ved å koble seg direkte til domenene via port 443. Hvis domenet ikke er tilgjengelig fra serveren selv, eller porten er blokkert av brannmuren, feiler kontrollen.
/etc/nginx/sites-enabled/, /etc/nginx/conf.d/) og Apache (/etc/apache2/sites-enabled/), pluss den nåværende verten fra HTTP_HOST.
Monitor kobler til MySQL med brukeren fra config.php, som bare har tilgang til sin egen database. MySQL viser i information_schema kun databaser med rettigheter — derfor er de andre ikke synlige.
For at Monitor skal se alle databaser, gi denne brukeren lesetilgang (én gang som root; sett inn brukernavnet fra config.php):
sudo mysql: databaselisten hentes via dets egen PDO-tilkobling.
PostgreSQL krever tilgang på nivå med brukeren postgres, som panelets nettbruker ikke har. Å åpne en bred sudo psql fra PHP er utrygt – i stedet kaller panelet en snever innpakning uten parametere, som kun skriver ut versjon, antall tilkoblinger og listen over databaser med størrelser. Opprett den:
monitor-pgstat fra sudoers (steg 13 i manuell installasjon) og la være å opprette selve skriptet: PostgreSQL-kortet forblir bare inaktivt.
Dashbordet viser hva som skjer; nedenfor står hva du skal gjøre i typiske situasjoner. Grunnprinsippet: ikke få panikk, sammenlign med legitim aktivitet (dine handlinger, oppdateringer, sikkerhetskopier), og reager etter alvorlighetsgrad.
ignoreip./etc, utenfor /usr/share) – mulig utbytting. Sjekk pakken: debsums PACKAGE_NAME, og installer den på nytt ved tvil (apt install --reinstall).127.0.0.1 eller steng porten i UFW. Dette er et reelt sikkerhetshull.certbot renew eller innstillingene i dashbordet).sudo apt update && sudo apt upgrade; start serveren på nytt etter en kjerneoppdatering.