4. Common Issues (Questioni comuni)

Sebbene i requisiti di sicurezza di ciascun sistema siano unici, certi requisiti comuni compaiono in vari protocolli. Spesso, quando i progettisti di protocolli naïf si trovano di fronte a questi requisiti, scelgono una soluzione ovvia ma insicura anche se esistono soluzioni migliori. Questa sezione descrive varie questioni riscontrate in molti protocolli e i pezzi comuni di tecnologia di sicurezza che possono essere utili per affrontarle.

4.1. User Authentication (Autenticazione dell’utente)

Essenzialmente ogni sistema che vuole controllare l’accesso alle proprie risorse ha bisogno di un modo per autenticare gli utenti. Un numero quasi innumerevole di tali meccanismi è stato progettato a questo scopo. Le prossime sezioni descrivono alcune di queste tecniche.

4.1.1. Username/Password (Nome utente/Password)

Il meccanismo di controllo degli accessi più comune è il semplice USERNAME/PASSWORD (nome utente/password). L’utente fornisce un nome utente e una password riutilizzabile all’host che desidera usare. Questo sistema è vulnerabile a un semplice attacco passivo in cui l’attaccante intercetta la password dal cavo e poi avvia una nuova sessione presentando la password. Questa minaccia può essere mitigata ospitando il protocollo su una connessione cifrata come TLS o IPSEC. I sistemi nome utente/password non protetti (in chiaro) non sono accettabili negli standard IETF.

4.1.2. Challenge Response and One Time Passwords (Challenge-response e password monouso)

I sistemi che desiderano maggiore sicurezza del semplice nome utente/password spesso impiegano uno schema ONE TIME PASSWORD (password monouso) [OTP] o un CHALLENGE-RESPONSE (sfida-risposta). In uno schema a password monouso, all’utente è fornito un elenco di password, che devono essere usate in sequenza, una volta ciascuna. (Spesso queste password sono generate da qualche chiave segreta così che l’utente possa semplicemente calcolare la password successiva nella sequenza.) SecureID e DES Gold sono varianti di questo schema. In uno schema challenge-response, l’host e l’utente condividono un segreto (che spesso è rappresentato come una password). Per autenticare l’utente, l’host presenta all’utente una sfida (generata casualmente). L’utente calcola una funzione basata sulla sfida e sul segreto e la fornisce all’host, che la verifica. Spesso questo calcolo è eseguito in un dispositivo portatile, come una carta DES Gold.

Entrambi i tipi di schema forniscono protezione contro l’attacco di replay, ma sono spesso ancora vulnerabili a un ATTACCO DI RICERCA DI CHIAVE OFFLINE (OFFLINE KEYSEARCH ATTACK, forma di attacco passivo): come menzionato in precedenza, spesso la password monouso o la risposta è calcolata da un segreto condiviso. Se l’attaccante conosce la funzione usata, può semplicemente provare tutti i segreti condivisi possibili finché non ne trova uno che produce l’output corretto. Ciò è più facile se il segreto condiviso è una password, nel qual caso può montare un ATTACCO A DIZIONARIO (DICTIONARY ATTACK), cioè provare un elenco di parole comuni (o stringhe) piuttosto che sole stringhe casuali.

Questi sistemi sono spesso anche vulnerabili a un attacco attivo. A meno che la sicurezza delle comunicazioni non sia fornita per l’intera sessione, l’attaccante può semplicemente aspettare che l’autenticazione sia stata eseguita e dirottare la connessione.

4.1.3. Shared Keys (Chiavi condivise)

I sistemi di tipo CHALLENGE-RESPONSE possono essere resi sicuri contro attacchi a dizionario usando chiavi condivise generate casualmente invece di password generate dall’utente. Se le chiavi sono sufficientemente grandi, gli attacchi di ricerca di chiave diventano impraticabili. Questo approccio funziona meglio quando le chiavi sono configurate nei nodi finali piuttosto che memorizzate e digitate dagli utenti, poiché gli utenti hanno difficoltà a ricordare chiavi sufficientemente lunghe.

Come i sistemi basati su password, i sistemi a chiave condivisa soffrono di problemi di gestione. Ogni coppia di parti comunicanti deve avere la propria chiave concordata, il che porta a un gran numero di chiavi.

4.1.4. Key Distribution Centers (Centri di distribuzione delle chiavi)

