Re: SSHd

[Giovanni Laieta <giolay@tin.it>]

Ciao Raffaele
On Wed, Sep 08, 2004 at 05:10:43PM +0200, Raffaele D'Elia wrote:
> E io che pensavo fosse una mia idea...
> Ogni volta che mi viene un'idea trovo sempre qualcuno che l'ha 
> realizzata prima di me!!!
> 
> Secondo me l'idea è valida. Per l'implementazione poi c'è solo 
> l'imbarazzo della scelta...
> 
secondo me l'idea di base si ma richiede molta riflessione, spiego dopo
il perche' di questa affermazione.

> Oppure si può usare un protocollo proprietario (leggi "segreto") con il 
> quale chiedi l'apertura di una/più determinate porte da/verso un 
> determinato IP.
la sicurezza non si implementa tramite security through obscurity.
(punto zero)

> Basta saper scrivere un buon parser e controllare ogni testo che viene 
> dall'esterno (giusto per evitare di inserire un buffer overflow).
> 
se fosse cosi' facile come dici dormirei piu' tranquillo la notte :)

> Io ero più propenso per una cosa di questo tipo, che è più flessibile 
> che mai.
> 
> Certo se qualcuno ti sta sniffando non c'è riparo; però devi quantomeno 
> essere in una posizione privilegiata. E al max puoi ottenere l'apertura 
> di una porta dove devi comunque autenticarti.
> 
bhe... esistono anche i sistemi di cifratura via chiave pubblica
privata, algoritmi di hashing su cui applicare la firma digitale... 
tutte cose create ad hoc per le situazioni di transizione evidentemente 
"non fidate".

> Che ne pensate

La sicurezza intesa come invulnerabilita' al 100% non esiste e questo e' un dato
di fatto, aumemtare la sicurezza puo' essere visto come aggiungere tanti
piccoli scalini per rendere l'arrampicata piu' difficile ad un possibile
attacker.

Usare knockd o cryptoknock non e' aggiungere un livello di sicurezza in
piu' anzi e' togliero, ti spiego il mio personale punto di vista:
se scrivi un demone che usa le libpcap esso *deve* girare come root
quindi aggiungi linee di codice con privilegi alti ad un codice che deve
implementare una sorta di wrapper ad un codice che gia' gira con privilegi 
alti, esempio ssh, questo e' un aggiungere probabilita' di vulnerabilita' 
alla probabilita' precedente.
(la spiegazione probbabilmente fa schifo ma capibile)

Se poi fai un analisi nel dettaglio di un demone di portknocking esso
non e' altro che aggiungere una passphrase che viaggia sulla rete in
chiaro. Questo e' vero anche per cryptoknock anche se "dice" di essere
cifrato in quanto basterebbe ad un attacker intercettare l'ultimo
pacchetto del DH key agreement e reindirizzarlo al server cambiando nel
header udp il source address e il server apre la porta
all'attacker. Questo avviene perche' non viene inserito all'interno del
pacchetto cifrato l'ip del sender, il server dovrebbe controllare che
siano combacianti l'ip sorgente e quello cifrato all'interno dell'ultimo
pacchetto ricevuto... va bhe, insomma, dal mio punto di vista e' come se
fosse in chiaro...

Se poi analizziamo la prima implementazione di portknocking, che e' stata
scritta in bash, essa analizza i log di iptables. Risultato: hai la
password scritta in chiaro nei log oltre ad avere le problematiche
espresse in precedenza. E' vero pero' che il bash scripting non e'
vulnerabile ai buffer overflow. Questa mi pare la soluzione attualmente
migliore e piu' personalizzabile visto com'e' implementata. Ma comunque
rimane il problema che intercettare la sequenza di knock e' facile e
ancora piu' facilmente riproducibile.

Secondo me c'e' una via percorribile che sto (fose stiamo?!?!?) 
implementando. Anche questa, come tutto, sara' raggirabile
sicuramente... spero quantomeno che sia un passettino avanti rispetto
l'attuale situazione.
La presentazione dopo linuxday 2004 se no tolgo la suspance della 
talk :)

ciao
giovanni

-- 
Giovanni Laieta (LAIn_)
Cell: 339 88 85 781
E-Mail: giovanni.laieta@milug.org
GPG key fingerprint: F972 DFEB 1EE6 C81C 09BF  6E59 EE3F 1CFA 2475 0553