Härda din VPS: säkerhetschecklista efter installation

Din nya VPS hinner knappt bli varm innan de första inloggningsförsöken dyker upp i loggen. Det är inget personligt. Botnät skannar publika IP-adresser dygnet runt och testar standardanvändare och svaga lösenord på varje ny server de hittar, ofta inom minuter efter att den fått sin adress. En ohärdad standardinstallation är precis vad de letar efter. Den här guiden tar vid där komma igång med din VPS slutar och går igenom det som faktiskt gör skillnad. Räkna med 30 till 60 minuter, och att den gäller Ubuntu 22.04/24.04 och Debian 12.

På en unmanaged VPS (se managed vs unmanaged VPS) sköter leverantören hårdvaran och nätet. Allt ovanför det, operativsystemet och dina tjänster, är ditt bord. Den VPS-plan du valt kommer inte färdighärdad.

1. SSH-nycklar obligatoriskt. Inaktivera lösenordsinloggning (PasswordAuthentication no).
2. Inaktivera root via SSH (PermitRootLogin no).
3. Skärp SSH ytterligare: MaxAuthTries, ClientAliveInterval, AllowUsers.
4. Installera fail2ban för automatisk blockering av upprepade misslyckade inloggningar.
5. Aktivera unattended-upgrades för automatiska säkerhetsuppdateringar.
6. Minimera exponerade tjänster. Lista med ss -tlnp och stäng av det du inte använder.
7. Kör en Lynis-revision för att identifiera vad du missat.
8. Sätt upp drifttidsövervakning så att du vet när servern är nere.
9. Lär dig var leverantörens räddningskonsol sitter, INNAN du börjar ändra SSH-konfigurationen.
10. Dokumentera vad du gjort. En textfil med kommandon och datum räcker.

Räddningslinan: leverantörens webbkonsol

De flesta härdningsguider kastar sig rakt på SSH. Börja med det här i stället. Innan du ändrar ett enda tecken i SSH-konfigurationen, verifiera att du har åtkomst till leverantörens webbkonsol. Gör du fel i sshd_config och saknar en alternativ inloggningsväg kan du låsa ut dig permanent, utan möjlighet att rätta till felet.

GleSYS erbjuder en HTML5 VNC-konsol i kontrollpanelen. Oderland har en Emergency Console med VNC-liknande åtkomst. Inleed inkluderar en VNC-konsol i sin kontrollpanel. Flera leverantörer erbjuder dessutom ett "rescue mode" som bootar servern från ett alternativt OS om det ordinarie systemet är i ett skadat tillstånd.

Testa konsolen nu, inte när det brinner. Logga in, verifiera att du ser terminalen och att du kan skriva kommandon. Stäng sedan konsolen och fortsätt med resten av checklistan.

Grunden är redan lagd: det här förutsätter vi

Vi utgår från att du har följt guiden för att komma igång med din VPS: du har skapat en sudo-användare, lagt in din SSH-nyckel och kört apt update && apt upgrade. Om det inte är gjort, gör det först. Stegen nedan bygger på den grunden.

Vi förutsätter också att du inte kör ufw med blockerade SSH-regler och att du fortfarande kan logga in på servern. Kör du ufw parallellt med det här, se till att port 22 (eller din valda SSH-port) är öppen innan du ändrar någonting.

Steg 1. Fördjupa SSH-härdningen

SSH är den primära ingångspunkten till servern och därmed det mest attackerade protokollet på en publik IP. Grundkonfigurationen i Ubuntu och Debian är rimlig, men den är inte härdad.

Inaktivera lösenordsinloggning helt

Om du inte redan gjort det, verifiera FÖRST att du kan logga in med din SSH-nyckel. Kör det här från din lokala maskin:

ssh -i ~/.ssh/din_nyckel dinuser@din-server-ip

Fungerar det? Bra. Öppna då /etc/ssh/sshd_config och sätt:

PasswordAuthentication no
PermitRootLogin no

Starta om SSH-tjänsten. Stäng inte den aktiva sessionen förrän du har bekräftat att du kan logga in i ett nytt terminalfönster:

sudo systemctl restart ssh

