VPS-guiden

Säkerhetstips för din VPS - skydda servern

Praktiska säkerhetstips för din VPS - från SSH-härdning och brandväggsregler till hotdetektering och automatiska uppdateringar.

Robert Leal Författare Robert Leal | 3 juni 2026 (uppdaterad 10 juni 2026) | ~7 min lästid

Säkerhet på en VPS börjar med enkla vanor. En unmanaged VPS innebär att du ansvarar för allt - från uppdateringar till säkerhetsskydd. Det kan låta skrämmande, men med rätt grundinställningar skyddar du dig mot de allra flesta angrepp.

Här är de viktigaste åtgärderna du bör genomföra, ordnade från mest kritiskt till bra-att-ha.

1. Inaktivera lösenordsinloggning för SSH

Lösenordsbaserad SSH-inloggning är den vanligaste attackvektorn mot VPS-servrar. Automatiserade botar testar tusentals lösenordskombinationer per dag. SSH-nycklar eliminerar den risken helt.

Förutsättning: Se till att du redan har kopierat din publika SSH-nyckel till servern (se vår guide Kom igång med VPS för instruktioner). Annars låser du ut dig själv.

Öppna SSH-konfigurationen:

sudo nano /etc/ssh/sshd_config

Ändra eller lägg till dessa rader:

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
MaxAuthTries 3
  • PasswordAuthentication no - Ingen kan logga in med lösenord
  • PermitRootLogin no - Root-kontot kan inte användas för SSH alls
  • PubkeyAuthentication yes - Bekräftar att nyckelbaserad inloggning är aktiverad
  • MaxAuthTries 3 - Kopplar bort klienten efter tre misslyckade försök

Starta om SSH-tjänsten:

sudo systemctl restart ssh

Viktigt: Testa i ett nytt terminalfönster innan du stänger din nuvarande session. Om något gick fel har du fortfarande din gamla session kvar som livlina.

2. Byt SSH-port (valfritt)

Att byta från standardport 22 till en annan port stoppar inte riktade attacker, men det minskar automatiserad skanning dramatiskt. Många botar skannar bara port 22.

I samma SSH-konfigurationsfil, ändra (eller lägg till) port-raden till:

Port 2222

Om det redan finns en okommenterad rad Port 22, ta bort eller kommentera bort den så att SSH inte lyssnar på båda portarna.

Kom ihåg att uppdatera brandväggsreglerna innan du startar om SSH:

sudo ufw allow 2222/tcp
sudo systemctl restart ssh

Testa att du kan ansluta på den nya porten:

ssh -p 2222 dittnamn@din-server-ip

Ta först bort den gamla regeln när du bekräftat att den nya porten fungerar:

sudo ufw delete allow OpenSSH

3. Begränsa öppna portar med brandvägg

Varje öppen port är en potentiell attackyta. Principen är enkel: öppna bara det du faktiskt behöver.

En typisk webbserver behöver:

PortTjänstProtokoll
22 (eller din anpassade port)SSHTCP
80HTTPTCP
443HTTPSTCP

Konfigurera UFW att neka allt annat:

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

Kontrollera att inga onödiga portar är öppna:

sudo ufw status numbered

Om du kör en databas (MySQL, PostgreSQL) eller cache (Redis) - exponera aldrig dessa mot internet. De bör bara lyssna på localhost (127.0.0.1).

Du kan verifiera vilka portar som lyssnar externt med:

sudo ss -tlnp

4. Installera och konfigurera Fail2Ban

Fail2Ban övervakar loggar och blockerar IP-adresser som visar misstänkt beteende, till exempel upprepade misslyckade inloggningsförsök.

sudo apt install fail2ban -y

Skapa en lokal konfigurationsfil som inte skrivs över vid uppdateringar:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Öppna filen och justera SSH-inställningarna:

sudo nano /etc/fail2ban/jail.local

Viktiga inställningar under [sshd]:

[sshd]
enabled = true
port = ssh
maxretry = 3
bantime = 3600
findtime = 600
  • port ssh - Porten som Fail2Ban övervakar. Om du har bytt SSH-port (se steg 2) måste du ändra port = ssh till din anpassade port, till exempel port = 2222
  • maxretry 3 - Tre misslyckade försök inom findtime leder till ban
  • bantime 3600 - Blockering i en timme (3600 sekunder)
  • findtime 600 - Tidsperioden (10 minuter) inom vilken försöken räknas

Starta tjänsten:

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Se vilka IP-adresser som är blockerade:

sudo fail2ban-client status sshd

5. Håll systemet uppdaterat

Regelbundna uppdateringar är den enskilt viktigaste säkerhetsåtgärden. De flesta lyckade angrepp utnyttjar kända sårbarheter som redan har en patch.

Manuell uppdatering:

sudo apt update && sudo apt upgrade -y

Automatiska säkerhetsuppdateringar med unattended-upgrades:

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure -plow unattended-upgrades

Verifiera att det är aktiverat:

cat /etc/apt/apt.conf.d/20auto-upgrades

Du bör se:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Det innebär att systemet automatiskt hämtar och installerar säkerhetsuppdateringar dagligen. Du bör ändå logga in regelbundet och kontrollera att allt fungerar som det ska.

6. Aktivera tvåfaktorsautentisering (2FA)

För ett extra lager av säkerhet kan du lägga till tvåfaktorsautentisering via TOTP (Time-based One-Time Password) med Google Authenticator:

sudo apt install libpam-google-authenticator -y

Kör konfigurationen som din vanliga användare (inte root):

google-authenticator

Svara y på frågorna om tidsbaserade tokens och uppdatering av .google_authenticator-filen. Skanna QR-koden med en autentiseringsapp som Google Authenticator, Authy eller Bitwarden.

Uppdatera PAM-konfigurationen:

sudo nano /etc/pam.d/sshd

Kommentera bort raden @include common-auth (sätt ett # framför den) så att PAM inte frågar efter Unix-lösenord. Lägg sedan till följande rad i stället:

auth required pam_google_authenticator.so

Om @include common-auth inte kommenteras bort kommer du att behöva ange både ditt Unix-lösenord och en engångskod - tre autentiseringssteg totalt istället för två.

Uppdatera också SSH-konfigurationen:

sudo nano /etc/ssh/sshd_config

Ändra eller lägg till:

KbdInteractiveAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

Starta om SSH:

sudo systemctl restart ssh

Nu krävs både din SSH-nyckel och en engångskod vid inloggning.

7. Följ upp loggar och övervaka servern

Övervaka servern aktivt för att snabbt upptäcka problem och misstänkt aktivitet.

Autentiseringsloggar visar inloggningsförsök:

sudo journalctl -u ssh --since "1 hour ago"

Eller granska auth-loggen direkt:

sudo tail -100 /var/log/auth.log

Diskutrymme - En full disk kan orsaka allt från kraschade tjänster till korrupta databaser:

df -h

Minnesanvändning:

free -h

Aktiva processer som drar mest resurser:

top -bn1 | head -20

Enkel övervakning med Logwatch

För dagliga sammanfattningar via e-post:

sudo apt install logwatch -y

Logwatch sammanställer en daglig rapport med inloggningar, systemhändelser och potentiella problem. För att faktiskt skicka rapporten via e-post behöver du en fungerande e-posttjänst (MTA) på servern, till exempel Postfix. Om du inte vill konfigurera e-post kan du köra Logwatch manuellt och läsa rapporten direkt i terminalen:

sudo logwatch --output stdout --range today

8. Säkra delade tjänster

Om du kör webbapplikationer, databaser eller andra tjänster - se till att de är korrekt konfigurerade:

  • Databaser - Byt standardlösenord, begränsa nätverksåtkomst till localhost, skapa separata användare per applikation med minimala rättigheter
  • Webbservern - Dölj versionsinformation i serverheaders, aktivera HTTPS med Let’s Encrypt, konfigurera säkerhetsheaders (X-Frame-Options, Content-Security-Policy)
  • PHP (om du kör det) - Stäng av expose_php, begränsa upload_max_filesize, och se till att display_errors är av i produktion
  • Redis/Memcached - Ska aldrig vara exponerade mot internet. Bind till 127.0.0.1 och använd lösenord

9. Säkerhetskopiera regelbundet

Säkerhetskopiering är inte bara en säkerhetsfråga - det är din sista utväg om något går riktigt fel. En attack med skadlig programvara, en felaktig uppdatering eller ett mänskligt misstag kan radera allt.

Grundläggande strategi:

  • Säkerhetskopiera utanför servern (till en annan server, objektlagring eller lokal maskin)
  • Automatisera processen så den inte beror på att du kommer ihåg
  • Testa återställning regelbundet - en backup du inte kan återställa är värdelös

Enkel spegling med rsync:

rsync -avz /var/www/ backup-user@backup-server:/backups/www/

Observera att detta är en envägssynkronisering, inte en versionerad backup. Om en fil raderas eller skrivs över på servern speglas det vid nästa körning. För riktiga backuper med versionshistorik, använd ett verktyg som restic eller borgbackup.

Många VPS-leverantörer erbjuder också automatiska snapshots som en tilläggstjänst. Det är ett bra komplement men inte en ersättning för egna backuper.

Checklista

Sammanfattning av de viktigaste stegen:

  • SSH-nycklar istället för lösenord
  • Root-inloggning inaktiverad
  • Brandvägg aktiverad med minimala öppna portar
  • Fail2Ban installerat och aktiverat
  • Automatiska säkerhetsuppdateringar konfigurerade
  • Loggar granskas regelbundet
  • Databaser och tjänster begränsade till localhost
  • Säkerhetskopior på plats och testade

Ingen server är 100% säker, men de här stegen skyddar dig mot den absoluta majoriteten av attacker mot VPS-servrar.