Porter og lyttende tjenester

Modul 5: Skjerm av nettverket · Lesetid: 10 minutter

Læringsmål: Etter denne leksjonen kan du se hvilke tjenester som lytter på serveren din og på hvilken adresse, forklare forskjellen mellom 0.0.0.0 og 127.0.0.1, og sjekke utenfra hva alle på internett ser av serveren din.

Nøkkelbegreper: port, TCP og UDP, lytte, ss -tulpn, 0.0.0.0 og [::], 127.0.0.1 og [::1], bind-address, åpen, lukket og filtrert, angrepsflate, skannere

En IP-adresse med 65.535 dører

Serveren din har en IP-adresse, for eksempel 192.0.2.10 og 2001:db8::10. På den adressen kan flere programmer være tilgjengelige samtidig, hver på sin egen port: et nummer fra 1 til 65.535. Et program som tar imot tilkoblinger, lytter på en port. Noen kjente porter:

TCP er protokollen for tilkoblinger der dataene må komme pålitelig frem (web, SSH, databaser). UDP er for raske, enkeltstående pakker (DNS, VPN-er som WireGuard, HTTP/3). En tjeneste lytter på TCP, UDP eller begge.

Hver lyttende port er en dør inn til serveren din. Bak hver dør sitter det programvare som kan inneholde feil. Alle dørene som er tilgjengelige utenfra, kalles til sammen angrepsflaten din. Jo mindre, jo bedre: en server med et nettsted trenger bare 22, 80 og 443 utenfra.

Se hva som lytter: ss

Kommandoen ss (socket statistics) viser hva som lytter på serveren din. Med valgene -t (TCP), -u (UDP), -l (bare lyttende), -p (hvilket program) og -n (tall, ikke navn):

anna@web1:~$ sudo ss -tulpn
Netid State  Local Address:Port  Peer Address:Port Process
udp   UNCONN 127.0.0.54:53       0.0.0.0:*         users:(("systemd-resolve",pid=402,fd=16))
tcp   LISTEN 0.0.0.0:22          0.0.0.0:*         users:(("sshd",pid=611,fd=3))
tcp   LISTEN 0.0.0.0:80          0.0.0.0:*         users:(("nginx",pid=902,fd=6))
tcp   LISTEN 0.0.0.0:443         0.0.0.0:*         users:(("nginx",pid=902,fd=7))
tcp   LISTEN 127.0.0.1:3306      0.0.0.0:*         users:(("mariadbd",pid=755,fd=21))
tcp   LISTEN 0.0.0.0:6379        0.0.0.0:*         users:(("redis-server",pid=780,fd=6))
tcp   LISTEN [::]:22             [::]:*            users:(("sshd",pid=611,fd=4))
tcp   LISTEN [::]:80             [::]:*            users:(("nginx",pid=902,fd=8))
tcp   LISTEN [::]:443            [::]:*            users:(("nginx",pid=902,fd=9))

Den viktigste kolonnen er Local Address: adressen programmet lytter på.

I eksempelet over er MariaDB i orden: den lytter på 127.0.0.1, så bare programmer på selve serveren (nettstedet ditt) kommer til. Men Redis lytter på 0.0.0.0:6379. Hvis brannmuren ikke er riktig satt opp, kan hele internett komme til. Det er akkurat den typen feil denne leksjonen handler om.

Lytt på riktig adresse

En database, en cache eller et administrasjonspanel skal nesten aldri være tilgjengelig utenfra. Det første og beste forsvaret er at tjenesten bare lytter på loopback. En brannmur (leksjon 5.2) er det andre laget; den kan ved et uhell være slått av eller ikke gjelde (for eksempel med Docker, leksjon 9.3).

Hvor du stiller inn dette, varierer fra program til program:

Pakkene i Debian og Ubuntu setter disse tjenestene allerede til localhost som standard. Det går som regel galt når noen følger en veiledning som sier "sett bind-address til 0.0.0.0 for å koble til utenfra". Vil du selv nå databasen fra den bærbare PC-en din, bruker du en SSH-tunnel (leksjon 2.3): porten forblir lukket, og bare den som kommer inn via SSH, kommer til.

Etter en endring starter du tjenesten på nytt og sjekker igjen med ss -tulpn.

Åpen, lukket og filtrert

Sett utenfra kan en port være tre ting:

• Åpen: noe lytter, og tilkoblingen lykkes.
• Lukket (closed): ingenting lytter, eller en brannmur avviser aktivt. Serveren sender straks et "nei" tilbake (med TCP en RST-pakke). En tilkobling feiler med en gang med "Connection refused".
• Filtrert (filtered): en brannmur kaster pakken stille. Tilkoblingen henger til den får tidsavbrudd.

