Hvilke tjenester lytter på VPS-en din, og hva er tilgjengelig utenfra?
Alle programmer som tar imot tilkoblinger, lytter på en port: SSH på 22, en webserver på 80 og 443, MariaDB på 3306. Hver port som kan nås utenfra, er en dør inn til serveren din. En nettside trenger som regel bare 22, 80 og 443 utenfra. Her ser du hvordan du finner ut hva som lytter og på hvilken adresse, og hvordan du sjekker hva resten av internett ser.
Se hva som lytter
Kjør dette på VPS-en din:
sudo ss -tulpn
Valgene betyr: TCP (-t), UDP (-u), bare lyttende (-l), hvilket program (-p) og tall i stedet for navn (-n). Et eksempel:
tcp LISTEN 0.0.0.0:22 users:(("sshd",...))
tcp LISTEN 0.0.0.0:443 users:(("nginx",...))
tcp LISTEN 127.0.0.1:3306 users:(("mariadbd",...))
tcp LISTEN 0.0.0.0:6379 users:(("redis-server",...))
tcp LISTEN [::]:22 users:(("sshd",...))
Det viktige er kolonnen Local Address, adressen programmet lytter på:
| Adresse | Betydning |
|---|---|
0.0.0.0 | Alle IPv4-adresser, altså også den offentlige adressen din: kan nås utenfra, med mindre en brannmur stopper det |
[::] | Alle IPv6-adresser: det samme for IPv6 |
127.0.0.1 eller [::1] | Bare selve serveren (loopback): kan aldri nås utenfra |
127.0.0.53 eller 127.0.0.54 | Også loopback: den lokale DNS-hjelperen til systemd-resolved |
I eksempelet er MariaDB i orden: bare programmer på selve serveren kommer til. Redis lytter på alle adresser, og det er nettopp den feilen det handler om.
Steng i selve tjenesten
En database, en cache eller et administrasjonspanel skal nesten aldri kunne nås utenfra. Det beste første steget er at tjenesten bare lytter på loopback. På Debian og Ubuntu:
| Program | Innstilling | Fil |
|---|---|---|
| MariaDB eller MySQL | bind-address = 127.0.0.1 | /etc/mysql/mariadb.conf.d/50-server.cnf |
| PostgreSQL | listen_addresses = 'localhost' | /etc/postgresql/<versjon>/main/postgresql.conf |
| Redis | bind 127.0.0.1 -::1 og protected-mode yes | /etc/redis/redis.conf |
Start deretter tjenesten på nytt (se Administrer tjenester med systemctl på VPS-en din) og sjekk igjen med ss -tulpn. Vil du selv nå databasen fra laptopen din, bruker du en SSH-tunnel i stedet for en åpen port, se En SSH-config: logg inn med et kort navn.
Brannmuren som andre lag
En brannmur stopper det som likevel ved et uhell lytter på alle adresser. Hvordan du setter opp ufw, står i En brannmur med ufw (eller nftables). Ikke stol på ett lag alene: en brannmur kan være slått av, eller en regel kan være for vid.
ports:), går forbi ufw. En database med "3306:3306" kan da nås utenfra, selv om ufw sier at porten er stengt. Sett 127.0.0.1: foran, eller ikke publiser porten. Se Docker og brannmuren: publiser porter trygt.Sjekk utenfra
ss viser hva som lytter på serveren, men ikke hva brannmuren slipper gjennom. Den ekte sjekken gjør du fra en annen datamaskin, ikke fra selve serveren. Med nc (netcat) på Mac eller Linux:
nc -vz -w 3 203.0.113.10 6379 nc -6 -vz -w 3 2001:db8::10 6379
På Windows gjør PowerShell det samme med Test-NetConnection 203.0.113.10 -Port 6379. Fyll inn din egen IPv4- og IPv6-adresse; de står i VPS-skjermbildet. Slik leser du resultatet:
- Åpen (succeeded): noe lytter, og det kan nås utenfra.
- Lukket (Connection refused): ingenting lytter, eller brannmuren avviser aktivt.
- Filtrert (time-out): en brannmur kaster trafikken i stillhet.
For en database er både lukket og filtrert bra. Test også IPv6: en vanlig feil er en brannmur med bare IPv4-regler, mens tjenesten også lytter på [::]. En portskanner som nmap sjekker flere porter samtidig; bruk en slik skanner bare på din egen server.
VPS-en din er fullt selvadministrert: hvilke tjenester som lytter og hvordan brannmuren er satt opp, ordner du selv. Vi hjelper med WebOké-delen, som VPS-skjermbildet, nettverket og snapshots.
Vil du lære mer? Ta det gratis kurset VPS og Linux-serveradministrasjon, leksjon 5.1 Porter og lyttende tjenester eller leksjon 5.2 En brannmur med ufw og nftables.