Cum să monitorizați un port TCP (și când să alertați dacă unul este deschis)

Monitorizarea porturilor reprezintă două sarcini într-una. Uneori doriți să știți că un serviciu ascultă, cum ar fi o bază de date sau un releu SMTP. Alteori doriți să știți că un port rămâne blocat de firewall, cum ar fi SSH pe o instanță expusă la internet. Aceeași sondă răspunde ambelor întrebări, dar alertați pentru rezultate opuse. Acest ghid acoperă când să folosiți fiecare mod, ce să alertați și porturile care îi surprind pe oameni.

Cum funcționează cu adevărat un monitor de port TCP

Un monitor de port TCP deschide un socket către țintă pe portul ales și așteaptă finalizarea strângerii de mână în trei pași. Dacă strângerea de mână reușește, portul este deschis. Dacă conexiunea este refuzată, portul este închis. Dacă conexiunea expiră, ceva între sondă și gazda dumneavoastră elimină pachetul, de obicei un firewall.

Sonda nu vorbește un protocol peste socket. Nu negociază TLS, nu schimbă banere SSH și nu rulează o interogare de bază de date. Vă spune doar dacă portul răspunde. Pentru sănătatea la nivel de aplicație aveți nevoie de o verificare HTTP sau personalizată deasupra.

Când doriți portul DESCHIS

Folosiți monitorizarea porturilor ca o sondă de sănătate a serviciului atunci când nu puteți face cu ușurință o verificare HTTP. Apar cinci cazuri frecvente.

• Servere de baze de date pe portul 5432 (Postgres), 3306 (MySQL), 6379 (Redis), 27017 (MongoDB). Dacă ascultătorul se blochează, fiecare serviciu dependent se defectează, dar nu puteți rula o sondă HTTP.
• Relee SMTP pe portul 25 sau 587. Verificările banerului SMTP detectează blocările ascultătorului pe care endpoint-urile interne de sănătate le ratează.
• Servere de jocuri și alte protocoale TCP personalizate care nu vorbesc HTTP.
• Echilibratoare de încărcare interne care expun un port de sănătate non-HTTP către serviciile din amonte.
• Endpoint-uri VPN pe porturi UDP-dar-și-TCP precum 443 pentru OpenVPN-TCP și WireGuard.

Când doriți portul ÎNCHIS

Monitorizarea inversată a porturilor este o protecție de securitate. Setați monitorul să alerteze când portul devine deschis, deoarece nu ar trebui să fie niciodată deschis din internetul public. Modelul detectează lucrurile care merg prost într-o săptămână normală de modificări de infrastructură.

Cineva deschide temporar o regulă de firewall pentru depanare și uită să o revoce. Un serviciu Kubernetes primește un tip LoadBalancer din greșeală. O nouă instanță primește grupul de securitate greșit. O modificare a unui modul Terraform expune un port care trebuia să fie intern. În fiecare caz, monitorul de port inversat detectează expunerea în cadrul unui singur interval de verificare.

Porturile cu valoare ridicată care merită monitorizate invers chiar acum

Cinci porturi merită să configurați o verificare inversată pentru orice gazdă expusă la internet care nu ar trebui să le expună.

• 22 (SSH) pe serverele de aplicații de producție. Accesul exclusiv prin bastion este norma, iar un port SSH deschis accidental apare în jurnalele de scanare în masă în câteva ore.
• 3306 (MySQL) și 5432 (Postgres). Porturile publice de baze de date sunt responsabile pentru o pondere semnificativă a atacurilor de tip credential-stuffing.
• 6379 (Redis). Redis deschis fără autentificare este una dintre cele mai exploatate configurări greșite din industrie.
• 27017 (MongoDB). Aceeași poveste ca la Redis. Configurație implicită, fără autentificare, port public înseamnă pierdere de date.
• 9200 (Elasticsearch). Clusterele deschise sunt extrase, minate și luate ostatice în câteva ore.

Praguri de alertare pentru monitorizarea porturilor

Sănătatea serviciului (portul ar trebui să fie DESCHIS) necesită același model de prag ca HTTP: alertare după 3 eșecuri consecutive, suprimarea fluctuațiilor scurte. Întreruperile de rețea care închid o singură sondă sunt zgomot.

Securitatea (portul ar trebui să fie ÎNCHIS) necesită opusul. Alertați la prima detectare. Un port SSH sau Redis deschis accidental este un eveniment de gradul cinci. Boții scanează constant internetul public, iar fereastra dintre expunere și compromitere pe un port binecunoscut se măsoară în minute.

O listă de verificare inițială pentru monitorizarea porturilor de securitate

Pentru fiecare IP expus la internet pe care îl operează echipa dumneavoastră, setați monitoare inversate pe 22, 3306, 5432, 6379 și 27017 la un interval de 60 de secunde. Direcționați alertele către canalul de securitate, separat de alertele de sănătate a serviciilor. O dată pe trimestru, rulați o scanare reală de porturi pe propriile IP-uri ca element de control. Costul este mic, acoperirea este largă, iar modurile de eșec pe care le detectează sunt catastrofale.