Un approccio per risolvere il problema del gran numero di chiavi è usare una "terza parte fidata" online che media tra le parti autenticanti. La terza parte fidata (in genere chiamata KEY DISTRIBUTION CENTER, KDC) condivide una chiave simmetrica o una password con ciascuna parte nel sistema. Ciascuna parte contatta prima il KDC, che le fornisce un TICKET contenente una chiave simmetrica generata casualmente cifrata sotto le chiavi di entrambi i pari. Poiché solo i pari corretti possono decifrare la chiave simmetrica, il ticket può essere usato per stabilire un’associazione attendibile. Di gran lunga il sistema KDC più popolare è Kerberos [KERBEROS].

4.1.5. Certificates (Certificati)

Un approccio semplice è far sì che tutti gli utenti abbiano CERTIFICATI [PKIX] che poi usano per autenticarsi in qualche modo specifico del protocollo, come in [TLS] o [S/MIME]. Un certificato è una credenziale firmata che lega l’identità di un’entità alla sua chiave pubblica. Il firmatario di un certificato è una CERTIFICATE AUTHORITY (CA, autorità di certificazione), il cui certificato può essere a sua volta firmato da una CA superiore. Affinché questo sistema funzioni, la fiducia in una o più CA deve essere stabilita fuori banda. Tali CA sono indicate come TRUSTED ROOTS o ROOT CA. L’ostacolo principale a questo approccio nei sistemi client-server è che richiede certificati per i client, il che può essere un problema di dispiegamento.

4.1.6. Some Uncommon Systems (Alcuni sistemi meno comuni)

Esistono modi per fare meglio degli schemi menzionati sopra, ma tipicamente non aggiungono molta sicurezza a meno che la sicurezza delle comunicazioni (almeno l’integrità dei messaggi) non sia impiegata per proteggere la connessione, perché altrimenti l’attaccante può semplicemente dirottare la connessione dopo che l’autenticazione è stata eseguita. Vari protocolli ([EKE], [SPEKE], [SRP]) consentono di avviare in modo sicuro la password dell’utente verso una chiave condivisa che può essere usata come input a un protocollo crittografico. Un ostacolo maggiore al dispiegamento di questi protocolli è stato che il loro stato di proprietà intellettuale è estremamente poco chiaro. Allo stesso modo, l’utente può autenticarsi usando certificati a chiave pubblica (ad esempio, autenticazione client S-HTTP). Tipicamente questi metodi sono usati come parte di un protocollo di sicurezza più completo.

4.1.7. Host Authentication (Autenticazione dell’host)

L’autenticazione dell’host presenta un problema speciale. Abbastanza comunemente, gli indirizzi dei servizi sono presentati usando un nome host DNS, ad esempio come URL [URL]. Quando si richiede tale servizio, bisogna assicurarsi che l’entità con cui si sta parlando non solo abbia un certificato ma che quel certificato corrisponda all’identità attesa del server. L’elemento importante è avere un legame sicuro tra il certificato e il nome host atteso.

Ad esempio, di solito non è accettabile che il certificato contenga un’identità nella forma di un indirizzo IP se la richiesta era per un dato nome host. Ciò non fornisce sicurezza end-to-end perché la mappatura nome host-IP non è sicura a meno che non sia usata la risoluzione sicura dei nomi [DNSSEC]. Questo è un problema particolare quando il nome host è presentato a livello applicativo ma l’autenticazione è eseguita a un livello inferiore.

4.2. Generic Security Frameworks (Framework di sicurezza generici)

Fornire funzionalità di sicurezza in un protocollo può essere difficile. Oltre al problema di scegliere meccanismi di autenticazione e stabilimento di chiavi, bisogna integrarli nel protocollo. Una risposta a questo problema (incarnata in IPsec e TLS) è creare un protocollo di sicurezza di livello inferiore e poi insistere che i nuovi protocolli siano eseguiti su quel protocollo. Un altro approccio che è recentemente diventato popolare è progettare framework di sicurezza generici a livello applicativo. L’idea è progettare un protocollo che consenta di negoziare vari meccanismi di sicurezza in modo modulare. I progettisti di protocolli applicativi poi organizzano il trasporto delle PDU del protocollo di sicurezza nel loro protocollo applicativo. Esempi di tali framework includono GSS-API [GSS] e SASL [SASL].