For databasen din er både lukket og filtrert bra: ingen kommer til. Forskjellen forteller deg bare hvorfor: filtrert betyr nesten alltid at brannmuren din stopper det.

Se utenfra

ss viser hva som lytter på serveren, men ikke hva som er tilgjengelig utenfra. Mellom de to sitter det en brannmur, og hos leverandøren din noen ganger også en nettverksbrannmur. Den eneste ekte kontrollen er derfor: se utenfra, fra en annen datamaskin.

Fra din egen datamaskin (ikke fra selve serveren, for da går du via loopback) kan du gjøre det med nc (netcat) for én port:

anna@laptop:~$ nc -vz -w 3 192.0.2.10 6379
nc: connect to 192.0.2.10 port 6379 (tcp) failed: Connection refused
anna@laptop:~$ nc -vz -w 3 192.0.2.10 22
Connection to 192.0.2.10 22 port [tcp/ssh] succeeded!

På Windows gjør PowerShell det samme med Test-NetConnection 192.0.2.10 -Port 6379. En portskanner som nmap kan sjekke flere porter samtidig; bruk en slik skanner bare på din egen server.

Ikke glem IPv6. En vanlig feil er en brannmur som bare har regler for IPv4, mens tjenesten også lytter på [::]. Test derfor også IPv6-adressen: nc -6 -vz -w 3 2001:db8::10 6379.

Hvorfor dette er så viktig

Serveren din blir skannet fra første minutt. Søkemotorer for enheter og tjenester på internett, og boter fra kriminelle, prøver hele tiden alle IPv4-adresser på kjente porter. En åpen Redis uten passord, en Elasticsearch-klynge eller en MongoDB uten tilgangskontroll blir funnet i løpet av kort tid. Datalekkasjer fra åpne databaser og åpne søkeklynger dukker jevnlig opp i nyhetene, og det handler nesten alltid om akkurat denne feilen: en tjeneste som var ment for intern bruk, lyttet på alle adresser.

Også SSH-porten får besøk hele dagen. Det er normalt og ikke noe problem med nøkler (leksjon 2.2) og fail2ban (leksjon 5.3).

Kurskontrollen

I oppgaven til denne leksjonen sjekker kursprogrammet utenfra fem faste databaseporter på serveren din: 3306 (MySQL/MariaDB), 5432 (PostgreSQL), 6379 (Redis), 9200 (Elasticsearch/OpenSearch) og 27017 (MongoDB). Programmet prøver bare om en tilkobling blir opprettet, sender ingen data og logger ikke inn noe sted. Det skanner ingen andre porter. Kontrollene kommer fra IP-adressen som står i oppgaven, slik at du kan kjenne dem igjen i din egen logg. En adresse kan bare sjekkes noen få ganger i timen.

På AlmaLinux og Rocky Linux

ss fungerer på samme måte. Filene til tjenestene ligger andre steder (for eksempel /etc/my.cnf.d/ for MariaDB, /var/lib/pgsql/data/postgresql.conf for PostgreSQL). I tillegg kan SELinux stoppe en tjeneste som vil lytte på en uvanlig port; det ser du da i journalctl (leksjon 6.2) og ikke i ss.

Oppsummering

• Hver lyttende port er en dør; hold bare åpent utenfra det som virkelig trengs (vanligvis 22, 80 og 443).
• sudo ss -tulpn viser hvilket program som lytter på hvilken adresse og hvilken port.
• 0.0.0.0 og [::] betyr "alle adresser", 127.0.0.1 og [::1] betyr "bare selve serveren". Databaser, cacher og søkeklynger hører hjemme på loopback.
• Lukket og filtrert er begge bra for en database; åpen er feil.
• Sjekk alltid utenfra, for både IPv4 og IPv6, for ss ser ikke brannmuren.

Quiz

Oppgave

Oppgave Z5.1: Databaseporter stengt utenfra. Kjør sudo ss -tulpn på serveren din og finn ut hvilke adresser tjenestene dine lytter på. La deretter kursprogrammet sjekke utenfra at portene 3306, 5432, 6379, 9200 og 27017 på serveren din ikke er tilgjengelige, for IPv4 og (hvis serveren din har en AAAA-post) IPv6. Fyll også inn hvilke tjenester som hos deg lytter på 0.0.0.0 eller [::]. Programmet kobler bare til disse fem portene og sender ingenting.

Les mer

• Sikre VPS-en din: de første fem minuttene
• Håndbok for ss(8): https://manpages.debian.org/trixie/iproute2/ss.8.en.html
• Redis, Security: https://redis.io/docs/latest/operate/oss_and_stack/management/security/