Benefici, limiti e contesti d'applicazione del portknocking
Come ben noto la sicurezza “totale” non esiste, e l'unica certezza assoluta di evitare un attacco remoto ad un server è quella di disconnetterlo fisicamente dalla rete, cosa peraltro decisamente poco pratica. La tecnica del portknocking non pretende certo di raggiungere una protezione simile a questo caso limite, ma puo' comunque garantire diversi benefici :
1. Chiudendo tutte le porte usando l'azione DROP anziche' REJECT, la presenza del server non puo' venire rintracciata con normali attivita' di portscanning. Di conseguenza si possono evitare molti problemi legati all'attivita' dei cosiddetti script-kiddies. Questa figura, ad esempio, e' solita ricorrere all'uso di portscanner su ampi intervalli di indirizzi IP, alla ricerca di host che abbiano attivi particolari servizi applicativi, sui quali potere provare software scritti da terze persone, in grado di sfruttarne delle vulnerabilita' note..
2. Viene ad aggiungersi un ulteriore layer di sicurezza ai sistemi, senza rimpiazzare o richiedere modifiche ai metodi preesistenti. In questo modo e' quindi possibile sfruttare anche le politiche di sicurezza specifiche delle applicazioni protette, aggiungendosi ad esse. E' sufficiente immaginare la tecnica portknocking applicata ad un server con accesso SSH basato su password. Nell'ipotesi che il sistema di portknocking venga infranto, resterebbero ancora da superare i meccanismi di sicurezza specifici del servizio SSH.
Inoltre, il violare un sistema di portknocking, non fornisce alcuna informazione utile nell'exploitare il servizio protetto.
3. Impossibilita' per un attacker di determinare se un server stia ascoltando in attesa di una sequenza di knock semplicemente agendo per tentativi oppure attraverso attivita' di portscannig.
Maggiori informazioni si potrebbero raccogliere monitorando il traffico di rete, ma tutto cio che si noterebbe in questo sarebbero solo delle serie di tentativi di connessione, poiche' nelle sequenze di knock l'informazione fluisce in questa forma e non nel payload del pacchetto.
Il sistema, inoltre, puo' essere reso piu' robusto in modo da rendere difficile per un attacker riconoscere tali sequenze e riutilizzarle. Esistono infatti, alcune misure ed accorgimenti che possono di permettere di raggiungere questo scopo. Esse verranno discusse analizzando gli attuali sistemi di portknocking e l'implementazione del prototipo servknock.
4. Relativa semplicita' nel riconoscere un eventuale attacco di tipo brute-force, che stia cercando di individuare qualche sequenza di knock, specialmente se il portknocking server e' integrato con un intrusion detection system.
D'altro canto l'utilizzo di questa soluzione presenta anche alcuni svantaggi :
1. Necessita' di utilizzare un programma specifico che generi la sequenza di knock, poiche' nei normali client che si utilizzano per accedere ai servizi non e' prevista questa possibilita' . L'utilizzo di client aggiuntivi pero', potrebbe non essere concesso in alcuni ambienti come internet cafe', biblioteche ecc.
2. Necessita' di riservare l'utilizzo di uno piu' intervalli di porte per la tecnica del portknocking. Se per esempio si avesse la necessita' di mantenere il servizio http fosse liberamente accessibile, non sarebbe possibile utilizzare la porta 80 anche per il portknocking.
Tale problema puo' essere parzialmente risolto, almeno per quanto riguarda le connessioni TCP, sfruttando anche i valori dei flags TCP all'interno dei pacchetti della sequenza.
3. Manipolando dinamicamente le regole di filtraggio del firewall e' necessario prestare la massima attenzione nell'implementazione del sistema. Basti pensare alla situazione in cui il processo del portknocking server dovesse morire inaspettatamente o non funzionare correttamente : non sarebbe piu' possibile interpretare le sequenze di knock e come diretta conseguenza diventerebbe impossibile connettersi all'host protetto.
4. Come molti altri meccanismi di protezione potrebbe indurre un falso senso di sicurezza, portando ad aggiornamenti e patch meno frequenti. Sebbene il portknocking possa migliorare la sicurezza di un sistema, e' comunque necessario partecipare attivamente nel monitoraggio e nel mantenimento delle politiche di base che soddisfino requisiti richiesti.
Non si tratta comunque di uno svantaggio intrinseco di questa tecnica.
5. Suscettibilita' ad attacchi di tipo Denial of Service. Come per i normali servizi applicativi, infatti esiste sempre un carico limite, indipendentemente dall'hardware a disposizione. Un'applicazione o lo stack TCP/IP potranno comunque essere sovraccaricati indipendentemente dal fatto che si stia usando o meno il portknocking.
Un portknocking server funziona tenendo una lista dei tentativi di connessione alle porte associati agli indirizzi IP dei richiedenti. Per ogni client che invia una sequenza di knock, viene aggiunto/aggiornato il suo attempt all'interno della coda e si controlla se esso corrisponda con una sequenza ritenuta valida. Se ad esempio dovessero arrivare un numero eccessivo di pacchetti, il server potrebbe diventare talmente sovraccaricato da non essere piu' in grado catturare ed interpretare l'altro traffico in arrivo.
6. Possibile vulnerabilita' ai replay attacks. In caso di mancato utilizzo di misure atte a prevenire questo problema, per un attacker sarebbe infatti sufficiente “sniffare” il traffico di rete diretto al portknocking server, per determinare la sequenze di knock e poterle quindi riprodurre. Possibili soluzioni al problema verranno discussi nelle sezioni successive.
Diversi detrattori, inoltre, sostengono che la tecnica del portknocking non si altro che una forma di security through obscurity. Un'affermazione del genere e' quantomeno opinabile, e per capirne il motivo e' bene riflettere su cosa si intenda esatta,ente per security through obscurity.
Il concetto viene descritto molto chiaramente da Jay Beale membro del Bastille Linux Project, che definisce questa forma di sicurezza come : “security implemented solely through obscurity”, ovvero quella situazione nella quale l'intera protezione risiede esclusivamente nella speranza che l'attacker non conosca i dettagli della configurazione del sistema protetto sia esso una rete, od un solo computer.
Un 'esempio di tale forma di protezione (o presunta tale) e' quello di un amministratore di sistema che tenga dati sensibili della societa', che non dovrebbero essere pubblici, su un webserver della rete interna dell'azienda, senza alcuna password posta a protezione delle pagine. Anziche' puntare su di un metodo accettabile per il controllo degli accessi la protezione viene basata sull'assunzione che nessuno sia a conoscenza del webserver ad eccezione dei dipendenti che debbano accedervi. Assunzione peraltro sbagliata, poiche' basterebbe ricorrere a tool come nmap , cheops o firewalk per scoprirne l'esistenza.
Alcuni attacker non spenderanno il proprio tempo alla ricerca del webserver, ma probabilmente altri potrebbero farlo, arrivando infine alle informazioni che dovevano invece essere riservate.
Il problema in questo caso e' stato il fatto di contare esclusivamente sulla “segretezza” della locazione dei dati, senza utilizzare forme per il controllo, logging o altri meccanismi di difesa, quando invece una caratteristica fondamentale per buona politica di protezione e' una fine granularita' nel controllo degli accessi e la possibilita' di riconoscere gli accessi indebiti.
Alla luce di queste considerazioni, non e' dunque possibile definire la tecnica del portknocking come un semplice caso di security through obscurity, poiche' essa e' una forma di sicurezza che si viene aggiungere agli altri meccanismi di difesa senza volerli assolutamente sostituire.
La tecnica del portknocking, quindi, e' una forma di hardening indicata dove si abbiano utenti che richiedano un accesso continuo a dei servizi che non debbano essere pubblici come invece sono http o SMTP, mantenendo le porte di rete chiuse al traffico pubblico, ed aprendole o chiudendole in maniera flessibile ai richiedenti che si siano autenticati con una sequenza di knock corretta.
Un sistema simile offre tutti vantaggi del filtraggio dei pacchetti basato sugli indirizzi IP, senza pero' incorrere nelle limitazioni di cui si e' gia' discusso nel primo capitolo.
Come si potra' intuire il portknocking non e' una soluzione indicata per proteggere servizi pubblici. Una simile protezione, infatti , sarebbe decisamente poco efficace se le sequenze di knock oppure il metodo utilizzato per generarle fossero resi di pubblico dominio.
Un altro ambito di utilizzo potrebbe essere l'ambiente “warez”, ad esempio per cercare di nascondere un server ftp al proprio Internet Service Provider. Esso infatti non potrebbe essere scoperto per mezzo di un semplice portscan, ma richiederebbe di controllare il traffico generato a partire dall'indirizzo IP dell'abbonato, oppure le porte sulle quali egli ha ricevuto delle connessioni.
Questa tecnica potrebbe inoltre venire sfruttata anche dagli sviluppatori dei cosiddetti malware, per creare delle “dormant backdoor” sui sistemi vittima. Avere una porta sempre aperta e pronta ad accettare connessioni remote, sarebbe estremamente semplice da rilevare da parte di un amministratore di sistema. Analizzando il traffico di rete, invece, sarebbe possibile avviare ed uccidere la backdoor vera e propria, solo una volta che siano state riconosciute la sequenze di knock opportune. Il portknocking permette infatti di associare comandi shell arbitrari alle diverse sequenze di knock, e quindi non deve essere pensato solo ed esclusivamente come un sistema di manipolazione delle regole di filtraggio, sebbene questo sia il suo principale ambito di utilizzo.