Sostituire i protocolli non sicuri: Telnet e SSH, FTP e SFTP
Comprenda perché i protocolli in chiaro come Telnet, FTP e HTTP espongano le credenziali e come le loro alternative crittografate (SSH, SFTP, HTTPS) risolvano il problema.
Sostituire i protocolli non sicuri: Telnet e SSH, FTP e SFTP è una lezione Security+ Academy gratuita su CoddyKit. Questa è la lezione 1 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Security+ Academy, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Security+ Academy include 4 lezioni in totale.
Il problema dei protocolli in chiaro
Molti protocolli Internet fondamentali sono stati progettati negli anni Settanta e Ottanta, quando la sicurezza non era una preoccupazione primaria. I protocolli in chiaro trasmettono tutti i dati, inclusi nomi utente, password e informazioni sensibili, in formato non cifrato sulla rete. Qualsiasi dispositivo presente nello stesso segmento di rete, o qualsiasi sistema attraversato dai pacchetti, può acquisire e leggere questo traffico con strumenti disponibili gratuitamente come Wireshark. Negli ambienti con switch di rete, che normalmente isolano il traffico tra le porte, lo spoofing ARP può reindirizzare il traffico verso il sistema di un aggressore, rendendo pericolosi i protocolli in chiaro anche sulle reti «interne».
# What an attacker sees on the wire with Telnet
# (captured via Wireshark or tcpdump)
tcpdump -i eth0 -A port 23
# Sample Telnet capture output:
..login: admin..
..password: S3cr3tPa$$...
..$ ls -la /etc/passwd..
# Every keystroke is visible in plaintext
# Credentials, commands, and file contents - all exposedTelnet e SSH
Telnet (porta TCP 23) fornisce l’accesso remoto alla riga di comando dei sistemi, ma trasmette tutto in formato non cifrato. Non dispone di autenticazione integrata oltre a nome utente e password, che vengono inviati senza cifratura. SSH (Secure Shell) (porta TCP 22) sostituisce Telnet con un canale cifrato e autenticato. SSH utilizza uno scambio di chiavi asimmetrico per stabilire una chiave di sessione, quindi cifra tutte le comunicazioni successive con la cifratura simmetrica. SSH autentica anche il server, impedendone l’usurpazione, e supporta l’autenticazione con chiave pubblica (senza password, ma più sicura delle password), oltre all’autenticazione tramite password.
# SSH connection (encrypted, server authenticated)
ssh admin@192.168.1.10
# SSH key-based authentication (no password)
ssh -i ~/.ssh/id_rsa admin@192.168.1.10
# Generate SSH key pair
ssh-keygen -t ed25519 -C 'admin@company.com'
# Copy public key to server
ssh-copy-id -i ~/.ssh/id_rsa.pub admin@192.168.1.10
# Disable Telnet on network devices (Cisco IOS)
no service telnet
line vty 0 4
transport input ssh
login localScambio di chiavi e autenticazione SSH
La sicurezza di SSH si basa su un solido processo di scambio delle chiavi. Durante la connessione, il client verifica la chiave host del server confrontandola con una copia memorizzata localmente: questo impedisce l’usurpazione del server. Se la chiave host cambia in modo imprevisto, SSH avvisa l’utente; ciò è un segnale comune di un attacco man-in-the-middle. Dopo aver verificato il server, l’autenticazione del client può utilizzare: password (cifrata durante il transito, ma vulnerabile al brute force), chiave pubblica (il client dimostra di possedere la chiave privata; è molto più sicura) oppure keyboard-interactive (supporta l’MFA). Le organizzazioni dovrebbero imporre l’autenticazione basata su chiavi e disabilitare l’autenticazione tramite password sui servizi SSH esposti a Internet.
# Harden SSH server configuration
# /etc/ssh/sshd_config
Port 22
PermitRootLogin no
PasswordAuthentication no # Require key auth only
ChallengeResponseAuthentication no
MaxAuthTries 3
AllowUsers admin deploy
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
ClientAliveInterval 300 # Disconnect idle sessions
ClientAliveCountMax 0
# Restart SSH after changes
systemctl restart sshdFTP, SFTP e FTPS a confronto
FTP (File Transfer Protocol) (porte TCP 20/21) trasferisce i file in formato non cifrato: credenziali, comandi e dati dei file sono tutti esposti. FTP utilizza inoltre un canale dati separato, in modalità passiva o attiva, che complica le regole del firewall. SFTP (SSH File Transfer Protocol) incanala il trasferimento dei file attraverso SSH sulla porta 22: è completamente diverso da FTP e condivide con esso solo un nome simile. FTPS (FTP Secure) aggiunge la cifratura TLS al protocollo FTP originale. In genere si preferisce SFTP perché utilizza una sola porta ed eredita l’autenticazione e la cifratura di SSH. FTP dovrebbe essere disabilitato su tutti i sistemi di produzione.
# SFTP usage (over SSH, single connection)
sftp admin@fileserver.company.com
sftp> put localfile.zip /uploads/
sftp> get /reports/monthly.pdf .
sftp> ls /uploads/
sftp> exit
# Automated SFTP transfer with key auth
sftp -i ~/.ssh/id_rsa admin@fileserver.company.com <<EOF
put /tmp/report.csv /incoming/
EOF
# Disable FTP on Linux (remove vsftpd)
apt purge vsftpd
# Verify no FTP listener:
ss -tlnp | grep ':21'HTTP e HTTPS a confronto
HTTP (porta TCP 80) trasmette contenuti Web, inclusi dati dei moduli, cookie di sessione e token di autenticazione, in formato non cifrato. HTTPS (porta TCP 443) incapsula HTTP in TLS, fornendo cifratura, autenticazione del server e integrità dei dati. Le organizzazioni dovrebbero imporre HTTPS ovunque: reindirizzare tutto il traffico HTTP a HTTPS (reindirizzamento 301), implementare HSTS per impedire ai browser di connettersi tramite HTTP e configurare i flag dei cookie secure e HttpOnly per impedire il furto dei token di sessione tramite HTTP o JavaScript. I browser moderni contrassegnano i siti HTTP come «Non sicuri»: HTTPS è ormai il requisito di base per tutti i servizi Web.
# nginx: force HTTPS redirect
server {
listen 80;
server_name example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
ssl_certificate /etc/ssl/example.crt;
ssl_certificate_key /etc/ssl/example.key;
add_header Strict-Transport-Security
'max-age=31536000; includeSubDomains; preload';
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options SAMEORIGIN;
}SNMP v1/v2 e SNMPv3 a confronto
SNMP (Simple Network Management Protocol) gestisce dispositivi e server di rete. SNMPv1 e v2c utilizzano community string, sostanzialmente password condivise, inviate in chiaro. Community string come «public» (lettura) e «private» (scrittura) sono valori predefiniti noti agli aggressori. Un aggressore che intercetta il traffico SNMP apprende la community string e può leggere le configurazioni dei dispositivi o modificarne le impostazioni. SNMPv3 aggiunge autenticazione (HMAC-MD5 o HMAC-SHA) e cifratura (AES) con credenziali specifiche per utente, rendendolo l’unica versione adatta agli ambienti di produzione. SNMPv1/v2c dovrebbe essere disabilitato.
# SNMPv3 configuration (Cisco IOS)
snmp-server group MYGROUP v3 priv
snmp-server user MONITORUSER MYGROUP v3 \
auth sha MyAuthP@ss priv aes 128 MyPrivP@ss
# SNMPv3 query from monitoring server
snmpwalk -v3 -l authPriv \
-u MONITORUSER \
-a SHA -A MyAuthP@ss \
-x AES -X MyPrivP@ss \
192.168.1.1 sysDescr
# Disable SNMPv1/v2c:
no snmp-server community public ro
no snmp-server community private rwLDAP e LDAPS a confronto
LDAP (Lightweight Directory Access Protocol) (porta TCP 389) autentica ed esegue query sui servizi directory (Active Directory, OpenLDAP) in formato non cifrato per impostazione predefinita, esponendo credenziali e dati della directory. LDAPS (LDAP su SSL/TLS, porta TCP 636) cifra la connessione utilizzando un certificato. StartTLS è un’alternativa che aggiorna una connessione LDAP esistente a TLS utilizzando la stessa porta 389. Sia LDAPS sia StartTLS forniscono cifratura, ma in genere LDAPS è più semplice e affidabile. Le organizzazioni dovrebbero configurare tutte le applicazioni che utilizzano LDAP per usare LDAPS e bloccare LDAP in chiaro sulla porta 389 tramite il firewall.
POP3/IMAP e recupero della posta elettronica cifrato
I client di posta legacy recuperano i messaggi utilizzando POP3 (porta 110) e IMAP (porta 143) in formato non cifrato. Alternative cifrate: POP3S (porta 995, TLS) e IMAPS (porta 993, TLS). Le moderne piattaforme di posta elettronica (Exchange Online, Google Workspace) impongono TLS per tutte le connessioni dei client e supportano l’autenticazione basata su token OAuth 2.0 anziché sulle password. Le organizzazioni dovrebbero disabilitare l’autenticazione di base nei protocolli di posta elettronica: richiedere l’autenticazione moderna (OAuth 2.0 + MFA) impedisce gli attacchi di credential stuffing che sfruttano i meccanismi di autenticazione in chiaro dei protocolli di posta elettronica legacy.
# Protocol port reference card
Protocol Insecure Port Secure Port Replacement
--------- ------------ ---------- -----------
Telnet 23 22 SSH
FTP 20/21 22 SFTP
HTTP 80 443 HTTPS
SMTP 25 587/465 SMTPS
POP3 110 995 POP3S
IMAP 143 993 IMAPS
LDAP 389 636 LDAPS
SNMP 161/162 161/162 SNMPv3
RDP 3389 3389 RDP+NLA+TLSSostituzione dei protocolli nella pratica
La sostituzione dei protocolli non sicuri richiede più della semplice abilitazione della versione sicura: la versione non sicura deve essere disabilitata attivamente. Procedura: verifichi l’uso dei protocolli esistenti (scansioni Nmap, log del firewall), esegua la migrazione delle applicazioni e delle configurazioni al protocollo sicuro, esegua test approfonditi, poiché le applicazioni aziendali potrebbero non funzionare, quindi blocchi il protocollo non sicuro sul firewall e sull’host. Problemi comuni: le stampanti legacy e i dispositivi integrati supportano spesso solo FTP o SNMPv2; i sistemi industriali legacy possono dipendere da Telnet. In questi casi sono necessari l’isolamento della rete o la sostituzione da parte del fornitore, non un semplice aggiornamento del protocollo.
# Audit for insecure protocol usage
# Nmap: find all Telnet listeners on network
nmap -p 23 10.0.0.0/24 --open -sV
# Find FTP listeners
nmap -p 21 10.0.0.0/24 --open
# Find HTTP (not HTTPS) web services
nmap -p 80 --open 10.0.0.0/24
# Check for SNMPv1/v2c community strings
nmap -sU -p 161 --script snmp-info 10.0.0.0/24
# Block Telnet at firewall after migration
iptables -A FORWARD -p tcp --dport 23 -j DROP
iptables -A INPUT -p tcp --dport 23 -j DROPSicurezza del Remote Desktop Protocol
RDP (Remote Desktop Protocol) (porta 3389) è ampiamente utilizzato per l’amministrazione remota di Windows ed è un bersaglio frequente degli attacchi. Le configurazioni RDP non sicure includono: esposizione della porta 3389 a Internet, utilizzo della sola autenticazione tramite password e disabilitazione di NLA. Rafforzamento di RDP: abiliti la Network Level Authentication (NLA), che autentica l’utente prima dell’apertura della sessione completa, bloccando le connessioni non autenticate; richieda TLS 1.2+ per tutte le sessioni RDP; collochi RDP dietro una VPN o un gateway RDP anziché esporlo a Internet; imponga il blocco degli account per impedire gli attacchi brute force. Molte campagne ransomware ottengono l’accesso iniziale tramite RDP esposto e protetto in modo insufficiente.
Dismissione graduale dei protocolli non sicuri
La migrazione dai protocolli non sicuri negli ambienti di produzione richiede una pianificazione attenta per evitare interruzioni operative. Un approccio graduale: Fase 1 — Individuazione: esegua scansioni Nmap e controlli i log del firewall per identificare tutti gli usi dei protocolli in chiaro. Fase 2 — Abilitazione delle alternative sicure: configuri SSH, SFTP e HTTPS insieme ai servizi non sicuri esistenti. Fase 3 — Migrazione dei sistemi che utilizzano i protocolli: aggiorni script, applicazioni, strumenti di monitoraggio e procedure degli utenti affinché utilizzino il protocollo sicuro. Fase 4 — Disabilitazione e blocco: disabiliti il servizio non sicuro su ogni host e blocchi la porta sul firewall. Eseguire test a ogni fase previene le interruzioni dei servizi di produzione.
# Phase 4: Disable and block Telnet permanently
# Disable Telnet service on Linux
systemctl stop telnet.socket
systemctl disable telnet.socket
# Block Telnet at iptables
iptables -A INPUT -p tcp --dport 23 -j DROP
iptables -A OUTPUT -p tcp --dport 23 -j DROP
# Save rules
iptables-save > /etc/iptables/rules.v4
# Block at network firewall (Cisco ASA)
access-list OUTSIDE_IN deny tcp any any eq 23
# Verify: should timeout / connection refused
nc -zv 192.168.1.10 23Verifica rapida
Verificate la vostra comprensione dei concetti di CompTIA Security+ (SY0-701) trattati in questa lezione.
Riepilogo della lezione
In questa lezione avete imparato che i protocolli in chiaro (Telnet, FTP, HTTP, SNMPv1/v2c, LDAP) espongono credenziali e dati all'intercettazione sulla rete e devono essere sostituiti, che le sostituzioni sicure (SSH, SFTP, HTTPS, SNMPv3, LDAPS) usano la crittografia TLS o SSH per proteggere le stesse funzionalità e che la sostituzione dei protocolli richiede la disabilitazione della versione non sicura a livello di firewall e di host dopo aver verificato la presenza di dipendenze legacy. Ora esamineremo le versioni di TLS, le suite di cifratura e la perfect forward secrecy.
Domande Frequenti
La lezione «Sostituire i protocolli non sicuri: Telnet e SSH, FTP e SFTP» è gratuita?
Sì — il testo completo di «Sostituire i protocolli non sicuri: Telnet e SSH, FTP e SFTP» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Security+ Academy, passa a CoddyKit PRO. Il corso Security+ Academy include 4 lezioni in totale.
Cosa imparerò in «Sostituire i protocolli non sicuri: Telnet e SSH, FTP e SFTP»?
Comprenda perché i protocolli in chiaro come Telnet, FTP e HTTP espongano le credenziali e come le loro alternative crittografate (SSH, SFTP, HTTPS) risolvano il problema. Eserciti Security+ Academy con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.
Ho bisogno di esperienza per iniziare Security+ Academy?
Non è richiesta alcuna esperienza precedente. Security+ Academy su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 1 di 4.
Quanto tempo richiede la lezione «Sostituire i protocolli non sicuri: Telnet e SSH, FTP e SFTP»?
La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.
Posso scrivere ed eseguire codice in questa lezione Security+ Academy?
Sì. Ogni lezione Security+ Academy include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.
Tutte le lezioni di questo corso
- Sostituire i protocolli non sicuri: Telnet e SSH, FTP e SFTP
- Versioni TLS, cipher suite e perfect forward secrecy
- DNS sicuro: DNSSEC e DNS su HTTPS (DoH)
- IPsec, protocolli VPN e sicurezza dell'accesso remoto