Fler SSH-inställningar som faktiskt spelar roll

Lägg till dessa i sshd_config:

MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
MaxSessions 2
AllowUsers dinuser

MaxAuthTries 3 begränsar antalet inloggningsförsök per anslutning. ClientAliveInterval och ClientAliveCountMax kopplar ner inaktiva sessioner efter ungefär tio minuter. AllowUsers är en vitlista som ser till att enbart namngivna användare kan autentisera sig, oavsett om andra konton skapas av misstag.

En fråga som återkommer är om man bör byta SSH-port från 22 till något annat. Det ärliga svaret är att portbytet minskar logbrus och håller de flesta skriptbaserade scanners borta, men det ger ingen faktisk säkerhet. Verktyg som Shodan hittar porten ändå via fullständig portskanning. Vill du ha snyggare auth.log-loggar, byt port. Men luras inte att tro att det skyddar dig.

Steg 2. Installera och konfigurera fail2ban

fail2ban övervakar loggfiler och bannlyser IP-adresser som uppvisar misstänkt beteende, typiskt upprepade misslyckade inloggningsförsök. Det är ett av de mest effektiva och lättinstallerade verktygen i härdningsverktygslådan.

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

Redigera /etc/fail2ban/jail.local och kontrollera SSH-sektionen:

[sshd]
enabled = true
port    = ssh
maxretry = 3
bantime  = 3600
findtime = 600

Det här innebär att en IP som misslyckas tre gånger inom tio minuter bannlyses i en timme. Aktivera och starta tjänsten:

sudo systemctl enable --now fail2ban
sudo systemctl status fail2ban

Kontrollera att SSH-fängelset är aktivt:

sudo fail2ban-client status sshd

Har du råkat blockera din egen IP (det händer) löser du det med:

sudo fail2ban-client set sshd unbanip IPADRESS

Märk att fail2ban är ett komplement, inte ett substitut för SSH-nycklar. Med PasswordAuthentication no på plats är fail2ban en andra försvarslinje som fångar upp automatiserade angrepp innan de ens hinner testa en nyckel.

Steg 3. Automatiska säkerhetsuppdateringar (unattended-upgrades)

Kända sårbarheter i kärnpaket åtgärdas ofta snabbt av distributionsunderhållarna. Problemet är att de flesta servrar aldrig uppgraderas förrän något gått fel. unattended-upgrades stänger det fönstret automatiskt, utan att röra applikationspaket. Mer om hur säkerhetsuppdateringar på en VPS fungerar finns i vår FAQ.

sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Svara "Ja" på frågan om automatisk installation av stabila säkerhetsuppdateringar. Kontrollera sedan konfigurationsfilen /etc/apt/apt.conf.d/50unattended-upgrades och se till att automatisk omstart är inaktiverad:

Unattended-Upgrade::Automatic-Reboot "false";

Automatisk omstart mitt i natten kan ta ner en sajt utan förvarning. Vill du ha omstarter, schemalägg dem manuellt under underhållsfönster. Verifiera att tjänsten är igång:

systemctl status unattended-upgrades

Loggarna hittar du i /var/log/unattended-upgrades/. Kika där om du vill bekräfta att uppdateringar faktiskt installerats.

Steg 4. Minimera exponeringen: tjänster som lyssnar

En nyinstallerad Ubuntu eller Debian-server har sällan många onödiga tjänster, men det är värt att kontrollera. Lista alla tjänster som lyssnar på TCP-portar:

ss -tlnp

Titta igenom listan. Ser du tjänster du inte känner igen, eller tjänster som lyssnar på 0.0.0.0 (alla interface) i stället för 127.0.0.1 (bara lokalt)? En databasserver som råkat bli publik på port 3306 är ett klassiskt misstag. Inaktivera tjänster du inte behöver:

sudo systemctl disable --now tjänstnamn

Färre öppna portar innebär färre angreppsytor. Det är en enkel princip med stor effekt, och ett renare system att felsöka när något väl går fel.

Steg 5. Kör en Lynis-revision

