6. Examples (Esempi)

Questa sezione consiste in alcuni esempi di sezioni Security Considerations, intesi a dare al lettore un’idea di ciò che questo documento intende.

Il primo esempio è un esempio "retrospettivo", che applica i criteri di questo documento a un protocollo ampiamente dispiegato esistente, SMTP. Il secondo esempio è una buona sezione Security Considerations estratta da un protocollo corrente.

6.1. SMTP

Quando è stato scritto l’RFC 821, le sezioni Security Considerations non erano richieste negli RFC, e nessuna è contenuta in quel documento. [RFC 2821] ha aggiornato l’RFC 821 e ha aggiunto una sezione security considerations dettagliata. Qui riproduciamo la sezione Security Considerations da quel documento (con nuovi numeri di sezione). I nostri commenti sono rientrati e preceduti da "NOTA:". Aggiungiamo anche vari nuovi paragrafi per coprire argomenti che consideriamo importanti. Tali sezioni sono marcate con [NEW] nell’intestazione di sezione.

6.1.1. Security Considerations (Considerazioni di sicurezza)

6.1.1.1. Mail Security and Spoofing (Sicurezza della posta e spoofing)

La posta SMTP è intrinsecamente insicura nel senso che è fattibile anche per utenti piuttosto occasionali negoziare direttamente con server SMTP riceventi e di relay e creare messaggi che inganneranno un destinatario naïf facendogli credere che provengano da altrove. Costruire tale messaggio in modo che il comportamento "spoofato" non possa essere rilevato da un esperto è un po’ più difficile, ma non abbastanza da essere un deterrente per qualcuno che è determinato e competente. Di conseguenza, man mano che la conoscenza della posta Internet aumenta, così aumenta la consapevolezza che la posta SMTP intrinsecamente non può essere autenticata, o avere controlli di integrità forniti, a livello di trasporto. La vera sicurezza della posta sta solo in metodi end-to-end che coinvolgono i corpi del messaggio, come quelli che usano firme digitali (vedere [14] e, ad esempio, PGP [4] o S/MIME [31]).

NOTA: Un cattivo approccio all’autenticazione del mittente è [IDENT] in cui il server di posta ricevente contatta il presunto mittente e chiede il nome utente del mittente. Questa è una cattiva idea per varie ragioni, inclusi ma non limitati a relay, dirottamento della connessione TCP e semplice menzogna da parte del server di origine. Oltre al fatto che IDENT ha basso valore di sicurezza, l’uso di IDENT dai siti riceventi può causare problemi operativi. Molti siti mittenti scartano le richieste IDENT, causando così che la posta sia trattenuta fino al timeout della richiesta IDENT del server ricevente.

Varie estensioni di protocollo e opzioni di configurazione che forniscono autenticazione a livello di trasporto (ad esempio, da un client SMTP a un server SMTP) migliorano un po’ la situazione tradizionale descritta sopra. Tuttavia, a meno che non siano accompagnate da passaggi di responsabilità attenti in un ambiente di fiducia accuratamente progettato, restano intrinsecamente più deboli dei meccanismi end-to-end che usano messaggi firmati digitalmente piuttosto che dipendere dall’integrità del sistema di trasporto.

Gli sforzi per rendere più difficile per gli utenti impostare il percorso di ritorno dell’envelope e i campi header "From" per puntare a indirizzi validi diversi dai propri sono in gran parte fuorvianti: frustrano applicazioni legittime in cui la posta è inviata da un utente per conto di un altro o in cui le risposte di errore (o normali) dovrebbero essere dirette a un indirizzo speciale. (I sistemi che forniscono modi convenienti per gli utenti di alterare questi campi su base per-messaggio dovrebbero tentare di stabilire un indirizzo di casella primario e permanente per l’utente così che i campi Sender all’interno dei dati del messaggio possano essere generati sensatamente.)

Questa specifica non affronta ulteriormente le questioni di autenticazione associate a SMTP oltre a sostenere che la funzionalità utile non sia disabilitata nella speranza di fornire un piccolo margine di protezione contro un utente ignorante che sta cercando di falsificare posta.

NOTA: Abbiamo aggiunto materiale supplementare sulla sicurezza delle comunicazioni e SMTP nella sezione 6.1.2 In una specifica finale, il testo sopra sarebbe modificato un po’ per riflettere tale fatto.