L’approccio del framework generico ha vari problemi. Primo, è altamente suscettibile agli ATTACCHI DI DOWNGRADE (DOWNGRADE ATTACKS). In un attacco di downgrade, un attaccante attivo manomette la negoziazione per forzare le parti a negoziare una protezione più debole di quella che altrimenti farebbero. È possibile includere un controllo di integrità dopo che negoziazione e stabilimento di chiave sono entrambi completati, ma la forza di questo controllo di integrità è necessariamente limitata all’algoritmo comune più debole. Questo problema esiste con qualsiasi approccio di negoziazione, ma i framework generici lo aggravano incoraggiando l’autore del protocollo applicativo a specificare solo il framework piuttosto che riflettere attentamente sui meccanismi sottostanti appropriati, in particolare poiché i meccanismi possono variare molto nel grado di sicurezza offerto.

Un altro problema è che non è sempre ovvio come le varie funzionalità di sicurezza nel framework interagiscano con il protocollo a livello applicativo. Ad esempio, SASL può essere usato meramente come framework di autenticazione, nel qual caso lo scambio SASL avviene ma il resto della connessione non è protetto, ma può anche negoziare la protezione del traffico, ad esempio tramite GSS, come meccanismo. Sapere in quali circostanze la protezione del traffico è opzionale e quando è richiesta richiede di riflettere sul modello di minaccia.

In generale, i framework di autenticazione sono più utili in situazioni in cui nuovi protocolli sono aggiunti a sistemi con sistemi di autenticazione legacy preesistenti. Un framework consente alle nuove installazioni di fornire migliore autenticazione senza forzare i siti esistenti a rifare completamente i loro sistemi di autenticazione legacy. Quando i requisiti di sicurezza di un sistema possono essere chiaramente identificati e sono usate solo poche forme di autenticazione, scegliere un singolo meccanismo di sicurezza porta a maggiore semplicità e prevedibilità. In situazioni in cui debba essere usato un framework, i progettisti DOVREBBERO esaminare attentamente le opzioni del framework e specificare solo i meccanismi appropriati per il loro particolare modello di minaccia. Se un framework è necessario, i progettisti DOVREBBERO scegliere uno di quelli consolidati invece di progettare il proprio.

4.3. Non-repudiation (Non ripudio)

L’approccio naïf al non ripudio è semplicemente usare firme digitali a chiave pubblica sul contenuto. La parte che desidera essere vincolata (SIGNING PARTY, parte firmataria) firma digitalmente il messaggio in questione. La controparte (RELYING PARTY, parte che fa affidamento) può successivamente indicare la firma digitale come prova che la parte firmataria in un dato momento ha accettato il messaggio contestato. Purtroppo, questo approccio è insufficiente.

Il modo più facile per la parte firmataria di ripudiare il messaggio è sostenere che la sua chiave privata è stata compromessa e che qualche attaccante (anche se non necessariamente la parte che fa affidamento) ha firmato il messaggio contestato. Per difendersi da questo attacco la parte che fa affidamento deve dimostrare che la chiave della parte firmataria non era stata compromessa al momento della firma. Ciò richiede infrastruttura sostanziale, inclusa archiviazione di informazioni di revoca dei certificati e server di timestamp per stabilire il momento in cui il messaggio è stato firmato.

Inoltre, la parte che fa affidamento potrebbe tentare di ingannare la parte firmataria affinché firmi un messaggio mentre crede di firmarne un altro. Questo problema è particolarmente grave quando la parte che fa affidamento controlla l’infrastruttura che la parte firmataria usa per firmare, come in situazioni chiosco. In molte tali situazioni la chiave della parte firmataria è tenuta su una smart card ma il messaggio da firmare è visualizzato dalla parte che fa affidamento.

Tutte queste complicazioni rendono il non ripudio un servizio difficile da dispiegare in pratica.

4.4. Authorization vs. Authentication (Autorizzazione rispetto ad autenticazione)

L’AUTHORIZATION (autorizzazione) è il processo con cui si determina se una parte autenticata ha il permesso di accedere a una particolare risorsa o servizio. Sebbene strettamente legati, è importante rendersi conto che autenticazione e autorizzazione sono due meccanismi separati. Forse a causa di questo accoppiamento stretto, l’autenticazione è talvolta erroneamente considerata come implicare l’autorizzazione. L’autenticazione identifica semplicemente una parte; l’autorizzazione definisce se possono compiere una certa azione.

