La sicurezza nel protocollo TCP

Il protocollo TCP, nonostante la sua affidabilità, ovviamente presenta anche delle vulnerabilità. Non dimentichiamo infatti che il suo scopo originario lo vedeva progettato come strumento da utilizzare nell’ambito di reti locali chiuse e private: di conseguenza non si pose il problema di implementare funzionalità orientate alla sicurezza come cifratura e autenticazione, che invece si decise di delegare ai livelli superiori.

Dato il suo enorme sviluppo si decise tuttavia di realizzare diverse soluzioni per ovviare a questa mancanza e risolvere i principali problemi di sicurezza del protocollo.

Di seguito illustriamo le principali vulnerabilità del protocollo e i sistemi per porvi rimedio.

Denial of Service

Si tratta di uno dei sistemi di attacco più pericolosi e più facili da mettere in pratica, di conseguenza è anche uno dei più diffusi. Un attacco DoS ha come scopo quello di mandare in crash un server semplicemente occupando tutte le risorse a sua disposizione. Questo obiettivo si può raggiungere con diverse tecniche, più o meno facili da implementare.

Una di queste tecniche sfrutta la principale caratteristica della creazione di una connessione nel modello TCP, ovvero il meccanismo del Three Way Handshake. Come abbiamo visto per aprire la connessione il mittente invia un pacchetto Syn al destinatario e resta in attesa del Syn-Ack. Questo metodo consiste quindi nell’inviare un messaggio con flag Syn impostato a 1, ovvero si invia richiesta di attivazione di una connessione. Se il client mittente, in questo caso attaccante, dopo aver ricevuto il Syn-Ack dal destinatario (ovvero l’host attaccato) non invia il relativo Ack, il server destinatario resterà in attesa.

Questo attacco consiste quindi nell’invio massimo di richieste di attivazione della connessione, alla quale non fanno seguito gli invii di ack, con la conseguenza che un singol host attaccante può bloccare numerose risorse del server attaccato, che in attesa dell’ack terrà nei suoi buffer di memoria le informazioni sulle richieste di connessioni fittizie, togliendo risorse a quelle reali.

Una delle soluzioni adottate per mitigare questa tipologia di attacco è l’utilizzo di un timer al termine del quale, senza aver ricevuto l’ack, il server destinatario cancellerà la connessione.

Connection hijacking

Questo attacco consiste nel reindirizzamento di pacchetti di una connessione attiva tramite modifica del numero di sequenza. Come abbiamo visto la trasmissione prevede nell’header la presenza di un numero che permette al destinatario di ricostruire l’esatta sequenziazione dei pacchetti ricevuti e la relativa ricostruzione corretta del messaggi. È quindi possibile mettere in piedi un attacco intercettando i pacchetti di una connessione e inviare al destinatario un falso pacchetto, con numero di sequenza atteso. Quando il destinatario riceve il falso pacchetto, vedendo il corretto numero di sequenza, lo accetta, ma riscontrando una lunghezza diversa da quella prevista perde la sincronizzazione con l’host sorgente terminando la connessione.

TCP Veto

Questo attacco è una pericolosa evoluzione del precedente, e presuppone che l’attaccante conosca la dimensione del pacchetto trasmesso, oltre al numero di sequenza. Se tale condizione si verifica, allora il server attaccato accetterà il pacchetto falso senza interrompere la connessione, ed in tale pacchetto l’attaccante potrà inserire i dati che vuole. Una volta che anche il pacchetto legittimo arriva a destinatario, questo verrà scartato, in quanto ne è già stato ricevuto uno che è stato scambiato con quello legittimamente atteso: quindi il pacchetto legittimo riceve il veto da quello dannoso!

In questo caso, a differenza del precedente, la connessione non viene interrotta, ma continua normalmente. Tuttavia, l’attacco TCP Veto conferisce pur sempre all’attaccante un controllo sulla comunicazione, e soprattutto diventa abbastanza complicato da individuare.

TCP Reset

Abbiamo visto che nell’header dei pacchetti TCP è presente un flag chiamato RST che settato a 1 identifica la connessione come non valida e ne provoca la terminazione con errore.

Questo tipo di attacco viene quindi condotto intercettando la comunicazione tra due host e inviando ad entrambi un pacchetto con flag RST impostato a 1, in modo da terminare la connessione senza lasciare tracce.