En ny server på internett blir skannet etter svakheter i løpet av minutter. Det er ikke personlig – det er roboter som prøver vanlige passord og kjente sårbarheter på alle IP-adresser de finner. Gode grunninnstillinger stopper det meste av dette. Kommandoene under er for Ubuntu og Debian; der AlmaLinux og Rocky Linux skiller seg ut, står det egne eksempler.
1. Logg inn med SSH-nøkler, ikke passord
Passord kan gjettes, nøkler i praksis ikke. Lag et nøkkelpar på din egen maskin og legg den offentlige nøkkelen på serveren:
# På din egen maskin
ssh-keygen -t ed25519 -C "navn@firma.no"
ssh-copy-id deploy@din-serverLag en egen bruker med sudo
Ikke jobb som root til daglig. Opprett en vanlig bruker og gi den sudo-rettigheter, slik at administrative kommandoer krever et bevisst valg:
adduser deploy
usermod -aG sudo deploy # Ubuntu/Debian
# usermod -aG wheel deploy # AlmaLinux/RockySlå av passord- og root-innlogging
Når du har bekreftet at nøkkelinnlogging fungerer, stenger du for passord og direkte root-innlogging. Legg innstillingene i en egen fil:
# /etc/ssh/sshd_config.d/10-herding.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
# Test konfigurasjonen før du laster den inn
sudo sshd -t && sudo systemctl reload ssh # sshd på AlmaLinux/Rocky2. Brannmur: blokker alt du ikke trenger
Prinsippet er enkelt: alt innkommende blokkeres, og du åpner bare portene tjenestene dine faktisk bruker. For en vanlig webserver er det SSH, HTTP og HTTPS. Databaser som PostgreSQL og MariaDB skal normalt ikke være åpne mot internett i det hele tatt.
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbosePå AlmaLinux og Rocky Linux brukes typisk firewalld med firewall-cmd. Uansett verktøy: dokumenter hvorfor hver port er åpen, og fjern regler som ikke lenger trengs.
Begrens SSH til kjente IP-adresser
Har du fast IP på kontoret eller bruker VPN, kan du tillate SSH bare derfra. Det fjerner nesten all støy i loggene og gjør gjetteangrep umulige fra resten av internett.
3. Steng ute dem som prøver seg
Verktøy som fail2ban leser innloggingslogger og sperrer IP-adresser midlertidig etter et visst antall mislykkede forsøk. Det reduserer belastningen og gjør automatiserte angrep langt mindre effektive.
sudo apt install fail2ban
# /etc/fail2ban/jail.local
[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1hRate limiting i webserveren eller brannmuren er et godt supplement, særlig for innloggingssider og API-er.
4. Hold systemet oppdatert – automatisk
De fleste vellykkede angrep utnytter kjente sårbarheter som det allerede finnes oppdateringer for. Slå på automatiske sikkerhetsoppdateringer, og planlegg omstart når kjernen oppdateres.
# Ubuntu/Debian
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
# AlmaLinux/Rocky
sudo dnf install dnf-automatic
# sett apply_updates = yes i /etc/dnf/automatic.conf
sudo systemctl enable --now dnf-automatic.timerHusk at operativsystemet bare er ett lag. WordPress, plugins, Node-pakker og Docker-images må også oppdateres jevnlig.
5. Minste privilegium
- Kjør hver applikasjon som en egen, uprivilegert bruker – aldri som root.
- Gi databasebrukere bare tilgang til sin egen database.
- Lytt på
127.0.0.1for tjenester som bare skal brukes lokalt, som Redis og PostgreSQL. - Fjern programvare og brukere du ikke trenger.
- Hold hemmeligheter som API-nøkler ute av kode og Git, og med strenge filrettigheter.
Det samme gjelder automatisering og AI. Gir du en AI-assistent tilgang til serveren, bør den bare få de verktøyene den trenger. Webbers MCP-server har per-verktøy-tillatelser, IP-whitelist, godkjenning for høyrisiko-handlinger og logg over alle kall – skallkommandoer er av som standard.
6. Logger, overvåking og backup
Les loggene
Sikkerhet handler også om å oppdage at noe er galt. Les loggene jevnlig, og sett opp varsling på disk, minne og tjenester som stopper.
journalctl -u ssh --since "1 hour ago" # SSH-innlogginger
sudo fail2ban-client status sshd # aktive sperringer
sudo ss -tulpn # hvilke porter lytter?
df -h && free -h # disk og minneBackup du har testet
Ingen sikkerhetstiltak er perfekte. Derfor trenger du sikkerhetskopier som ligger utenfor serveren, og du må ha prøvd å gjenopprette dem. Les mer i guiden om forskjellen på snapshots og backup.
Slik dekker Webber dette for deg
Alle Webber-servere er driftet. Det betyr at mye av sjekklisten over er på plass fra start, og at du kan styre resten i kontrollpanelet:
| Tiltak | Hos Webber |
|---|---|
| Brannmur | Alt innkommende blokkert unntatt SSH, HTTP/HTTPS, HTTP/3 og ping som standard |
| SSH kun fra kjente IP-er | «SSH kun fra whitelist» med ett klikk |
| Utestengning | Automatisk utestengning, IP-sperre, geoblokkering og rate limiting |
| Trygge endringer | Automatisk tilbakerulling etter 90 sekunder hvis en risikabel endring ikke bekreftes |
| Oppdateringer | Sikkerhetsoppdateringer av operativsystemet er en del av driften |
| Overvåking | Døgnovervåking av oppetid og ressurser med varsling |
| Backup | Automatiske snapshots til separat filserver i Norge |
| Nødtilgang | KVM-konsoll i nettleseren |
Les mer om brannmuren i kontrollpanelet og hva drift hos Webber innebærer, eller se prisene.
Ofte stilte spørsmål
Er det nok å bytte SSH-port?
Nei. Å flytte SSH til en annen port reduserer støy i loggene, men er ikke et sikkerhetstiltak i seg selv. SSH-nøkler, avslått passordinnlogging og whitelist er det som faktisk beskytter.
Hva gjør jeg hvis jeg låser meg ute?
På en Webber-server kan du bruke KVM-konsollen i nettleseren. I tillegg rulles risikable brannmurendringer automatisk tilbake etter 90 sekunder hvis du ikke bekrefter dem.
Må jeg installere fail2ban selv på en Webber-server?
Nei. Kontrollpanelet har automatisk utestengning, IP-sperre og rate limiting innebygd i brannmuren.
Hvem oppdaterer applikasjonen min?
Webber holder operativsystemet oppdatert. Egen applikasjonskode og innhold er kundens ansvar, men driftsteamet hjelper gjerne.