Ghid pentru Scanner de porturi
Cum testează Scanner de porturi de la XGM porturile TCP ale unei gazde publice, ce înseamnă deschis, închis și filtrat și cum închideți porturile riscante.
Ce face Scanner de porturi
Un port TCP este locul în care un serviciu ascultă conexiuni: 443 pentru HTTPS, 25 pentru e-mailul dintre servere, 22 pentru SSH. Dacă un port este accesibil de pe internet depinde de serviciu, de firewallul gazdei, de grupurile de securitate din cloud și de firewallurile de rețea aflate între ele. O testare din interiorul propriei rețele vă spune puțin despre ce pot atinge cei din exterior. Același server poate arăta o suprafață complet diferită privit de la birou. De aceea expunerea trebuie măsurată întotdeauna din afara rețelei.
Scanner de porturi se conectează de pe serverul XGM la gazda și la porturile alese de dumneavoastră, exact cum ar face orice client din exterior. Testează doar porturile pe care le enumerați, cel mult 200 deodată; presetarea Top 100 acoperă porturile găsite cel mai des deschise. Pe un port deschis citește salutul pe care serverele SSH, SMTP, FTP, POP3, IMAP și MySQL îl trimit de la sine și trimite o singură cerere HEAD către porturile HTTP și HTTPS. Nu se autentifică și nu caută vulnerabilități; scopul este doar să arate ce se vede din exterior.
Cum folosiți Scanner de porturi
- Deschideți Scanner de porturi și introduceți un nume de gazdă public sau o adresă IP de care răspundeți.
- Introduceți porturile ca listă separată prin virgule sau ca intervale, de exemplu
80, 443, 8000-8005, ori alegeți o presetare: Web, E-mail, Acces la distanță, Baze de date sau Cele mai comune 20. - Rulați verificarea și citiți rezultatul pentru fiecare port: deschis, cu latența afișată, închis sau filtrat.
- Citiți explicația de sub fiecare port deschis: dacă este așteptat pe această gazdă, ce înseamnă expunerea și ce aveți de făcut.
| Presetare | Porturi |
|---|---|
| Web | 80, 443, 8080, 8443 |
| 25, 465, 587, 110, 143, 993, 995 | |
| Acces la distanță | 22, 23, 3389, 5900 |
| Baze de date | 3306, 5432, 6379, 27017, 1433, 9200 |
| Cele mai comune 20 | 21, 22, 23, 25, 53, 80, 110, 143, 443, 445, 465, 587, 993, 995, 1433, 3306, 3389, 5432, 6379, 8080 |
Testați doar gazdele de care răspundeți
Raportul de expunere a porturilor
Fila Raport complet din Scanner de porturi rulează raportul de expunere a porturilor: o listă fixă și sigură de porturi uzuale de servicii (80, 443, 22, 25, 53, 8080 și 8443), cu un scor, rezultate și recomandări. Folosiți Verificare rapidă pentru porturile alese de dumneavoastră și raportul atunci când vreți aceeași bază de comparație pentru fiecare server. Raportul era înainte o pagină separată la /tools/port-exposure-report; acea adresă deschide acum această filă. Rularea aceleiași liste pe fiecare server face ușoară compararea rezultatelor la nivelul întregii flote. Astfel priviți tendința generală, nu porturi izolate.
Deschis, închis și filtrat
| Stare | Ce s-a întâmplat | Ce înseamnă de obicei |
|---|---|---|
| Deschis | Negocierea TCP s-a încheiat | Un serviciu ascultă, iar firewallul permite conexiunea |
| Închis | Gazda a răspuns cu un reset | Gazdă accesibilă, nimic nu ascultă pe acel port |
| Filtrat (fără răspuns) | Niciun răspuns în 1,5 secunde | Un firewall aruncă pachetele sau gazda este căzută ori foarte lentă |
Rulați verificarea de două ori dacă un rezultat vă surprinde. Un singur timeout poate fi o problemă de rețea trecătoare. Același rezultat obținut la două momente diferite este o dovadă mult mai solidă.
Filtrat este cea mai bună stare pentru porturile pe care nu le folosiți, pentru că dezvăluie cel mai puțin. Închis este la fel de bine. Un port deschis este o problemă doar când serviciul din spatele lui nu ar trebui să fie public sau când este public, dar prost securizat. De aceea cea mai sănătoasă abordare este să justificați, port cu port, de ce fiecare intrare deschisă se află acolo.
Rezultatele vin dintr-o singură locație și dintr-un singur moment. Firewallurile pot permite unele adrese sursă și altele nu, echilibratoarele de sarcină din cloud pot răspunde pe porturi pe care backendul nu le servește, iar limitarea ratei poate transforma un port deschis într-un timeout după teste repetate. Din acest motiv, nu interpretați un rezultat neașteptat pe baza unei singure rulări.
Porturi care nu ar trebui să fie publice
| Port | Serviciu | De ce este riscant |
|---|---|---|
| 21 | FTP | Datele de autentificare sunt trimise în clar |
| 23 | Telnet | Totul, inclusiv parolele, este trimis în clar |
| 445 | SMB | Un punct de intrare frecvent pentru ransomware atunci când este expus |
| 1433, 3306, 5432 | SQL Server, MySQL, PostgreSQL | Bazele de date nu ar trebui să fie niciodată accesibile de pe internet |
| 3389 | Desktop la distanță | Atacat masiv prin forță brută; puneți-l în spatele unui VPN |
| 5900 | VNC | Adesea cu autentificare slabă |
| 6379 | Redis | Fără autentificare în mod implicit; abuzat frecvent |
| 9200 | Elasticsearch | Clusterele expuse pierd adesea date |
| 27017 | MongoDB | Instanțele expuse pierd adesea date |
Bazele de date și serviciile de acces la distanță expuse se află în spatele unei părți însemnate din scurgerile de date și din incidentele cu ransomware. Scanerele automate găsesc instanțe nou expuse în câteva ore de la apariția lor online. Tratați ca pe o descoperire urgentă orice astfel de port care apare deschis. Nu este nevoie ca cineva să vă vizeze anume pentru ca o bază de date publică să fie găsită.
Cum închideți sau restricționați porturile
Cea mai curată soluție este ca serviciul să asculte doar pe o interfață privată, așa încât din exterior să nu existe nimic de atins. Acolo unde serviciul trebuie să accepte conexiuni de la distanță, restricționați adresele sursă într-un firewall sau într-un grup de securitate din cloud și puneți accesul administrativ în spatele unui VPN ori al unei gazde-bastion. Astfel întrebarea dacă un serviciu trebuie să fie public devine o decizie asumată pentru fiecare port. Restricționarea după adresa sursă nu înlocuiește o parolă sau o cheie; folosiți-le împreună.
# PostgreSQL: listen only on localhost and the private network (postgresql.conf)
listen_addresses = 'localhost,10.0.0.5'
# Redis: bind to localhost and require a password (redis.conf)
bind 127.0.0.1 ::1
requirepass use-a-long-random-secret
# ufw: allow SSH only from an office address
ufw allow from 203.0.113.10 to any port 22 proto tcp
ufw deny 22/tcp- În cloud, verificați grupurile de securitate și listele ACL de rețea, nu doar firewallul gazdei.
- Containerele pot publica implicit porturile pe toate interfețele; publicați-le pe
127.0.0.1atunci când doar un proxy local are nevoie de ele. - După o modificare, rulați din nou Scanner de porturi din exterior, ca să confirmați că portul este acum închis sau filtrat.
- Documentați ce porturi trebuie să expună fiecare server, ca abaterile apărute în timp să fie observate.
Verificarea serverelor de mail și de web
Pentru un server de mail, portul 25 trebuie să fie deschis pentru a primi e-mail de la alte servere, iar 465 sau 587 pentru utilizatorii dumneavoastră care trimit e-mail cu autentificare. IMAP (993) și POP3 (995) sunt pentru clienții de e-mail. IMAP simplu (143) și POP3 (110), fără TLS, ar trebui închise acolo unde clienții acceptă porturile criptate. Separarea acestor trei grupuri face mai ușor de văzut care port este cu adevărat necesar.
Pentru un site, porturile 80 și 443 sunt cele așteptate. Porturi precum 8080 sau 8443 aparțin adesea unor panouri de administrare, servere de dezvoltare ori servere de aplicație menite să stea în spatele unui proxy. Dacă unul dintre ele este deschis, verificați ce răspunde acolo și dacă ar trebui să fie public, apoi confirmați certificatul cu Verificator TLS. Un mediu de testare uitat sau o interfață de administrare ies la iveală tocmai în acest fel.
Întrebări frecvente
Este acesta un scanner de porturi?
Este o verificare țintită. Testează doar porturile pe care le enumerați, cel mult 200. Porturilor deschise li se cere un banner (o cerere HEAD pe porturile HTTP, doar ascultare pe celelalte); nu se autentifică niciodată și nu caută vulnerabilități. Fiecare port deschis este apoi explicat pornind de la ce știe deja scanarea - portul, bannerul și DNS-ul invers - astfel încât un server web pe 80 și 443 să apară ca normal, în timp ce o bază de date, un port de administrare sau o interfață de administrare primește o frază despre ce înseamnă expunerea și ce aveți de făcut.
De ce este un port filtrat când serviciul rulează?
Un firewall, un grup de securitate sau rețeaua furnizorului aruncă conexiunile din exterior ori serviciul ascultă doar pe o interfață privată. De cele mai multe ori asta este intenționat.
Pot verifica porturi UDP?
Nu. Instrumentul testează doar conexiuni TCP. Serviciile UDP, precum DNS sau VPN-urile, au nevoie de teste specifice protocolului.
Pot testa o adresă IP privată?
Nu. Adresele private, de loopback și interne sunt refuzate, pentru că XGM rulează verificările de pe un server public și nu trebuie să ajungă în rețele interne.
De ce s-a schimbat latența între rulări?
Timpul de conectare depinde de traseele de rețea și de încărcarea serverului în acel moment. Variațiile mici sunt normale și nu sunt singure un semn de problemă.
De ce este portul 25 filtrat pe serverul meu din cloud?
Mulți furnizori de cloud blochează implicit portul 25, ca să prevină spamul. Trimiteți e-mailul printr-un serviciu de e-mail sau cereți furnizorului procedura de deblocare, dacă administrați un server de mail.
De ce apare portul 443 deschis pe un IP fără site?
Echilibratoarele de sarcină, CDN-urile și unele platforme de găzduire acceptă conexiuni pe adrese partajate pentru mai mulți clienți. Faptul că portul este deschis spune că ceva acceptă TCP acolo, nu că site-ul dumneavoastră este configurat.
Un port deschis înseamnă că am fost spart?
Nu. Înseamnă că un serviciu este accesibil. Dacă asta este o problemă depinde de serviciu, de autentificarea lui și de faptul că ar trebui sau nu să fie public.