Indirizzi che non compaiono negli header del messaggio possono comparire nei comandi RCPT a un server SMTP per vari motivi. I due più comuni coinvolgono l’uso di un indirizzo di mailing come "list exploder" (un singolo indirizzo che si risolve in più indirizzi) e la comparsa di "copie nascoste" (blind copies). Specialmente quando è presente più di un comando RCPT, e per evitare di vanificare parte dello scopo di questi meccanismi, i client e server SMTP NON DOVREBBERO copiare l’insieme completo degli argomenti del comando RCPT negli header, sia come parte di header di traccia sia come header informativi o di estensione privata. Poiché questa regola è spesso violata in pratica e non può essere applicata, i sistemi SMTP mittenti che sono consapevoli dell’uso "bcc" POSSONO trovare utile inviare ogni copia nascosta come transazione di messaggio separata contenente solo un singolo comando RCPT.

Non c’è relazione intrinseca né tra indirizzi "inversi" (da comandi MAIL, SAML, ecc.) né "in avanti" (RCPT) nella transazione SMTP ("envelope") e gli negli header. I sistemi riceventi NON DOVREBBERO tentare di dedurre tali relazioni e usarle per alterare gli header del messaggio per la consegna. Il popolare header "Apparently-to" è una violazione di questo principio così come una fonte comune di divulgazione involontaria di informazioni e NON DOVREBBE essere usato.

6.1.1.3. VRFY, EXPN, and Security (VRFY, EXPN e sicurezza)

Come discusso nella sezione 3.5, singoli siti possono voler disabilitare VRFY o EXPN o entrambi per ragioni di sicurezza. Come corollario di quanto sopra, le implementazioni che consentono ciò NON DEVONO sembrare aver verificato indirizzi che in effetti non sono verificati. Se un sito disabilita questi comandi per ragioni di sicurezza, il server SMTP DEVE restituire una risposta 252, piuttosto che un codice che potrebbe essere confuso con verifica riuscita o fallita.

Restituire un codice di risposta 250 con l’indirizzo elencato nel comando VRFY dopo averlo controllato solo per la sintassi viola questa regola. Naturalmente, un’implementazione che "supporta" VRFY restituendo sempre 550 sia che l’indirizzo sia valido o meno è ugualmente non conforme.

Negli ultimi anni, il contenuto delle mailing list è diventato popolare come fonte di informazioni sugli indirizzi per i cosiddetti "spammer". L’uso di EXPN per "raccogliere" indirizzi è aumentato man mano che gli amministratori di list hanno installato protezioni contro usi inappropriati delle list stesse. Le implementazioni DOVREBBERO ancora fornire supporto per EXPN, ma i siti DOVREBBERO valutare attentamente i compromessi. Man mano che meccanismi di autenticazione sono introdotti in SMTP, alcuni siti possono scegliere di rendere EXPN disponibile solo a richiedenti autenticati.

NOTA: Non è chiaro che disabilitare VRFY aggiunga molta protezione, poiché spesso è possibile scoprire se un indirizzo è valido usando RCPT TO.

6.1.1.4. Information Disclosure in Announcements (Divulgazione di informazioni negli annunci)

C’è stato un dibattito continuo sui compromessi tra i vantaggi di debug dell’annuncio del tipo e versione del server (e, talvolta, persino il nome di dominio del server) nella risposta di saluto o in risposta al comando HELP e gli svantaggi dell’esposizione di informazioni che potrebbero essere utili in un attacco potenzialmente ostile. L’utilità delle informazioni di debug è fuori dubbio. Chi sostiene di renderle disponibili sottolinea che è molto meglio effettivamente proteggere un server SMTP piuttosto che sperare che tentare di nascondere vulnerabilità note nascondendo l’identità precisa del server fornisca più protezione. I siti sono incoraggiati a valutare il compromesso tenendo presente questa questione; le implementazioni sono fortemente incoraggiate a fornire al minimo un modo per rendere disponibili informazioni su tipo e versione ad altri host di rete.

6.1.1.5. Information Disclosure in Trace Fields (Divulgazione di informazioni nei campi di traccia)