L’autorizzazione si affida necessariamente all’autenticazione, ma l’autenticazione da sola non implica autorizzazione. Piuttosto, prima di concedere il permesso di compiere un’azione, il meccanismo di autorizzazione deve essere consultato per determinare se quell’azione è permessa.

4.4.1. Access Control Lists (Liste di controllo degli accessi)

Una forma comune di meccanismo di autorizzazione è una access control list (ACL, lista di controllo degli accessi), che elenca gli utenti a cui è permesso l’accesso a una risorsa. Poiché assegnare permessi di autorizzazione individuali a ciascuna risorsa è tedioso, le risorse sono spesso disposte gerarchicamente così che l’ACL della risorsa padre è ereditata dalle risorse figlie. Ciò consente agli amministratori di impostare politiche di alto livello e sovrascriverle quando necessario.

4.4.2. Certificate Based Systems (Sistemi basati su certificati)

Sebbene la distinzione tra autenticazione e autorizzazione sia intuitiva quando si usano meccanismi di autenticazione semplici come nome utente e password (cioè tutti capiscono la differenza tra l’account amministratore e un account utente), con meccanismi di autenticazione più complessi la distinzione talvolta si perde.

Con i certificati, ad esempio, presentare una firma valida non implica autorizzazione. La firma deve essere supportata da una catena di certificati che contiene una root attendibile, e quella root deve essere attendibile nel contesto dato. Ad esempio, gli utenti che possiedono certificati emessi dall’Acme MIS CA possono avere privilegi di accesso Web diversi dagli utenti che possiedono certificati emessi dall’Acme Accounting CA, anche se entrambe queste CA sono "attendibili" dal server Web Acme.

I meccanismi per far rispettare queste proprietà più complicate non sono ancora stati completamente esplorati. Un approccio è semplicemente allegare politiche alle ACL che descrivono quali tipi di certificati sono attendibili. Un altro approccio è portare quell’informazione con il certificato, sia come estensione/attributo del certificato [PKIX, SPKI] sia come separato "Attribute Certificate".

4.5. Providing Traffic Security (Fornire sicurezza del traffico)

I protocolli progettati in modo sicuro dovrebbero fornire qualche meccanismo per proteggere (cioè proteggere l’integrità, autenticare e possibilmente cifrare) tutto il traffico sensibile. Un approccio è proteggere il protocollo stesso, come in [DNSSEC], [S/MIME] o [S-HTTP]. Sebbene ciò fornisca la sicurezza più adatta al protocollo, richiede anche uno sforzo considerevole per farlo bene.

Molti protocolli possono essere adeguatamente protetti usando uno dei sistemi di sicurezza del canale disponibili. Discuteremo i due più comuni, IPsec [AH, ESP] e [TLS].

4.5.1. IPsec

I protocolli IPsec (in particolare AH ed ESP) possono fornire sicurezza di trasmissione per tutto il traffico tra due host. I protocolli IPsec supportano granularità variabili di identificazione dell’utente, inclusi ad esempio "IP Subnet", "IP Address", "Fully Qualified Domain Name" e utente individuale ("Mailbox name"). Questi livelli variabili di identificazione sono impiegati come input a strutture di controllo degli accessi che sono parte intrinseca di IPsec. Tuttavia, una data implementazione IPsec potrebbe non supportare tutti i tipi di identità. In particolare, i security gateway potrebbero non fornire autenticazione user-to-user o avere meccanismi per fornire quell’informazione di autenticazione alle applicazioni.

Quando AH o ESP è usato, il programmatore applicativo potrebbe non dover fare nulla (se AH o ESP è stato abilitato a livello di sistema) o potrebbe dover fare modifiche software specifiche (ad esempio aggiungendo specifiche chiamate setsockopt()), a seconda dell’implementazione AH o ESP usata. Purtroppo, le API per controllare le implementazioni IPsec non sono ancora standardizzate.

L’ostacolo principale all’uso di IPsec per proteggere altri protocolli è il dispiegamento. L’uso maggiore di IPsec al momento è per applicazioni VPN, in particolare per l’accesso remoto alla rete. Senza coordinamento estremamente stretto tra amministratori della sicurezza e sviluppatori applicativi, l’uso VPN non è ben adatto a fornire servizi di sicurezza per applicazioni individuali poiché è difficile per tali applicazioni determinare quali servizi di sicurezza sono stati in effetti forniti.

