[Soci SLIP] L'ora del rant (client FTP)

Lucio Crusca lucio a sulweb.org
Sab 7 Lug 2007 23:53:04 CEST


Ok, è software libero.
Ok, è sempre meglio di Windows.
Ok, devo ringraziare che c'è.
Ok, forse potrei fare di meglio che lamentarmi.

Però:

sto cercando di fare una copia locale, via FTP, del sito del Veloce per poi 
trasferirlo su hosting Linux, sempre su Aruba. 

Client ftp da linea di comando: non ne vuole sapere.
Kasablanca: scarica qualcosa, incontra un errore, interrompe il download e non 
permette di riprenderlo da dove l'ha interrotto.
gFTP: come sopra
ftpcopy: sembrerebbe funzionare (ovvero riprende il download dopo che incontra 
errori) ma ogni tre per due si ferma con: "illegal redirect by FTP server" 
indipendentemente da quanti "--allow-pasv-ip" gli specifico (ulteriore rant 
in nota 1 sotto)
KFTPGrabber: sembra resistere più degli altri, ma verso il 38% si pianta pure 
lui.

Ora io immagino che il problema debba essere un denominatore comune, ovvero il 
server FTP di Aruba, ma mi domando e dico: se anche il problema fosse quello, 
per quanto un server possa comportarsi male, possibile che non esista un 
client che semplicemente ritenti l'operazione invece di piantarsi a prova di 
SIGTERM?

Proprio in questo istante, mentre scrivevo la frase qui sopra, KFTPGrabber si 
è risvegliato da circa mezz'ora di freeze ed ha ripreso il download, il che, 
per carità, gioca a suo favore, ma non si può certo definire un comportamento 
amichevole e forse nemmeno corretto per un'interfaccia grafica (in tutto quel 
tempo non hai mai ridisegnato la finestra, quindi sembrava proprio 
irrimediabilmente bloccato).

Nota 1 (rant su ftpcopy): la pagina di manuale giustifica l'errore riportato 
da ftpcopy dicendo, sostanzialmente, che se si permettesse al server 
qualsiasi redirect si rischierebbe di permettere al server di sferrare un 
attacco DoS verso computers innocenti in giro per internet (credo usando il 
nostro client). Non riesco a cogliere esattamente il modo in cui il server 
potrebbe farlo, ma faccio atto di fede ed assumo che sia vero. Nonostante ciò 
mi chiedo: ma se è vero, sarà poi un pericolo così concreto? Oppure un server 
FTP malizioso che induce i suoi client a sferrare attacchi DoS è troppo in 
vista per passare inosservato? 
Immaginate la situazione: io, cracker brutto e cattivo, metto su un server FTP 
malizioso che sfrutta la suddetta vulnerabilità del protocollo FTP per 
rompere le scatole a novell.com (ne ho ovviamente preso uno a caso, avrei 
ovviamente potuto dire anche, che so... sco.com).
Poi metto sul server FTP un tot di files interessanti, in modo che molti 
client vengano a prenderli, e quando ho centomila utenti connessi faccio in 
modo che il server mandi contemporaneamente a tutti un redirect verso 
novell.com. Conseguenza? Un bel DDoS a novell.com (assumendo che io abbia 
capito in che modo funziona l'attacco a cui la pagina di man fa riferimento).
Wow!
Pericoloso!
Ma allora, per quale motivo ftpcopy è l'unico client FTP sulla faccia della 
terra a preoccuparsene al punto da rifiutarsi di funzionare ad ogni 
server "malizioso falso positivo" che trova?
Io penso per due motivi (e mi chiedo perché non lo pensi anche Uwe Ohse, 
autore di ftpclient):
1. Perché il tutto funzioni, il server FTP malizioso deve poter gestire più 
connessioni di quante non ne possa gestire novell.com
2. Nell'ipotesi che un attacco così si verifichi, tutti i client riceverebbero 
errore dall'indirizzo di novell.com mentre stanno usando il server FTP 
malizioso che con novell non ha nulla a che vedere. Ok, l'errore riporterebbe 
solo un indirizzo IP di novell, non il nome di dominio, ma su centomila vuoi 
che non ci sia un utente curioso che cerca di capire cosa è capitato? A quel 
punto il mio server malizioso è smascherato.

Nel frattempo KFTPGrabber ha finito di scaricare... Linux 1 Aruba 0. Ma mi 
sarebbe piaciuto non dover fare tutta 'sta fatica.

# killall rantd

Lucio.

-- 
Virtual Bit di Lucio Crusca
via Isonzo, 5
10069 - Villar Perosa (TO)
http://virtualbit.sulweb.org




Maggiori informazioni sulla lista Soci