In alcune circostanze, come quando la posta origina da una LAN i cui host non sono direttamente su Internet pubblico, i campi di traccia ("Received") prodotti in conformità a questa specifica possono divulgare nomi host e informazioni simili che normalmente non sarebbero disponibili. Ciò ordinariamente non pone un problema, ma i siti con preoccupazioni speciali sulla divulgazione dei nomi dovrebbero esserne consapevoli. Inoltre, la clausola FOR opzionale dovrebbe essere fornita con cautela o per niente quando sono coinvolti più destinatari, per evitare che divulghi inadvertitamente le identità di destinatari "copia nascosta" ad altri.

6.1.1.6. Information Disclosure in Message Forwarding (Divulgazione di informazioni nell’inoltramento dei messaggi)

Come discusso nella sezione 3.4, l’uso dei codici di risposta 251 o 551 per identificare l’indirizzo sostitutivo associato a una casella può inadvertitamente divulgare informazioni sensibili. I siti che sono preoccupati di queste questioni dovrebbero assicurarsi di selezionare e configurare i server appropriatamente.

6.1.1.7. Scope of Operation of SMTP Servers (Ambito di operazione dei server SMTP)

È un principio ben stabilito che un server SMTP può rifiutare di accettare posta per qualsiasi ragione operativa o tecnica che abbia senso per il sito che fornisce il server. Tuttavia, la cooperazione tra siti e installazioni rende possibile Internet. Se i siti approfittano eccessivamente del diritto di rifiutare traffico, l’ubiquità della disponibilità della posta elettronica (uno dei punti di forza di Internet) sarà minacciata; dovrebbe essere presa cura considerevole e mantenuto l’equilibrio se un sito decide di essere selettivo sul traffico che accetterà ed elaborerà.

Negli ultimi anni, l’uso della funzione di relay attraverso siti arbitrari è stato usato come parte di sforzi ostili per nascondere le origini effettive della posta. Alcuni siti hanno deciso di limitare l’uso della funzione di relay a sorgenti note o identificabili, e le implementazioni DOVREBBERO fornire la capacità di eseguire questo tipo di filtraggio. Quando la posta è rifiutata per queste o altre ragioni di policy, un codice 550 DOVREBBE essere usato in risposta a EHLO, MAIL o RCPT come appropriato.

6.1.1.8. Inappropriate Usage (Uso inappropriato)

SMTP di per sé non fornisce protezione contro la posta commerciale di massa non sollecitata (detta spam). È estremamente difficile dire a priori se un dato messaggio è spam o meno. Da una prospettiva di protocollo, lo spam è indistinguibile da altra posta elettronica: la distinzione è quasi interamente sociale e spesso piuttosto sottile. (Ad esempio, un messaggio da un commerciante da cui avete acquistato articoli prima che pubblicizza articoli simili è spam?) I meccanismi di soppressione dello spam SMTP sono generalmente limitati all’identificazione di mittenti spam noti e al rifiuto di servirli o al bersagliarli per punizione/disconnessione. [RFC-2505] fornisce guida estensiva su come rendere i server SMTP resistenti allo spam. Forniamo una breve discussione dell’argomento qui.

Lo strumento primario per il rifiuto di servizio agli spammer è la blacklist. Qualche autorità come [MAPS] raccoglie e pubblica un elenco di spammer noti. Singoli server SMTP poi bloccano i trasgressori in blacklist (in genere per indirizzo IP).

Per evitare di essere in blacklist o altrimenti identificati, gli spammer spesso tentano di offuscare la loro identità, sia semplicemente inviando un’identità SMTP falsa sia inoltrando la loro posta attraverso un Open Relay, un server SMTP che eseguirà relay di posta per qualsiasi mittente. Di conseguenza, ci sono ora blacklist [ORBS] di open relay altrettanto.

6.1.1.8.1. Closed Relaying (Relay chiuso)

Per evitare di essere usati per l’inoltramento dello spam, molti server SMTP operano come relay chiusi, fornendo servizio di relay solo per client che possono identificare. Tali relay dovrebbero in genere insistere che i mittenti annuncino un indirizzo di invio coerente con la loro identità nota. Se il relay fornisce servizio per una rete identificabile (come una rete aziendale o la rete di un ISP) allora è sufficiente bloccare tutti gli altri indirizzi IP. In altri casi, deve essere usata autenticazione esplicita. Le due scelte standard per questo sono TLS [STARTTLS] e SASL [SASLSMTP].