Il dispiegamento di IPsec in ambienti host-to-host è stato lento. A differenza dei sistemi di sicurezza applicativi come TLS, aggiungere IPsec a un sistema non-IPsec comporta in genere la modifica del sistema operativo, sia modificando il kernel sia installando nuovi driver. Questo è un impegno sostanzialmente maggiore che installare semplicemente una nuova applicazione. Tuttavia, versioni recenti di vari sistemi operativi commodity includono stack IPsec, quindi il dispiegamento sta diventando più facile.

In ambienti in cui IPsec è sicuro che sarà disponibile, rappresenta un’opzione praticabile per proteggere il traffico delle comunicazioni applicative. Se il traffico da proteggere è UDP, IPsec e la sicurezza specifica dell’oggetto applicativo sono le sole opzioni. Tuttavia, i progettisti NON DEVONO assumere che IPsec sarà disponibile. Una politica di sicurezza per un protocollo generico a livello applicativo NON DOVREBBE semplicemente stabilire che IPsec deve essere usato, a meno che non ci sia qualche motivo di credere che IPsec sarà disponibile nell’ambiente di dispiegamento previsto. In ambienti in cui IPsec potrebbe non essere disponibile e il traffico è esclusivamente TCP, TLS è il metodo di scelta, poiché lo sviluppatore applicativo può facilmente assicurarne la presenza includendo un’implementazione TLS nel proprio pacchetto.

Nel caso speciale di IPv6, sia AH che ESP sono obbligatori da implementare. Quindi, è ragionevole assumere che AH/ESP siano già disponibili per protocolli solo IPv6 o dispiegamenti solo IPv6. Tuttavia, la gestione automatica delle chiavi (IKE) non è richiesta da implementare, quindi i progettisti di protocolli NON DOVREBBERO assumere che sarà presente. [USEIPSEC] fornisce parecchia guida su quando IPsec è una buona scelta.

4.5.2. SSL/TLS

Attualmente, l’approccio più comune è usare SSL o il suo successore TLS. Forniscono sicurezza del canale per una connessione TCP a livello applicativo. Cioè, girano sopra TCP. Le implementazioni SSL tipicamente forniscono un’interfaccia simile a Berkeley Sockets per una programmazione facile. Il problema principale quando si progetta una soluzione di protocollo intorno a TLS è differenziare tra connessioni protette con TLS e quelle che non lo sono.

I due approcci primari usati sono avere una porta ben nota separata per connessioni TLS (ad esempio, la porta HTTP su TLS è 443) [HTTPTLS] o avere un meccanismo per negoziare verso l’alto dal protocollo base a TLS come in [UPGRADE] o [STARTTLS]. Quando è usata una strategia di negoziazione verso l’alto, bisogna fare attenzione a garantire che un attaccante non possa forzare una connessione in chiaro quando entrambe le parti desiderano usare TLS.

Si noti che TLS dipende da un protocollo affidabile come TCP o SCTP. Ciò produce due difficoltà notevoli. Primo, non può essere usato per proteggere protocolli datagram che usano UDP. Secondo, TLS è suscettibile ad attacchi a livello IP a cui IPsec non lo è. Tipicamente, questi attacchi assumono qualche forma di negazione del servizio o assassinio della connessione. Ad esempio, un attaccante potrebbe falsificare un TCP RST per chiudere connessioni SSL. TLS ha meccanismi per rilevare attacchi di troncamento ma questi consentono solo alla vittima di sapere di essere sotto attacco e non forniscono sopravvivenza della connessione di fronte a tali attacchi. Per contrasto, se IPsec fosse usato, un tale RST falsificato potrebbe essere rifiutato senza influire sulla connessione TCP. Se RST falsificati o altri tali attacchi sulla connessione TCP sono una preoccupazione, allora AH/ESP o l’opzione TCP MD5 [TCPMD5] sono le scelte preferite.

4.5.2.1. Virtual Hosts (Host virtuali)

Se è usato l’approccio "porte separate" per TLS, allora TLS sarà negoziato prima che sia inviato traffico a livello applicativo. Ciò può causare un problema con protocolli che usano host virtuali, come [HTTP], poiché il server non sa quale certificato offrire al client durante il handshake TLS. L’estensione hostname di TLS [TLSEXT] può essere usata per risolvere questo problema, sebbene sia troppo recente per aver visto ampio dispiegamento.

4.5.2.2. Remote Authentication and TLS (Autenticazione remota e TLS)

