Vai al contenuto

Impostazioni cookie

Scelga per ogni tipo quali cookie consente. Può modificare la sua scelta in qualsiasi momento tramite Impostazioni cookie in fondo a ogni pagina. Informativa sulla privacy

Necessari

Sempre attivi

Servono per accedere, conservare il carrello e ricordare le sue scelte. Sono sempre attivi.

Quali cookie?
  • weboke_sessie, weboke_klant, weboke_remember: la sua sessione e la permanenza dell'accesso
  • weboke_basket: il suo carrello
  • wkBtwIncl: visualizzazione dei prezzi con o senza IVA
  • wok_cookies: la sua scelta sui cookie, 12 mesi

Misurano quale annuncio porta a una visita o a un ordine, così non paghiamo annunci che non funzionano.

Quali cookie?
  • Google Ads tramite Google Tag Manager (_gcl_au, _gcl_aw), fino a 90 giorni
  • OpenAI Ads, annunci in ChatGPT
  • wok_aff: tramite quale partner è arrivato da noi (programma di affiliazione), 60 giorni

4,6

Paese e lingua

Ogni paese ha il suo sito, con i prezzi e l'IVA di quel paese.

Vedi

Quali servizi sono in ascolto sul Suo VPS e cosa è raggiungibile dall'esterno?

Ogni programma che accetta connessioni è in ascolto su una porta: SSH sulla 22, un web server sulla 80 e sulla 443, MariaDB sulla 3306. Ogni porta raggiungibile dall'esterno è una via d'accesso al Suo server. Un sito web, dall'esterno, di solito ha bisogno solo delle porte 22, 80 e 443. In questo articolo scopre come vedere cosa è in ascolto, su quale indirizzo, e come verificare cosa vede il resto di Internet.

Vedere cosa è in ascolto

Esegua sul Suo VPS:

sudo ss -tulpn

Le opzioni significano: TCP (-t), UDP (-u), solo in ascolto (-l), quale programma (-p) e numeri invece di nomi (-n). Un esempio:

tcp LISTEN 0.0.0.0:22       users:(("sshd",...))
tcp LISTEN 0.0.0.0:443      users:(("nginx",...))
tcp LISTEN 127.0.0.1:3306   users:(("mariadbd",...))
tcp LISTEN 0.0.0.0:6379     users:(("redis-server",...))
tcp LISTEN [::]:22          users:(("sshd",...))

La colonna importante è Local Address, l'indirizzo su cui il programma è in ascolto:

IndirizzoSignificato
0.0.0.0Tutti gli indirizzi IPv4, quindi anche il Suo indirizzo pubblico: raggiungibile dall'esterno, a meno che un firewall non lo blocchi
[::]Tutti gli indirizzi IPv6: lo stesso, ma per IPv6
127.0.0.1 o [::1]Solo il server stesso (loopback): mai raggiungibile dall'esterno
127.0.0.53 o 127.0.0.54Anche questo è loopback: il resolver DNS locale di systemd-resolved

Nell'esempio MariaDB è a posto: solo i programmi sul server stesso possono accedervi. Redis invece è in ascolto su tutti gli indirizzi, ed è proprio questo l'errore da evitare.

Chiudere l'accesso nel servizio stesso

Un database, una cache o un pannello di gestione non dovrebbero quasi mai essere raggiungibili dall'esterno. Il primo passo migliore è fare in modo che il servizio sia in ascolto solo sul loopback. Su Debian e Ubuntu:

ProgrammaImpostazioneFile
MariaDB o MySQLbind-address = 127.0.0.1/etc/mysql/mariadb.conf.d/50-server.cnf
PostgreSQLlisten_addresses = 'localhost'/etc/postgresql/<versione>/main/postgresql.conf
Redisbind 127.0.0.1 -::1 e protected-mode yes/etc/redis/redis.conf

Riavvii poi il servizio (consulti Gestire i servizi con systemctl sul Suo VPS) e controlli di nuovo con ss -tulpn. Se desidera accedere al database dal Suo portatile, utilizzi un tunnel SSH invece di una porta aperta; consulti Una configurazione SSH: accedere con un nome breve.

Il firewall come secondo livello

Un firewall blocca ciò che, per errore, è comunque in ascolto su tutti gli indirizzi. Come configurare ufw è spiegato in Un firewall con ufw (o nftables). Non si affidi a un solo livello: un firewall può essere disattivato oppure una regola può essere troppo permissiva.

Le porte pubblicate con Docker (ports:) aggirano ufw. Un database con "3306:3306" è quindi raggiungibile dall'esterno, anche se ufw indica che la porta è chiusa. Anteponga 127.0.0.1: oppure non pubblichi la porta. Consulti Docker e il firewall: pubblicare le porte in modo sicuro.

Verificare dall'esterno

ss mostra cosa è in ascolto sul server, ma non cosa lascia passare il Suo firewall. La verifica reale va fatta da un altro computer, non dal server stesso. Con nc (netcat) su Mac o Linux:

nc -vz -w 3 203.0.113.10 6379
nc -6 -vz -w 3 2001:db8::10 6379

Su Windows, PowerShell fa lo stesso con Test-NetConnection 203.0.113.10 -Port 6379. Inserisca il Suo indirizzo IPv4 e IPv6, che trova nella schermata del VPS. Il risultato si interpreta così:

  • Aperta (succeeded): qualcosa è in ascolto ed è raggiungibile dall'esterno.
  • Chiusa (Connection refused): nulla è in ascolto, oppure il firewall rifiuta attivamente la connessione.
  • Filtrata (time-out): un firewall scarta il traffico in modo silenzioso.

Per un database, chiusa e filtrata vanno entrambe bene. Verifichi anche IPv6: un errore frequente è un firewall con sole regole IPv4, mentre il servizio è in ascolto anche su [::]. Uno scanner di porte come nmap controlla più porte contemporaneamente; utilizzi uno scanner del genere solo sul Suo server.

Il Suo server viene scansionato fin dal primo minuto, anche sulle porte di database e cluster di ricerca. Se è attivo un servizio che non conosce, verifichi di cosa si tratta e lo rimuova se non Le serve. Ciò che non è in esecuzione non può causare fughe di dati.

Il Suo VPS è interamente in autogestione: quali servizi sono in ascolto e come è configurato il firewall dipende da Lei. Noi La aiutiamo con la parte di WebOké, come la schermata del VPS, la rete e gli snapshot.

Desidera saperne di più? Segua il corso gratuito VPS e amministrazione di server Linux, lezione 5.1 Porte e servizi in ascolto o lezione 5.2 Un firewall con ufw e nftables.

Questo articolo le è stato utile?

← Torna a Hosting VPS

Un momento…

Configuri i suoi domini

Per ogni dominio imposti i nameserver, il collegamento al suo hosting e chi ne diventa l'intestatario.

Caricamento dei suoi domini…