6.1.1.8.2. Endpoints (Endpoint)

Realisticamente, gli endpoint SMTP non possono rifiutare servizio a mittenti non autenticati. Poiché la stragrande maggioranza dei mittenti è non autenticata, ciò romperebbe l’interoperabilità della posta Internet. L’eccezione è quando il server endpoint dovrebbe ricevere posta solo da qualche altro server che può a sua volta ricevere messaggi non autenticati. Ad esempio, un’azienda potrebbe operare un gateway pubblico ma configurare i suoi server interni per parlare solo con il gateway.

6.1.2. Communications security issues (Questioni di sicurezza delle comunicazioni)

SMTP di per sé non fornisce sicurezza delle comunicazioni, e quindi un gran numero di attacchi è possibile. Un attacco passivo è sufficiente per recuperare il testo dei messaggi trasmessi con SMTP. Nessuna autenticazione degli estremi è fornita dal protocollo. Lo spoofing del mittente è banale, e quindi falsificare messaggi di posta elettronica è banale. Alcune implementazioni aggiungono righe header con nomi host derivati tramite risoluzione inversa dei nomi (sicura solo nella misura in cui è difficile fare spoofing del DNS, non molto), sebbene queste righe header normalmente non siano mostrate agli utenti. Lo spoofing del destinatario è anche abbastanza semplice, sia usando dirottamento della connessione TCP sia spoofing DNS. Inoltre, poiché i messaggi di posta spesso passano attraverso gateway SMTP, tutti i gateway intermedi devono essere attendibili, una condizione quasi impossibile su Internet globale.

Vari approcci sono disponibili per alleviare queste minacce. In ordine di livello sempre più alto nello stack di protocollo, abbiamo:

SMTP over IPSEC SMTP/TLS S/MIME e PGP/MIME

6.1.2.1. SMTP over IPSEC

Una connessione SMTP eseguita su IPSEC può fornire riservatezza per il messaggio tra il mittente e il primo hop del gateway SMTP, o tra qualsiasi coppia di gateway SMTP connessi. Cioè, fornisce sicurezza del canale per le connessioni SMTP. In una situazione in cui il messaggio va direttamente dal client al gateway del ricevitore, ciò può fornire sicurezza sostanziale (sebbene il ricevitore debba ancora fidarsi del gateway). È fornita protezione contro attacchi di replay, poiché i dati stessi sono protetti e i pacchetti non possono essere riprodotti.

L’identificazione degli estremi è un problema, tuttavia, a meno che l’indirizzo del ricevitore non possa essere autenticato direttamente in modo crittografico. L’identificazione del mittente non è in genere disponibile, poiché in genere è autenticata solo la macchina del mittente, non il mittente stesso. Inoltre, l’identità del mittente compare semplicemente nell’header From del messaggio, quindi è facilmente falsificabile dal mittente. Infine, a meno che la politica di sicurezza non sia impostata estremamente rigorosamente, c’è anche un attivo downgrade al testo in chiaro.

Un altro problema con IPsec come soluzione di sicurezza per SMTP è la mancanza di un’API IPsec standard. Per trarre vantaggio da IPsec, le applicazioni in genere devono poter istruire l’implementazione IPsec sulle loro politiche di sicurezza e scoprire quale protezione è stata applicata alle loro connessioni. Senza un’API standard ciò è molto difficile da fare in modo portabile.

Gli implementatori di server SMTP o gli amministratori SMTP NON DEVONO assumere che IPsec sarà disponibile a meno che non abbiano ragione di crederlo (come l’esistenza di un’associazione preesistente tra due macchine). Tuttavia, può essere una procedura ragionevole tentare di creare un’associazione IPsec opportunisticamente a un server peer quando la posta è consegnata. Si noti che nei casi in cui IPsec è usato per fornire un tunnel VPN tra due siti, ciò ha sostanziale valore di sicurezza, in particolare nella misura in cui è fornita riservatezza, soggetto alle riserve menzionate sopra. Vedere anche [USEIPSEC] per guida generale sull’applicabilità di IPsec.

6.1.2.2. SMTP/TLS