Una difficoltà con l’uso di TLS è che il server è autenticato tramite un certificato. Ciò può essere scomodo in ambienti in cui in precedenza l’unica forma di autenticazione era una password condivisa tra client e server. È allettante usare TLS senza un server autenticato (cioè con DH anonimo o un certificato RSA autofirmato) e poi autenticarsi tramite qualche meccanismo challenge-response come SASL con CRAM-MD5.

Purtroppo, questa composizione di SASL e TLS è meno forte di quanto ci si aspetterebbe. È facile per un attaccante attivo dirottare questa connessione. Il client fa man-in-the-middle sulla connessione SSL (ricordate che non stiamo autenticando il server, che è ciò che di solito previene questo attacco) e poi semplicemente fa da proxy all’handshake SASL. Da quel momento in poi, è come se la connessione fosse in chiaro, almeno per quanto riguarda quell’attaccante. Per prevenire questo attacco, il client deve verificare il certificato del server.

Tuttavia, se il server è autenticato, il challenge-response diventa meno desiderabile. Se avete già un canale rafforzato, le password semplici vanno bene. In effetti, sono discutibilmente superiori al challenge-response poiché non richiedono che la password sia memorizzata in chiaro sul server. Pertanto, la compromissione del file delle chiavi con sistemi challenge-response è più grave che se fossero usate password semplici.

Si noti che se il client ha un certificato, può essere usata l’autenticazione client basata su SSL. Per facilitare ciò, SASL fornisce il meccanismo EXTERNAL, mediante il quale il client SASL può dire al server "esamina il canale esterno per la mia identità". Ovviamente, questo non è soggetto agli attacchi di stratificazione descritti sopra.

In alcuni casi speciali può valere la pena fornire sicurezza a livello di canale direttamente nell’applicazione piuttosto che usare IPSEC o SSL/TLS. Un tale caso è la sicurezza del terminale remoto. I caratteri sono tipicamente consegnati dal client al server un carattere alla volta. Poiché SSL/TLS e AH/ESP autenticano e cifrano ogni pacchetto, ciò può significare un’espansione dei dati di 20 volte. L’opzione di cifratura telnet [ENCOPT] previene questa espansione rinunciando all’integrità del messaggio.

Quando si usa il servizio di terminale remoto, spesso è desiderabile eseguire in modo sicuro altri tipi di servizi di comunicazione. Oltre a fornire login remoto, SSH [SSH] fornisce anche port forwarding sicuro per porte TCP arbitrarie, consentendo così agli utenti di eseguire applicazioni TCP arbitrarie sul canale SSH. Si noti che il port forwarding SSH può essere un problema di sicurezza se è usato impropriamente per aggirare firewall ed esporre impropriamente applicazioni interne insicure al mondo esterno.

4.6. Denial of Service Attacks and Countermeasures (Attacchi di negazione del servizio e contromisure)

Gli attacchi di negazione del servizio sono troppo spesso visti come un dato di fatto. Un problema è che un attaccante può spesso scegliere tra molti attacchi di negazione del servizio da infliggere a una vittima, e poiché la maggior parte di questi attacchi non può essere sventata, il senso comune assume frequentemente che non abbia senso proteggersi da un tipo di attacco di negazione del servizio quando ce ne sono molti altri possibili che non possono essere prevenuti.

Tuttavia, non tutti gli attacchi di negazione del servizio sono uguali e, cosa più importante, è possibile progettare protocolli in modo che gli attacchi di negazione del servizio siano resi più difficili, se non impraticabili. Recenti attacchi SYN flood [TCPSYN] dimostrano entrambe queste proprietà: gli attacchi SYN flood sono così facili, anonimi ed efficaci che sono più attraenti per gli attaccanti di altri attacchi; e perché la progettazione di TCP abilita questo attacco.

Poiché la protezione completa contro DoS è così difficile, la sicurezza contro DoS deve essere affrontata pragmaticamente. In particolare, alcuni attacchi contro cui sarebbe desiderabile difendersi non possono essere difesi in modo economico. L’obiettivo dovrebbe essere gestire il rischio difendendosi da attacchi con rapporti sufficientemente alti tra gravità e costo della difesa. Sia la gravità dell’attacco sia il costo della difesa cambiano con la tecnologia e quindi cambia anche l’insieme di attacchi contro cui ci si dovrebbe difendere.