Lynis är ett granskningsverktyg med öppen källkod som genomsöker systemet och lyfter fram svagheter, felkonfigurationer och saker du kan ha missat under den manuella härdningen. Det ger inte en komplett säkerhetsgenomgång, men det är ett utmärkt underlag för att förstå vad som kan förbättras.

sudo apt install lynis && sudo lynis audit system

Genomgången tar ett par minuter. Resultatet delas upp i tre kategorier: varningar, förslag och godkänt. Läs igenom varningarna noggrant. Förslagen är mer kontextkänsliga och inte alla är relevanta för en liten VPS.

Lynis ger dig ett härdningsindex i slutet. Sikta inte på 100, det kräver konfigurationsändringar som kan bryta tjänster. Fokusera på varningarna och de förslag som är enkla att åtgärda med din specifika konfiguration.

Steg 6. Sätt upp drifttidsövervakning

Du behöver veta när servern är nere. Utan extern övervakning kan en kraschad tjänst ligga nere i timmar innan du märker det. Det finns gratistjänster som kontrollerar tillgängligheten var femte minut och skickar ett mejl eller en notis om servern inte svarar.

Välj en tjänst som kontrollerar en HTTP(S)-adress, inte bara ett ping. Servern kan svara på ping men ha en Nginx som inte startat. Registrera dig, lägg till din URL och konfigurera en mejlavisering. Det tar tio minuter och du slipper höra om krascher från en arg kund.

Vad är överdrivet för en liten VPS?

En del härdningsguider listar verktyg som är designade för storskaliga företagsmiljöer och regelefterlevnadskrav. På en liten VPS som kör en webbapplikation eller en WordPress-sajt är kostnad-nytta-kvoten dålig för flera av dem.

auditd loggar systemanrop i detalj och är värdefull i regelefterlevnadsmiljöer, men loggnivå och konfigurationskostnad är orimliga för en sajt-VPS utan regelefterlevnadskrav. rkhunter och chkrootkit kan vara OK som engångskontroll men skapar ett falskt trygghetsskapande om du förlitar dig på dem löpande. De hittar gamla mönster, inte moderna hot. IDS/IPS-verktyg som Snort och Suricata är kraftfulla men resurskrävande, och konfigurationen kräver gedigen kunskap för att inte generera mer brus än nytta.

Port knocking är ett fördunklingslager med hög komplexitetskostnad och låg faktisk säkerhetsvinst. AppArmor är aktivt med standardprofiler på Ubuntu, och det är bra. Rör inte de manuella profilerna om du inte vet exakt vad du gör.

De sex stegen ovan ger långt mer säkerhet per nedlagd timme än något av verktygen i den här listan.

Kopplingen till felsökning

Härdning och felsökning hänger ihop på ett konkret sätt. Utan fail2ban kan en råstyrkeattack (brute force) generera loggar i en takt som fyller diskutrymme och orsakar minnesproblem. Utan unattended-upgrades kan en känd sårbarhet bli ingången för en attack som sedan kräver timmar att diagnostisera. Minimerade tjänster ger inte bara färre angreppsytor, de gör också felsökningen enklare för att systemet har färre rörliga delar.

Hamnar du ändå i ett läge där servern krånglar, med hög belastning, misslyckade anslutningar eller tjänster som inte startar, finns konkreta metoder att gå igenom i guiden för att felsöka en seg eller nedlagd VPS.

Håll checklistan levande

En härdning är inte en engångshändelse. Systemet förändras och hotbilden likaså. Några kommandon att köra med jämna mellanrum:

sudo apt update && sudo apt list --upgradable
sudo systemctl is-enabled fail2ban
sudo grep "Failed password\|Invalid user" /var/log/auth.log | tail -50

Det första kontrollerar om det finns väntande uppdateringar som unattended-upgrades inte tagit. Det andra bekräftar att fail2ban fortfarande är aktivt efter eventuella omstarter. Det tredje ger dig en snabb bild av inloggningsaktiviteten på servern.

Dokumentera också vad du gjort. Det behöver inte vara sofistikerat: en textfil i hemkatalogen med datum, kommandon och eventuella avvikelser från standardkonfigurationen räcker. Nästa gång du driftsätter en server, eller nästa gång du felsöker ett problem, tackar du dig själv för att du tog fem minuter på det.