Lista porturilor deschise este chiar lista căilor de a ajunge la server. Tot restul — firewalluri, WAF, detectarea intruziunilor — sunt suprastructuri peste ea. De aceea verificarea „ce ascultă la mine” stă pe primul loc în orice audit, și tot ea dă cel mai des un rezultat neplăcut: jumătate din ce se găsește nu ai deschis tu, ci scriptul de instalare al vreunui pachet.

Citim ieșirea

sudo ss -tulpn

Opțiuni: t — TCP, u — UDP, l — doar cele care ascultă, p — procesul, n — fără rezolvarea numelor. Fără sudo, coloana cu procesul rămâne goală și sensul se pierde.

Trebuie privită coloana Local Address:Port, iar diferența de acolo este esențială:

  • 127.0.0.1:3306 — serviciul este accesibil doar de pe mașina însăși. Asta e bine;
  • 0.0.0.0:3306 — de la toate adresele IPv4, adică din internet. Asta trebuie verificat;
  • [::]:3306 — același lucru pentru IPv6. O linie separată, care se uită în mod regulat;
  • 203.0.113.25:443 — pe o adresă anume, de obicei intenționat.

Apoi, la fiecare linie cu 0.0.0.0 sau [::], pui o singură întrebare: trebuie să poată ajunge aici un străin? Pentru 80 și 443 răspunsul este da. Pentru aproape tot restul este nu.

Descoperiri obișnuite

Redis, portul 6379. Cea mai periculoasă linie posibilă. Implicit, Redis nu cere parolă, iar comenzile lui permit scrierea unui fișier pe disc — adică o cheie străină în authorized_keys. Între apariția Redis pe o adresă publică și exploatarea lui trec ore, uneori mai puțin. Verifică bind 127.0.0.1 și protected-mode yes în configurație.

Memcached, 11211/UDP. Chiar dacă înăuntru nu e nimic valoros, serverul tău devine un amplificator în atacurile altora — iar reclamațiile vin de la furnizorul de găzduire.

MySQL și PostgreSQL, 3306 și 5432. Parolă există, dar ghicirea se desfășoară neîntrerupt, iar versiunile bazelor de date se actualizează mai rar decât ar trebui. În afară nu sunt necesare aproape niciodată: aplicația este pe aceeași mașină, iar pentru lucru ajunge un tunel SSH.

Elasticsearch 9200, MongoDB 27017. Istoric, fără autentificare implicită. Instanțele publice ale acestor servicii sunt o sursă constantă de știri despre scurgeri de date.

API-ul Docker, 2375. Un port de control Docker deschis înseamnă root pe mașină, complet fără parolă. Apare de obicei după experimente cu accesul la distanță la Docker.

Panouri de control și phpMyAdmin pe porturile lor: 8080, 8083, 10000. Nu e vorba că nu ar putea fi deschise niciodată, dar tocmai ele atrag fluxul principal de încercări.

Repară la nivelul serviciului, nu al firewallului

Tentația de a închide fiecare descoperire cu o regulă UFW este de înțeles, dar aceasta este a doua linie, nu prima. O regulă poate fi ștearsă din greșeală, firewallul oprit o clipă la depanare, iar Docker publică porturi ocolind complet UFW. Setarea legării în configurația serviciului supraviețuiește tuturor acestora:

  • MySQL/MariaDB — bind-address = 127.0.0.1;
  • PostgreSQL — listen_addresses = 'localhost';
  • Redis — bind 127.0.0.1 ::1;
  • Docker Compose — publicare ca "127.0.0.1:5432:5432".

Firewallul se adaugă deasupra ca asigurare, nu în locul acestora.

Găsirea procesului când nu știi ce este

ss arată numele și pid-ul. Apoi:

sudo systemctl status <pid>
sudo lsof -i :8080

Prima comandă numește unitatea systemd de care aparține procesul — de obicei este suficient pentru a înțelege ce este și dacă este necesar. Un proces necunoscut care ascultă pe un port înalt și a pornit din afara directoarelor de sistem — de exemplu din /tmp sau /dev/shm — nu mai este o chestiune de configurare, ci motiv pentru o investigație separată.

Verificarea din exterior este obligatorie

ss răspunde la întrebarea „ce ascultă”, nu „unde se poate ajunge”. Între cele două stau firewallul, NAT și regulile furnizorului. Singurul răspuns onest îl dă o scanare de pe altă mașină:

nmap -Pn -p- 203.0.113.25
nmap -Pn -p- -6 2001:db8::1

Nu sări peste a doua comandă: adresă IPv6 are aproape orice VPS, regulile pentru ea se scriu separat, iar serviciul ascultă pe ambele versiuni de protocol simultan.

Aceasta nu este o verificare unică

Lista porturilor deschise se schimbă de la sine. Ai instalat un pachet — a adus un serviciu și a deschis un port. Ai actualizat panoul — a restaurat setarea implicită. Ai pornit un container — a publicat un port ocolind firewallul. O verificare unică răspunde pentru ziua de azi și pentru nimic mai mult.

Valoarea nu stă în lista însăși, ci în schimbările ei: un port nou, care ieri nu exista, este un semnal scurt și foarte grăitor. Exact așa merită privită — ca un instantaneu cu istoric, nu ca o ieșire ss reprodusă din memorie. Pagina demonstrativă de mai jos arată exact asta.