Gli autori di standard Internet DEVONO descrivere a quali attacchi di negazione del servizio il loro protocollo è suscettibile. Questa descrizione DEVE includere le ragioni per cui era irragionevole o fuori ambito tentare di evitare questi attacchi di negazione del servizio.

Gli attacchi di negazione del servizio CIECA (BLIND) sono particolarmente insidiosi. Con un attacco cieco l’attaccante ha un vantaggio significativo. Se l’attaccante deve essere in grado di ricevere traffico dalla vittima, allora deve o sovertire il tessuto di instradamento o usare il proprio indirizzo IP. Entrambi forniscono alla vittima l’opportunità di tracciare l’attaccante e/o filtrarne il traffico. Con un attacco cieco l’attaccante può usare indirizzi IP falsificati, rendendo estremamente difficile per la vittima filtrare i suoi pacchetti. L’attacco TCP SYN flood è un esempio di attacco cieco. I progettisti dovrebbero fare ogni tentativo possibile per prevenire attacchi ciechi di negazione del servizio.

4.6.2. Distributed Denial of Service (Negazione del servizio distribuita)

Ancora più pericolosi sono gli attacchi di negazione del servizio DISTRIBUITI (DDoS) [DDOS]. In un DDoS l’attaccante organizza che un numero di macchine attacchi simultaneamente la macchina bersaglio. Di solito ciò è realizzato infettando un gran numero di macchine con un programma che consente l’avvio remoto degli attacchi. Le macchine che effettivamente eseguono l’attacco sono chiamate ZOMBIE e probabilmente sono di proprietà di terze parti ignare in una posizione completamente diversa dal vero attaccante. Gli attacchi DDoS possono essere molto difficili da contrastare perché gli zombie spesso sembrano fare richieste di protocollo legittime e semplicemente soffocano gli utenti reali. Gli attacchi DDoS possono essere difficili da sventare, ma ci si attende che i progettisti di protocolli siano consapevoli di queste forme di attacco mentre progettano i protocolli.

4.6.3. Avoiding Denial of Service (Evitare la negazione del servizio)

Vi sono due approcci comuni per rendere gli attacchi di negazione del servizio più difficili:

4.6.3.1. Make your attacker do more work than you do (Far sì che l’attaccante faccia più lavoro di voi)

Se un attaccante consuma più delle sue risorse delle vostre quando lancia un attacco, gli attaccanti con meno risorse di voi non saranno in grado di lanciare attacchi efficaci. Una tecnica comune è richiedere all’attaccante di eseguire un’operazione intensiva nel tempo, come un’operazione crittografica. Si noti che un attaccante può ancora montare un attacco di negazione del servizio se può radunare potenza CPU sostanzialmente sufficiente. Ad esempio, questa tecnica non fermerebbe gli attacchi distribuiti descritti in [TCPSYN].

4.6.3.2. Make your attacker prove they can receive data from you (Far provare all’attaccante che può ricevere dati da voi)

Un attacco cieco può essere subvertito forzando l’attaccante a provare che può ricevere dati dalla vittima. Una tecnica comune è richiedere che l’attaccante risponda usando informazioni ottenute prima nello scambio di messaggi. Se questa contromisura è usata, l’attaccante deve o usare il proprio indirizzo (rendendolo facile da tracciare) o falsificare un indirizzo che sarà instradato indietro lungo un percorso che attraversa l’host da cui l’attacco è lanciato.

Gli host su sottoreti piccole sono quindi inutili all’attaccante (almeno nel contesto di un attacco di spoofing) perché l’attacco può essere ricondotto a una sottorete (che dovrebbe essere sufficiente per localizzare l’attaccante) così che misure anti-attacco possano essere messe in atto (ad esempio, un router di confine può essere configurato per scartare tutto il traffico da quella sottorete). Una tecnica comune è richiedere che l’attaccante risponda usando informazioni ottenute prima nello scambio di messaggi.

4.6.4. Example: TCP SYN Floods (Esempio: flood SYN TCP)

TCP/IP è vulnerabile agli attacchi SYN flood (descritti nella sezione 3.3.2) a causa della progettazione dell’handshake a tre vie. Primo, un attaccante può forzare una vittima a consumare risorse significative (in questo caso, memoria) inviando un singolo pacchetto. Secondo, poiché l’attaccante può compiere questa azione senza aver mai ricevuto dati dalla vittima, l’attacco può essere eseguito in modo anonimo (e quindi usando un gran numero di indirizzi sorgente falsificati).

4.6.5. Example: Photuris (Esempio: Photuris)

