I samma stund som det blev ’min server’ blev allt mitt ansvar
Senast tog jag mig över muren av Linux CLI och behörigheter (Permission). chmod, chown, och till och med det man absolut inte får göra — chmod 777. Åtkomstkontroll på enskilda filer hade jag någorlunda grepp om.
Men då hade jag en stor missuppfattning. Jag trodde att servern var säker bara jag skötte ’filbehörigheterna’ ordentligt.
”Serversäkerhet? Är inte det säkerhetsteamets sak?”
På ett storföretag kanske. Men jag är en soloutvecklare. Serveradministratör, säkerhetsansvarig, nätverksingenjör — allt var ’jag’. Hela säkerhetsansvaret låg på mina axlar.
Och det som fick mig att inse det var en inloggningslogg på servern som jag upptäckte en måndagsmorgon.
Krisen: någon knackade på min servers dörr
En måndagsmorgon, när jag som vanligt SSH:ade in på servern och kollade loggarna, hittade jag något konstigt.
# Kontrollera senaste misslyckade SSH-inloggningar
$ grep "Failed password" /var/log/auth.log | tail -20
När jag såg loggen på skärmen fick jag gåshud.
Feb 10 03:14:22 sshd: Failed password for root from 185.220.xx.xx
Feb 10 03:14:25 sshd: Failed password for root from 185.220.xx.xx
Feb 10 03:14:27 sshd: Failed password for admin from 185.220.xx.xx
Feb 10 03:14:30 sshd: Failed password for ubuntu from 185.220.xx.xx
...
Hundratals inloggningsförsök från klockan tre på morgonen. Utländska IP-adresser. Kontonamnen växlade mellan root, admin och ubuntu. Någon körde ett ’automatiserat program (bot)’ och försökte råstyrka (Brute Force) fram lösenorden.
”Va? Jag är väl inte hackad än…?”
Tur nog kom de inte in. Men kan man verkligen stå framför en tjuv som provar nyckel efter nyckel och säga ”ingen fara, dörren höll”? Jag gick direkt igenom serverns säkerhetsläge.
Steg 1: lås ytterdörren — SSH-härdning
Serverns ytterdörr är SSH (Secure Shell). Precis den jag själv använder för att logga in. Problemet är att hackaren vill in genom samma dörr. Det första man måste göra är att förstärka just den här dörren.
Byta SSH-port (standard 22 → annat nummer)
SSH:s standardport är 22. Hackarnas automatiska skannrar knackar först på port 22. Bara genom att byta portnummer filtrerar du bort över 90 % av brute force-attackerna.
# Öppna SSH-konfigurationsfilen
$ sudo vi /etc/ssh/sshd_config
# Ändra portnummer (standard 22 → t.ex.: 2222)
Port 2222
# Starta om SSH-tjänsten
$ sudo systemctl restart sshd
Som liknelse: tjuven siktar oftast på huvudentrén på bottenvåningen (22). Flyttar du ingången till en takdörr på tredje våningen (2222) hittar de flesta tjuvar inte ens var dörren är.
Blockera direkt root-inloggning
Av loggarna syns det att hackarnas första försök alltid gäller ’root’. root är Linux högsta administratörskonto — bryter de det tar de över hela servern.
# Blockera direkt root-inloggning i SSH-konfigurationsfilen
$ sudo vi /etc/ssh/sshd_config
PermitRootLogin no
Nu är det omöjligt att SSH:a in som root. Du loggar in med ett vanligt konto och höjer behörigheten med sudo när det behövs.
SSH-nyckelautentisering i stället för lösenord
Hur komplicerat lösenordet än är kan ett automatiserat program som testar tiotusentals kombinationer knäcka det förr eller senare. Säkrast är att stänga av lösenordsinloggning helt och bara tillåta åtkomst via ’SSH-nyckel (Key)’.
# Skapa ett SSH-nyckelpar på den egna datorn (lokalt)
$ ssh-keygen -t rsa -b 4096
# Kopiera den publika nyckeln till servern
$ ssh-copy-id -p 2222 user@my-server-ip
# Inaktivera lösenordsinloggning på servern
$ sudo vi /etc/ssh/sshd_config
PasswordAuthentication no
SSH-nyckelautentisering är inte en ’nyckel’ utan ett ’fingeravtrycksläsare’. Lösenord (nyckel) kan kopieras, men den privata nyckeln (fingeravtrycket) som bara finns på min dator är i praktiken omöjlig att duplicera.
Steg 2: res muren — Brandvägg
När ytterdörren (SSH) är förstärkt är det dags att staketa in huset och styra vem som får komma in. Det är ’Brandväggen’.
En server har totalt 65 535 portar (ingångar). Utan brandvägg är det som att alla 60 000 dörrar står öppna. Man måste öppna bara de som behövs och låsa resten.
Lättaste brandväggsverktyget i Linux är ’UFW (Uncomplicated Firewall)’.
# Aktivera UFW
$ sudo ufw enable
# Standardpolicy: blockera all inkommande trafik, tillåt utgående
$ sudo ufw default deny incoming
$ sudo ufw default allow outgoing
# Öppna bara de nödvändiga portarna
$ sudo ufw allow 2222/tcp # SSH (ändrad port)
$ sudo ufw allow 80/tcp # HTTP
$ sudo ufw allow 443/tcp # HTTPS
# Kontrollera brandväggens nuvarande status
$ sudo ufw status
| Port | Användning | Öppen? |
|---|---|---|
| 2222 | SSH (ändrad port) | ✅ Tillåten |
| 80 | HTTP (webb) | ✅ Tillåten |
| 443 | HTTPS (säker webb) | ✅ Tillåten |
| 22 | SSH (standard, används inte längre) | ❌ Blockerad |
| Övriga | Samtliga | ❌ Blockerade |
Av 60 000 dörrar lämnade jag exakt 3 öppna och murade igen resten med tegel. Själva dörrarna som tjuven skulle kunna knacka på har försvunnit.
Steg 3: kryptera kommunikationen — HTTPS
Om servern erbjuder en webbtjänst måste också kommunikationen mellan användare och server skyddas. Det är ’HTTPS’.
HTTP skickar data som ett ’vykort’. Vem som helst längs vägen kan läsa innehållet. HTTPS skickar data i ett ’förseglat brev’. Även om någon snappar upp det kan de inte läsa det.
Om användar-ID och lösenord som användaren skrivit i inloggningsformuläret skickas via HTTP? Någon som sitter på samma Wi-Fi på caféet kan se allt i klartext.
I praktiken är det enklaste sättet att införa HTTPS att utfärda ett gratis SSL-certifikat via ’Let’s Encrypt’.
# Installera Certbot (automatiseringsverktyg för Let's Encrypt)
$ sudo apt install certbot python3-certbot-nginx
# Utfärda certifikat och tillämpa automatiskt i Nginx
$ sudo certbot --nginx -d mydomain.com
# Test av automatisk förnyelse (certifikatet måste förnyas var 90:e dag)
$ sudo certbot renew --dry-run
Med några rader kommando byts tjänstens adress från http:// till https:// och hänglåsikonen dyker upp i webbläsarens adressfält. Du ger användaren känslan av ”den här sajten är säker”.
Steg 4: automatiskt försvarssystem — Fail2Ban
Även efter byte av SSH-port och nyckelautentisering finns det envisa bottar där ute. Det finns definitivt de som hittar den ändrade porten och försöker logga in.
I de lägena är ’Fail2Ban’ användbart. Det är ett verktyg som automatiskt blockerar IP-adresser som misslyckas med inloggning ett visst antal gånger.
# Installera Fail2Ban
$ sudo apt install fail2ban
# Konfigurera SSH-skydd
$ sudo vi /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 2222
maxretry = 5
bantime = 3600
findtime = 600
| Inställning | Betydelse |
|---|---|
| maxretry = 5 | Efter 5 felaktiga försök |
| bantime = 3600 | Blockera det IP:t i 1 timme |
| findtime = 600 | Regeln slår till om 5 misslyckanden sker inom 10 minuter |
# Starta Fail2Ban
$ sudo systemctl enable fail2ban
$ sudo systemctl start fail2ban
# Se aktuellt blockerade IP-adresser
$ sudo fail2ban-client status sshd
Fail2Ban är ’övervakningskameran + automatlåset’ som står framför ytterdörren. Om någon misstänkt anger fel lösenord flera gånger nekas tillträde automatiskt.
Praktiskt tips: säkerhetschecklista
Jag sammanfattar allt vi hittills ställt in i en checklista. Varje gång du sätter upp en ny server och följer den här listan har du det grundläggande skyddet på plats.
| # | Punkt | Kommando/Inställning |
|---|---|---|
| 1 | Byta SSH-port | Port 2222 in sshd_config |
| 2 | Blockera root-inloggning | PermitRootLogin no |
| 3 | Byta till SSH-nyckelautentisering | PasswordAuthentication no |
| 4 | Aktivera brandvägg | ufw enable, tillåt endast nödvändiga portar |
| 5 | Införa HTTPS | Let’s Encrypt + Certbot |
| 6 | Installera Fail2Ban | Automatisk IP-blockering vid misslyckade inloggningar |
| 7 | Regelbundna uppdateringar | sudo apt update && sudo apt upgrade |
Punkt 7 är förvånansvärt viktig. Säkerhetsbrister upptäcks dagligen. Hur bra brandvägg du än har hjälper det inte om själva operativsystemet eller mjukvaran har hål. Regelbundna uppdateringar är både den mest grundläggande och den mest effektiva säkerhetsåtgärden.
Avslutningsvis: säkerhet är inget märkvärdigt — det är en vana
I början kändes ordet säkerhet pompöst. Hackningsskydd, intrångsdetektering, kryptering… Det lät som något som bara finns på film.
Men när jag väl provade behövdes ingen avancerad teknik. Byta SSH-port, sätta på brandväggen, konfigurera nyckelautentisering, installera Fail2Ban. Allt gick att lösa med några rader kommando. Det viktiga var inte att ’veta’, utan att ’göra’.
Säkerhetsincidenter uppstår inte på grund av avancerade hackningstekniker, utan på servrar där man inte vidtagit de grundläggande åtgärderna.
Sedan den dagen går jag alltid obligatoriskt igenom den här säkerhetschecklistan innan jag laddar upp kod på en ny server. Att kontrollera låset innan man öppnar dörren — det är den mest grundläggande hållningen för att skydda sin server.
Fram till nu har vi byggt den grundläggande konditionen (CLI, behörigheter, säkerhet) som krävs för att överleva i Linux-vildmarken. Men det återstår ett grundläggande problem. Miljön på min laptop (Windows) skiljer sig från Linux-servern. Olika Java-versioner, olika bibliotek.
Det finns en teknik som för alltid sätter stopp för ursäkten ”Det funkar på min dator”. Nästa gång tar vi upp ’virtualisering och containrar’ som helt utplånar miljöskillnaderna.