Porturi și servicii care ascultă

Modulul 5: Protejarea rețelei · Timp de citire: 10 minute

Obiectivul lecției: După această lecție veți putea vedea ce servicii ascultă pe serverul dumneavoastră și pe ce adresă, veți putea explica diferența dintre 0.0.0.0 și 127.0.0.1 și veți putea verifica din exterior ce vede oricine de pe internet la serverul dumneavoastră.

Noțiuni cheie: port, TCP și UDP, ascultare, ss -tulpn, 0.0.0.0 și [::], 127.0.0.1 și [::1], bind-address, deschis, închis și filtrat, suprafață de atac, scanere

O adresă IP cu 65.535 de uși

Serverul dumneavoastră are o adresă IP, de exemplu 192.0.2.10 și 2001:db8::10. La această adresă pot fi accesibile simultan mai multe programe, fiecare pe propriul port: un număr de la 1 la 65.535. Un program care acceptă conexiuni ascultă pe un port. Câteva porturi cunoscute:

TCP este protocolul pentru conexiunile în care datele trebuie să ajungă în mod fiabil (web, SSH, baze de date). UDP este pentru pachete rapide și independente (DNS, VPN-uri precum WireGuard, HTTP/3). Un serviciu ascultă pe TCP, pe UDP sau pe ambele.

Fiecare port care ascultă este o ușă către serverul dumneavoastră. În spatele fiecărei uși se află software care poate conține erori. Ansamblul ușilor accesibile din exterior se numește suprafața de atac. Cu cât este mai mică, cu atât mai bine: un server cu un site web are nevoie din exterior doar de 22, 80 și 443.

Ce ascultă: ss

Comanda ss (socket statistics) arată ce ascultă pe serverul dumneavoastră. Cu opțiunile -t (TCP), -u (UDP), -l (doar ce ascultă), -p (ce program) și -n (numere, nu nume):

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))

Coloana cea mai importantă este Local Address: adresa pe care ascultă programul.

În exemplul de mai sus, MariaDB este în regulă: ascultă pe 127.0.0.1, deci doar programele de pe serverul însuși (site-ul dumneavoastră) au acces. Redis însă ascultă pe 0.0.0.0:6379. Dacă firewall-ul nu este configurat corect, întregul internet are acces. Exact acest tip de greșeală este subiectul acestei lecții.

Ascultarea pe adresa corectă

O bază de date, un cache sau un panou de administrare nu ar trebui aproape niciodată să fie accesibile din exterior. Prima și cea mai bună apărare este ca serviciul să asculte doar pe loopback. Un firewall (lecția 5.2) este al doilea strat; acesta poate fi dezactivat din greșeală sau poate să nu se aplice (de exemplu la Docker, lecția 9.3).

Locul în care setați acest lucru diferă de la program la program:

Pachetele Debian și Ubuntu configurează deja implicit aceste servicii pe localhost. De obicei, problemele apar când cineva urmează un ghid care spune "setați bind-address la 0.0.0.0 pentru a vă conecta din exterior". Dacă doriți să accesați baza de date de pe laptopul dumneavoastră, folosiți un tunel SSH (lecția 2.3): portul rămâne închis și doar cine intră prin SSH are acces.

După o modificare, reporniți serviciul și verificați din nou cu ss -tulpn.

Deschis, închis și filtrat

Văzut din exterior, un port poate avea trei stări:

• Deschis (open): ceva ascultă și conexiunea reușește.
• Închis (closed): nu ascultă nimic sau un firewall refuză activ. Serverul trimite imediat înapoi un "nu" (la TCP, un pachet RST). O conexiune eșuează imediat cu "Connection refused".
• Filtrat (filtered): un firewall aruncă pachetul în tăcere. Conexiunea rămâne în așteptare până la expirarea timpului (time-out).

Pentru baza dumneavoastră de date, închis și filtrat sunt ambele bune: nimeni nu are acces. Diferența vă spune doar de ce: filtrat înseamnă aproape întotdeauna că firewall-ul dumneavoastră blochează traficul.

Verificarea din exterior