[PHOTURIS] specifica un meccanismo anti-clogging che previene attacchi a Photuris che assomigliano all’attacco SYN flood. Photuris impiega un segreto variante nel tempo per generare un "cookie" che è restituito all’attaccante. Questo cookie deve essere restituito in messaggi successivi perché lo scambio progredisca. La caratteristica interessante è che questo cookie può essere rigenerato dalla vittima più tardi nello scambio, e quindi non è necessario mantenere stato dalla vittima finché l’attaccante non ha provato che può ricevere pacchetti dalla vittima.

4.7. Object vs. Channel Security (Sicurezza dell’oggetto rispetto al canale)

È utile fare la distinzione concettuale tra sicurezza dell’oggetto e sicurezza del canale. La sicurezza dell’oggetto si riferisce a misure di sicurezza che si applicano a interi oggetti dati. Le misure di sicurezza del canale forniscono un canale sicuro sul quale gli oggetti possono essere trasportati in modo trasparente ma il canale non ha conoscenza speciale dei confini dell’oggetto.

Considerate il caso di un messaggio di posta elettronica. Quando è trasportato su una connessione protetta IPSEC o TLS, il messaggio è protetto durante la trasmissione. Tuttavia, non è protetto nella casella del destinatario e nei file di spool intermedi lungo il percorso. Inoltre, poiché i server di posta girano in genere come demone, non come utente, l’autenticazione dei messaggi in genere significa meramente autenticazione del demone, non dell’utente. Infine, poiché il trasporto della posta è hop-by-hop, anche se l’utente si autentica al primo relay hop l’autenticazione non può essere verificata in modo sicuro dal ricevitore.

Per contrasto, quando un messaggio di posta è protetto con S/MIME o OpenPGP, l’intero messaggio è cifrato e protetto in integrità finché non è esaminato e decifrato dal destinatario. Fornisce anche forte autenticazione del mittente effettivo, in opposizione alla macchina da cui proviene il messaggio. Questa è sicurezza dell’oggetto. Inoltre, il ricevitore può dimostrare l’autenticità del messaggio firmato a una terza parte.

Si noti che la differenza tra sicurezza dell’oggetto e del canale è una questione di prospettiva. La sicurezza dell’oggetto a un livello dello stack di protocollo spesso assomiglia alla sicurezza del canale al livello successivo. Quindi, dalla prospettiva del livello IP, ogni pacchetto assomiglia a un oggetto protetto individualmente. Ma dalla prospettiva di un client Web, IPSEC fornisce solo un canale sicuro.

La distinzione non è sempre netta. Ad esempio, S-HTTP fornisce sicurezza a livello di oggetto per una singola transazione HTTP, ma una pagina Web tipicamente consiste in multiple transazioni HTTP (la pagina base e numerose immagini inline). Quindi, dalla prospettiva della pagina Web totale, ciò assomiglia piuttosto di più alla sicurezza del canale. La sicurezza dell’oggetto per una pagina Web consisterebbe nella sicurezza per la chiusura transitiva della pagina e tutto il suo contenuto incorporato come unità singola.

4.8. Firewalls and Network Topology (Firewall e topologia di rete)

È pratica di sicurezza comune nelle reti moderne partizionare la rete in reti esterne e interne usando un firewall. La rete interna è poi assunta sicura e solo misure di sicurezza limitate sono usate lì. La porzione interna di tale rete è spesso chiamata WALLED GARDEN (rete recintata).

I progettisti di protocolli Internet non possono assumere in sicurezza che i loro protocolli saranno dispiegati in tale ambiente, per tre ragioni. Primo, protocolli originariamente progettati per essere dispiegati in ambienti chiusi sono spesso successivamente dispiegati su Internet, creando così vulnerabilità gravi.

Secondo, reti che sembrano topologicamente disconnesse potrebbero non esserlo. Una ragione può essere che la rete è stata riconfigurata per consentire accesso dal mondo esterno. Inoltre, i firewall stanno sempre più facendo passare protocolli generici a livello applicativo come [SOAP] o [HTTP]. I protocolli di rete basati su questi protocolli generici non possono in generale assumere che un firewall li proteggerà. Infine, una delle minacce di sicurezza più gravi ai sistemi proviene dagli insider, non dagli outsider. Poiché gli insider per definizione hanno accesso alla rete interna, protezioni topologiche come i firewall non li proteggeranno.