SMTP può essere combinato con TLS come descritto in [STARTTLS]. Ciò fornisce protezione simile a quella fornita usando IPSEC. Poiché i certificati TLS tipicamente contengono il nome host del server, l’autenticazione del destinatario può essere leggermente più ovvia, ma è ancora suscettibile ad attacchi di spoofing DNS. In particolare, implementazioni comuni di TLS contengono una modalità esportabile USA (e quindi a bassa sicurezza). Le applicazioni che desiderano alta sicurezza dovrebbero assicurarsi che questa modalità sia disabilitata. È fornita protezione contro attacchi di replay, poiché i dati stessi sono protetti e i pacchetti non possono essere riprodotti. [Nota: La sezione Security Considerations del documento SMTP su TLS è piuttosto buona e merita di essere letta come esempio di come fare le cose.]

6.1.2.3. S/MIME and PGP/MIME

S/MIME e PGP/MIME sono entrambi protocolli di sicurezza orientati al messaggio. Forniscono sicurezza dell’oggetto per singoli messaggi. Con varie impostazioni, possono essere fornite autenticazione del mittente e del destinatario e riservatezza. Più importante, l’identificazione non è delle macchine mittente e riceventi, ma piuttosto del mittente e del destinatario stessi. (O, almeno, di chiavi crittografiche corrispondenti al mittente e al destinatario.) Di conseguenza, può essere ottenuta sicurezza end-to-end. Si noti, tuttavia, che non è fornita protezione contro attacchi di replay. Si noti anche che S/MIME e PGP/MIME in genere forniscono segni identificativi sia per mittente sia per ricevitore. Così anche quando è fornita riservatezza, l’analisi del traffico è ancora possibile.

6.1.3. Denial of Service (Negazione del servizio)

Nessuna di queste misure di sicurezza fornisce protezione reale contro la negazione del servizio. Le connessioni SMTP possono facilmente essere usate per impegnare risorse di sistema in vari modi, incluso consumo eccessivo di porte, uso eccessivo del disco (la posta elettronica è tipicamente consegnata in file su disco) e consumo eccessivo di memoria (sendmail, ad esempio, è abbastanza grande e tipicamente effettua la fork di un nuovo processo per gestire ogni messaggio.)

Se la sicurezza a livello di trasporto o applicativo è usata per connessioni SMTP, è possibile montare vari attacchi su singole connessioni usando RST falsificati o altri tipi di iniezione di pacchetti.

6.2. VRRP

Il secondo esempio proviene da VRRP, il Virtual Router Redundancy Protocol ([VRRP]). Qui riproduciamo la sezione Security Considerations da quel documento (con nuovi numeri di sezione). I nostri commenti sono rientrati e preceduti da "NOTA:".

6.2.1. Security Considerations (Considerazioni di sicurezza)

VRRP è progettato per una gamma di ambienti internetworking che possono impiegare diverse politiche di sicurezza. Il protocollo include vari metodi di autenticazione che vanno da nessuna autenticazione, password semplici in chiaro, ad autenticazione forte usando IP Authentication con MD5 HMAC. I dettagli su ciascun approccio inclusi possibili attacchi e ambienti raccomandati seguono.

Indipendentemente dal tipo di autenticazione VRRP include un meccanismo (impostazione TTL=255, controllo alla ricezione) che protegge contro pacchetti VRRP iniettati da un’altra rete remota. Ciò limita la maggior parte delle vulnerabilità ad attacchi locali.

NOTA: Le misure di sicurezza discusse nelle sezioni seguenti forniscono solo vari tipi di autenticazione. Non è fornita alcuna riservatezza. Ciò dovrebbe essere esplicitamente descritto come fuori dall’ambito.

6.2.1.1. No Authentication (Nessuna autenticazione)

L’uso di questo tipo di autenticazione significa che gli scambi di protocollo VRRP non sono autenticati. Questo tipo di autenticazione DOVREBBE essere usato solo in ambienti in cui c’è rischio di sicurezza minimo e poche possibilità di errori di configurazione (ad esempio, due router VRRP su una LAN).

6.2.1.2. Simple Text Password (Password in testo semplice)

L’uso di questo tipo di autenticazione significa che gli scambi di protocollo VRRP sono autenticati da una password semplice in chiaro.

