Dette er en veiledning for installasjon, konfigurasjon og vedlikehold av Arcivéo Security 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 Security 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.
To arbeidsrytmer. Sidene i panelet spør verktøyene i det øyeblikket du åpner dem — du ser alltid den aktuelle tilstanden. I tillegg kjører bakgrunnsjobber etter en plan (cron):
Hele listen over jobber finnes i avsnittet «Alle cron-jobber på ett sted».
Scoren starter på maksimum og reduseres for hvert problem som oppdages:
PermitRootLogin yes) — −20PasswordAuthentication yes) — −10X11Forwarding slått på, MaxAuthTries over 3 eller sshd_config lesbar for alle kontoer — −5TRACE er slått på, eller headeren Strict-Transport-Security eller X-Frame-Options mangler — −5Resultat: 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.
Det finnes fire kanaler: Telegram, e-post, webhook og push i nettleseren. De er uavhengige av hverandre — slå på dem du vil, gjerne alle fire. Over de samme kanalene går den daglige sikkerhetsrapporten, belastningsvarslene og funnene fra hendelsessensoren; de settes opp én gang, her, i avsnittet «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.Webhook. Én enkelt adresse som tar imot en POST dekker Slack, Discord, Mattermost, n8n og din egen behandler. «Innstillinger» → Webhook: lim inn adressen og slå på bryteren.
{"text": …}, til Discord {"content": …} (Discord avviser meldinger på over 2000 tegn, så teksten kortes ned);text, event, severity, source, count, host, ts — meldingsteksten trenger ikke tolkes på nytt.Push-varsler. Meldingen kommer rett i nettleseren, og hvis panelet er lagt til på telefonens startskjerm, som et vanlig appvarsel — uten bot og uten e-postserver imellom. «Innstillinger» → Push-varsler: slå på bryteren og trykk «Koble til denne enheten» på hver enhet som skal motta varsler. Telleren «Tilkoblede enheter» viser hvor mange de er.
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.
Panelet er stengt bak innlogging med passord og, dersom det er slått på, bak IP-filteret. For et program passer ingen av delene, så eksterne systemer har sin egen inngang — to adresser kun for lesing, beskyttet med et token. Tokenet endrer ingenting på serveren: med det kan man bare hente tall.
Slå på — «Innstillinger» → «API kun for lesing»: bryteren «Slå på API»; tokenet opprettes automatisk ved første lagring. Knappen «Nytt token» utsteder et annet og stenger i samme øyeblikk ute alle som brukte det forrige.
/api/status.php — JSON: sikkerhetsscore, modulenes tilstand, siste belastningsmåling med de tyngste prosessene og sikkerhetshendelsene de siste 24 timene;/api/metrics.php — de samme tallene i Prometheus’ tekstformat (målene arciveo_*: arciveo_security_score, arciveo_fail2ban_banned, arciveo_cpu_busy_pct og så videre).Kan klienten din ikke sette en header, tas tokenet også imot som parameter — ?token=…. Vær klar over at det i den formen havner i webserverens tilgangslogg, så headeren er å foretrekke.
Prometheus. En ferdig blokk til scrape_configs:
api disabled — API-et er slått av i innstillingene. Avviste forespørsler skrives til applikasjonsloggen sammen med avsenderens IP, så gjetting på tokenet vises på siden «Applikasjonslogger».
Panelet installeres på hver server for seg og svarer godt på spørsmålet «hvordan står det til med denne maskinen». På spørsmålet «hvordan står det til med alle maskinene mine» svarer det ikke — derfor kan hvert panel sende et kort sammendrag til kontoen, der serverne vises i én liste.
Det du henter på kontoen my.arciveo.com → avsnittet «Mine servere»: der utstedes et token (på formen fk_…), og mottakerens adresse oppgis: https://my.arciveo.com/api/fleet.php. Tokenet er ett per konto — det samme for alle serverne dine.
Det du stiller inn i panelet — «Innstillinger» → «Serveroversikt»: mottakerens adresse, tokenet, servernavnet (slik det står i listen; lar du det stå tomt, brukes panelets domene) og bryteren «Send sammendraget». Knappen «Send nå» prøver forbindelsen med én gang, uten å vente på planen.
Videre går sammendraget via cron, hvert 15. minutt:
Hva som nøyaktig sendes: serverens navn og domene, operativsystem, oppetid, PHP-versjon; sikkerhetsscoren; modulenes tilstand (UFW, antall Fail2ban-jails, dagens blokkeringer, om CrowdSec, Suricata og Falco kjører, ClamAV-trusler, AIDE-endringer, Lynis-indeks, ventende oppdateringer, om omstart trengs, dager til sertifikatet utløper, antall farlig åpne porter); siste belastningsmåling (load, CPU, RAM, disk, inoder); hendelsestellerne for de siste 24 timene og den siste kritiske hendelsen. Logger, passord og filinnhold finnes ikke i sammendraget.
sudo crontab -l) og hva knappen «Send nå» svarer. Sendefeil skrives til applikasjonsloggen med merket FLEET — der ser du om tokenet ble avvist (HTTP 401), eller om selve forbindelsen aldri kom i stand.
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. Vinduet på 24 timer er standard: knappene øverst bytter det til 7 dager eller 30 dager.
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.
To lagringsdybder. De «rå» femminutters øyeblikksbildene lever ett døgn (pluss en time margin, slik at det eldste punktet i grafen fortsatt har en forgjenger å regne mot). Hver avsluttet time foldes til én rad; denne timeserien tas vare på i 30 dager, og det er nettopp den visningene «7 dager» og «30 dager» leser. En måneds historikk koster dermed omtrent 720 rader i stedet for rundt 8600.
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.
Tyngste prosesser. Under grafene står to tabeller med de fem prosessene som bruker mest CPU:
Begge tabellene beskriver alltid de siste 24 timene, selv når grafene viser en måned: et øyeblikksbilde av prosessene finnes bare i femminuttersradene, og de tas ikke vare på lenger enn ett døgn.
ps, PHP-skriptet som samler inn, og cron/sudo-kjeden over det) holdes utenfor listen — ellers ville de ligget øverst i hvert øyeblikksbilde: ps viser nesten 100 % CPU i det øyeblikket den starter. Andre cron-jobber som kjørte samme minutt kommer derimot med, og det er nettopp det tabellen er til for.
Belastningsvarsler (avsnittet «Innstillinger» → «Belastningsvarsler») — når terskelen for CPU/RAM/disk/inoder overskrides, sender panelet et varsel over alle påslåtte kanaler (Telegram, e-post, webhook, push — de samme som for dagsrapporten; for varslene trenger ingenting slås på ekstra), og enda ett når verdien er tilbake på normalt nivå. Så lenge terskelen holdes, gjentas det ikke: neste varsel kommer først etter en syklus «ble normal igjen → ble overskredet på ny».
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.
Dagsrapporten svarer på spørsmålet «hvordan står det til med serveren». Sensoren svarer på et annet — «hva skjedde akkurat nå». Hvert 5. minutt spør den de raske kildene og noterer bare det som har endret seg siden forrige kontroll; siden «Sikkerhetshendelser» i menyen viser listen over funn.
De trege kontrollene — Lynis, debsums, pakkeoppdateringer, SSL-utløp — rører sensoren ikke: tallene deres endrer seg uansett bare én gang i døgnet og hører til dagsrapporten.
Hva den legger merke til — ni kilder:
[Priority: 1] løfter funnet til kritisk;FOUND-linjer i skanneloggen;root (kritisk) og en innlogging fra en adresse som ikke er sett før (advarsel);Et verktøy som ikke er installert, eller som panelet ikke får lest loggen til, tier ganske enkelt — det er verken en feil eller en hendelse.
data/secwatch_state.json), og den første kjøringen skriver bare dette merket. Ellers ville en påslått overvåking gitt et varsel om alt loggene har samlet opp gjennom måneder.
Oppsett — «Innstillinger» → «Overvåking av hendelser»:
23-7 der advarsler ikke sendes.Varslene går over de samme kanalene som dagsrapporten (Telegram, e-post, webhook, push) — ingenting må slås på ekstra. Alle funn skrives til listen uavhengig av om et varsel ble sendt, og tas vare på i 90 dager.
Hendelseslisten. Filtre: periode (24 timer, 7, 30 eller 90 dager), alvorlighet og kilde; de siste 500 oppføringene vises. Knappen «Sjekk nå» kjører nøyaktig samme gjennomgang som cron — praktisk rett etter oppsettet, så du slipper å vente fem minutter; den oppgir også grunnen når ingen varsler ble sendt («under alvorlighetsterskelen», «stille timer», «ingen varslingskanal er satt opp»). Den røde telleren ved menypunktet er antallet kritiske hendelser de siste 24 timene.
Adressekortet. Et klikk på en rad i hendelseslisten eller i blokken Relaterte adresser åpner alt som er kjent om én adresse: tidslinjen over hendelsene, landet og på første linje en konklusjon. En rad i listen åpner kortet når hendelsen gjelder nøyaktig én adresse; nevner den flere, er det adressene inne i raden som er lenker. Det finnes fire konklusjoner:
Under tidslinjen ligger blokken Hva som skjedde på serveren samtidig: hendelser som ikke har noen adresse i det hele tatt. AIDE vet ikke hvem som endret filen, ClamAV vet ikke hvem som tok med den infiserte. Vist er de som faller innenfor adressens aktivitet og de seks timene etter. Det er nettopp innloggingen sammen med det som fulgte, som skiller et forsøk fra faktisk tilgang.
Plan. Jobben legges i roots crontab (sudo crontab -e), forskjøvet 2 minutter i forhold til måleinnsamlingen, slik at de to ikke starter samtidig:
php cron/security_watch.php. Wrapperen finner alle installasjoner av panelet på serveren og kjører kontrollen på vegne av nettstedets eier — med nøyaktig de sudo-rettighetene panelet bruker fra weben. Et direkte kall fra roots crontab ville opprettet tilstandsfilen data/secwatch_state.json med root som eier, og knappen «Sjekk nå» ville sluttet å virke.
Siden «Webserver» analyserer tilgangsloggen og viser hvor mange forespørsler det var, hvor stor del av dem som endte med feil, og hvem som sto bak. ModSecurity svarer på spørsmålet «hva ble blokkert», denne siden på spørsmålet «hva kom i det hele tatt inn på nettstedet».
Hva som vises: antall forespørsler, RPS, feilandel, en egen 5xx-teller og datamengden som er levert; en graf over forespørsler per time; fordelingen av kodene 2xx/3xx/4xx/5xx; hyppige adresser, hyppige IP-adresser, hyppige feil (kode pluss sti) og klienter (User-Agent). Perioden: 24 timer eller 7 dager.
Kilden er tilgangsloggen i formatet combined, så både Nginx og Apache passer, og ingen ekstra modul trengs. Panelet leter etter loggen blant standardfilene:
/var/log/nginx/access.log/var/log/apache2/access.log/var/log/apache2/other_vhosts_access.log/var/log/httpd/access_logI tillegg sjekker panelet filer med navnene *access*.log og *requests*.log i /var/log/nginx/, /var/log/apache2/ og /var/log/httpd/. Slik finnes også en logg som et nettsted skriver til sin egen fil med direktivet CustomLog — for eksempel arciveo-monitor_requests.log, som Arcivéo-installasjonsprogrammet oppretter.
Bare én logg leses: når Nginx står foran Apache, ville en summering av to logger telt hver forespørsel to ganger. Panelet tar den første loggen i listen ovenfor som er skrevet til det siste døgnet (filene funnet via navnemønster prøves etterpå, nyeste først); er det ikke skrevet til noen på et døgn, tas den sist endrede ikke-tomme. En logg som logrotate har tømt, eller som er igjen etter en stoppet webserver, skjuler derfor ikke den aktive. Den siste delen av loggen leses (3 MB), og resultatet mellomlagres i 5 minutter — på et travelt nettsted kan den valgte perioden derfor være ufullstendig dekket; den faktiske dekningen står over grafen.
adm, og webbrukeren er ikke med i den. Arcivéo-installasjonsprogrammet legger webbrukeren til i gruppen; etter en manuell installasjon hjelper en liten wrapper fra root som får gjøre nøyaktig én ting — skrive ut loggen (ModSecurity-siden fungerer på samme måte). Wrapperen velger loggen etter de samme reglene som panelet. Kommandoen vises på selve siden; her er den også. Lim den inn i sin helhet — det er én kommando:
Webbrukeren kan være en annen enn www-data — sjekk hvilken bruker nettstedets PHP-FPM-pool kjører som (ps -o user= -C php-fpm), og sett den inn i sudoers-linjen. Inneholder loggens navn verken access eller requests, legger du stien til i starten av linjen L=… inne i wrapperen.
Forsøk med kjente exploits. Panelet sammenligner forespørsler i loggen med signaturer for rundt tjue utbredte exploits: PHP-CGI, katalogtraversering i Apache, PHPUnit, Log4Shell og sårbarheter i rutere, kameraer og VPN-gatewayer. For hvert forsøk oppgir det om det kan virke på denne serveren, ut fra fakta: installerte versjoner av Apache og PHP, om Java finnes, og hvilken svarkode serveren ga på filforespørselen. Bare det som faktisk kan virke, markeres med rødt.
Herding av webserveren. Panelet ber om hvert nettsted på serveren via 127.0.0.1 og kontrollerer hva en besøkende mottar: om versjonene av webserveren og PHP er synlige, om metoden TRACE er slått på, og om beskyttelsesheaderne Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy og Content-Security-Policy finnes. Nettstedene hentes fra adressen panelet åpnes på og fra filene for virtuelle verter, hvis panelet kan lese dem. Resultatet oppdateres hvert 10. minutt.
Mangler noe, vises én kommando under tabellen. Den lager en egen fil, zz-arciveo-hardening.conf, og laster webserveren på nytt først når konfigurasjonstesten er bestått; headere som nettstedet allerede sender, dupliseres ikke. CSP tilbys ikke som én linje: policyen bygges for det konkrete nettstedet, ellers slutter det å laste sine egne skript, stiler og skrifter. Angre endringen på Apache:
ServerSignature) markeres ikke når webserverens versjon allerede er skjult: uten versjon viser den bare servernavnet og vertsnavnet.
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.Panelet kjører allerede, og på den samme serveren trengs det enda et nettsted — med eget domene ved siden av monitoren. Etter det automatiske oppsettet er serveren en helt vanlig Apache + PHP-FPM, så nettstedet trenger tre ting: sin egen katalog, sin egen vhost og sitt eget sertifikat. Panelet rører du ikke: det overvåker hele serveren, og en andre kopi for det andre domenet er ikke nødvendig.
site2.example.com er adressen til det nye nettstedet. Det kan være både et eget domene (mycompany.com) og et underdomene (shop.mycompany.com) — for Apache er det ingen forskjell, bare DNS-oppføringen (trinn 1) og utstedelsen av sertifikatet (trinn 5) er ulike. site2 er bare et kort navn på nettstedet: slik heter katalogen /var/www/site2 og konfigurasjonsfilen site2.conf. Det har ingenting med domenet å gjøre, Apache henter adressen bare fra ServerName; navnet kan være hva som helst — for shop.mycompany.com er for eksempel shop praktisk: katalog /var/www/shop, konfigurasjon shop.conf.
1. DNS. Opprett i DNS-panelet hos registraren din en A-oppføring mot IP-adressen til denne serveren:
Sjekk etter noen minutter: dig +short site2.example.com skal returnere IP-adressen til serveren.
2. Katalogen til nettstedet.
3. vhost. Blokken limes inn i terminalen i sin helhet — stien til PHP-FPM-socketen finnes automatisk:
4. Slå på nettstedet og sjekk konfigurasjonen før du laster inn på nytt:
5. SSL. certbot er allerede installert av det automatiske oppsettet; DNS må på dette tidspunktet peke mot serveren:
Et tredje domene og de neste legges til på samme måte — gjenta trinn 1–5 med et annet domene og en annen katalog.
Host ikke stemmer med noe ServerName (besøk via IP eller et fremmed domene som peker mot serveren din), leverer Apache det alfabetisk første aktiverte nettstedet fra /etc/apache2/sites-enabled/. Standard 000-default slås av av det automatiske oppsettet, så denne «vakt»-rollen blir hos vhosten til panelet (arciveo-monitor.conf) — det påvirker ikke nettsteder som åpnes med sitt eget navn. Skal et annet nettsted åpnes via IP, gi filen et navn som kommer først alfabetisk (for eksempel 000-site2.conf).
site2_error.log og site2_access.log i /var/log/apache2/.
.htaccess (frontkontroller), og et nøstet nettsted ville levert noe annet enn du venter. Hold nettstedene ved siden av hverandre: /var/www/monitor, /var/www/site2.
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;security-watch-all.sh → /usr/local/bin/ (chmod +x) — kjører panelets cron/security_watch.php på vegne av nettstedets eier (siden «Sikkerhetshendelser», linjen 2-57/5 i crontab over); security_watch.php hører allerede til panelet og trenger ingen egen installasjon;fleet-push-all.sh → /usr/local/bin/ (chmod +x) — sender serverens sammendrag til kontoen via panelets cron/fleet_push.php (linjen 3,18,33,48 over);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.