ss arată ce ascultă pe server, dar nu ce este accesibil din exterior. Între ele se mai află un firewall, iar la furnizorul dumneavoastră uneori și un firewall de rețea. De aceea, singura verificare reală este: verificați din exterior, de pe alt calculator.

De pe propriul calculator (nu de pe server, pentru că atunci treceți prin loopback) puteți face acest lucru cu nc (netcat) pentru un singur 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!

Pe Windows, PowerShell face același lucru cu Test-NetConnection 192.0.2.10 -Port 6379. Un scaner de porturi precum nmap poate verifica mai multe porturi deodată; folosiți un astfel de scaner doar pe propriul server.

Nu uitați de IPv6. O greșeală frecventă este un firewall care are reguli doar pentru IPv4, în timp ce serviciul ascultă și pe [::]. Testați deci și adresa IPv6: nc -6 -vz -w 3 2001:db8::10 6379.

De ce este atât de important

Serverul dumneavoastră este scanat din primul minut. Motoarele de căutare pentru dispozitive și servicii de pe internet, precum și roboții infractorilor, încearcă în permanență toate adresele IPv4 pe porturile cunoscute. Un Redis deschis fără parolă, un cluster Elasticsearch sau un MongoDB fără control al accesului sunt găsite în scurt timp. Scurgerile de date din cauza bazelor de date și a clusterelor de căutare deschise apar regulat în presă și aproape întotdeauna este vorba exact de această greșeală: un serviciu destinat utilizării interne asculta pe toate adresele.

Și portul SSH este „ciocănit” toată ziua. Acest lucru este normal și nu reprezintă o problemă dacă folosiți chei (lecția 2.2) și fail2ban (lecția 5.3).

Verificarea din curs

În exercițiul acestei lecții, programul cursului verifică din exterior cinci porturi fixe de baze de date ale serverului dumneavoastră: 3306 (MySQL/MariaDB), 5432 (PostgreSQL), 6379 (Redis), 9200 (Elasticsearch/OpenSearch) și 27017 (MongoDB). Programul încearcă doar dacă se poate stabili o conexiune, nu trimite date și nu se autentifică nicăieri. Nu scanează alte porturi. Verificările provin de la adresa IP indicată în exercițiu, astfel încât să le puteți recunoaște în propriul jurnal. O adresă poate fi verificată doar de câteva ori pe oră.

Pe AlmaLinux și Rocky Linux

ss funcționează la fel. Fișierele serviciilor se află în alte locuri (de exemplu /etc/my.cnf.d/ pentru MariaDB, /var/lib/pgsql/data/postgresql.conf pentru PostgreSQL). În plus, SELinux poate bloca un serviciu care vrea să asculte pe un port neobișnuit; acest lucru îl vedeți atunci în journalctl (lecția 6.2), nu în ss.

Rezumat

• Fiecare port care ascultă este o ușă; lăsați deschis din exterior doar ce este cu adevărat necesar (de obicei 22, 80 și 443).
• sudo ss -tulpn arată ce program ascultă, pe ce adresă și pe ce port.
• 0.0.0.0 și [::] înseamnă "toate adresele", 127.0.0.1 și [::1] înseamnă "doar serverul însuși". Bazele de date, cache-urile și clusterele de căutare trebuie să asculte pe loopback.
• Închis și filtrat sunt ambele bune pentru o bază de date; deschis este greșit.
• Verificați întotdeauna din exterior, pentru IPv4 și IPv6, deoarece ss nu vede firewall-ul.

Test (quiz)

Exercițiu

Exercițiul Z5.1: Porturile bazelor de date închise din exterior. Rulați sudo ss -tulpn pe serverul dumneavoastră și aflați pe ce adrese ascultă serviciile dumneavoastră. Apoi lăsați programul cursului să verifice din exterior că porturile 3306, 5432, 6379, 9200 și 27017 ale serverului dumneavoastră nu sunt accesibile, pentru IPv4 și (dacă serverul are o înregistrare AAAA) IPv6. Completați și ce servicii ascultă la dumneavoastră pe 0.0.0.0 sau [::]. Programul face doar o conexiune către aceste cinci porturi și nu trimite nimic.

Lecturi suplimentare

• Securizarea VPS-ului: primele cinci minute
• Manualul 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/