Questo tipo di autenticazione è utile per proteggere contro errori di configurazione accidentali dei router su una LAN. Protegge contro router che inadvertitamente fanno backup di un altro router. Un nuovo router deve prima essere configurato con la password corretta prima di poter eseguire VRRP con un altro router. Questo tipo di autenticazione non protegge contro attacchi ostili dove la password può essere appresa da un nodo che intercetta pacchetti VRRP sulla LAN. L’autenticazione Simple Text combinata con il controllo TTL rende difficile che un pacchetto VRRP sia inviato da un’altra LAN per disturbare l’operazione VRRP.

Questo tipo di autenticazione è RACCOMANDATO quando c’è rischio minimo che nodi su una LAN disturbino attivamente l’operazione VRRP. Se questo tipo di autenticazione è usato l’utente dovrebbe essere consapevole che questa password in chiaro è inviata frequentemente, e quindi non dovrebbe essere la stessa di qualsiasi password significativa per la sicurezza.

NOTA: Questa sezione dovrebbe essere più chiara. Il punto di base è che nessuna autenticazione e Simple Text sono utili solo per un modello di minaccia molto limitato, cioè che nessuno dei nodi sulla LAN locale sia ostile. Il controllo TTL previene nodi ostili fuori-LAN dal fingersi nodi validi, ma nulla ferma nodi ostili sulla LAN dal impersonare nodi autorizzati. Questo non è un modello di minaccia particolarmente realistico in molte situazioni. In particolare, è estremamente fragile: la compromissione di qualsiasi nodo sulla LAN consente la riconfigurazione dei nodi VRRP.

6.2.1.3. IP Authentication Header (Intestazione di autenticazione IP)

L’uso di questo tipo di autenticazione significa che gli scambi di protocollo VRRP sono autenticati usando i meccanismi definiti dall’IP Authentication Header [AH] usando [HMAC]. Ciò fornisce forte protezione contro errori di configurazione, attacchi di replay e corruzione/modifica di pacchetti.

Questo tipo di autenticazione è RACCOMANDATO quando c’è controllo limitato sull’amministrazione dei nodi su una LAN. Sebbene questo tipo di autenticazione protegga l’operazione di VRRP, ci sono altri tipi di attacchi che possono essere impiegati su collegamenti a media condivisa (ad esempio, generazione di risposte ARP false) che sono indipendenti da VRRP e non sono protetti.

NOTA: È un errore che AH sia RACCOMANDATO in questo contesto. Poiché AH è l’unico meccanismo che protegge VRRP da attacco da altri nodi sulla stessa LAN, dovrebbe essere un DEVE per i casi in cui ci sono nodi non attendibili sulla stessa rete. In ogni caso, AH dovrebbe essere un DEVE implementare.

NOTA: C’è un pezzo importante di analisi di sicurezza che è solo accennato in questo documento, cioè il compromesso costo/beneficio dell’autenticazione VRRP.

[Il resto di questa sezione è materiale NEW] La minaccia che l’autenticazione VRRP intende prevenire è un attaccante che organizza di essere il master VRRP. Ciò sarebbe fatto unendosi al gruppo (probabilmente più volte), imbavagliando il master e poi eleggendo sé stesso master. Tale nodo potrebbe poi dirigere il traffico in modi arbitrariamente indesiderati.

Tuttavia, non è necessario per un attaccante essere il master VRRP per fare ciò. Un attaccante può fare danni simili alla rete falsificando pacchetti ARP o (su reti commutate) ingannando lo switch. L’autenticazione VRRP non offre protezione reale contro questi attacchi.

Purtroppo, l’autenticazione rende le reti VRRP molto fragili di fronte a errori di configurazione. Considerate cosa succede se due nodi sono configurati con password diverse. Ciascuno rifiuterà messaggi dall’altro e quindi entrambi tenteranno di essere master. Ciò crea instabilità di rete sostanziale.

Questo insieme di compromessi costo/beneficio suggerisce che l’autenticazione VRRP è una cattiva idea, poiché il beneficio incrementale di sicurezza è marginale ma il rischio incrementale è alto. Questo giudizio dovrebbe essere rivalutato se l’insieme attuale di minacce non-VRRP viene rimosso.