[PLUTO-security] ftp e iptables

[Fabio Panigatti]

> A proprosito di filtrare con "string" (penso ti riferissi al modulo per
> iptables), hai qualche info in merito a i vantaggi e o svantaggi ?
>
> Mi spiego meglio: il modulo in questione offre (in logica) un ottimo sistema
> per eseguire il filtraggio dal traffico; rimane pero' sempre il problema che
> le sessioni ti rimangono aperte fino a regolare timeout, e non è un bene.

Quando non si riesce a fare altrimenti :-) (IMHO) Uno dei due lati deve
sempre andare in timeout [1], ma a volte potrebbe valerne la pena se il
rimedio non e' peggiore del male che si cura. In ogni caso, il problema
affligge solo il protocollo tcp: con icmp o udp si pone in misura molto
minore.

Il limite maggiore che vedo nell'uso di string e' nella possibilita' di
falsi positivi, dovuta alla poverta' delle regole di matching (semplice
confronto tra stringhe in un punto qualsiasi del payload).

> A questo punto mi chiedo, quali sono i casi in cui si puo' riccorrere al suo
> funzionamento senza mettersi nella codizione di esporsi a problemi _troppo_
> rilevanti ?

> Se dovessi rispondere adesso direi: tutti e nessuno !

Anch'io :-) Se hai una macchina IIS non patchata che non puoi fermare e
non hai a disposizione nient'altro, e' sicuramente meglio far andare in
timeout un po' di socket finche' la situazione non cambia, per esempio,
ed intanto bloccare tutti gli accessi a default.ida.
Di solito, pero', penso che ci sia quasi sempre una soluzione migliore,
vedi anche quella snort flexresp. Se si parla di udp o icmp diventa una
cosa molto piu' fattibile: vuoi impedire le query per un certo dominio?
Con string rigetti con un port unreachable i pacchetti che contengono i
riferimenti al dominio, et voila'. Vuoi impedire a welchia di vedere la
tua rete come up? Droppi tutto il traffico icmp echo request contenente
una serie di 0xAA, e via. E chi se ne frega se welchia va in timeout :-)
Altri esempi a fantasia.


Fabio

[1] a meno che non si attuino soluzioni come quella che ho descritto nel
    post precedente (snort) [2]
[2] ... o che non venga creato un helper per netfilter che resetti tutti
    e due i lati della connessione e non soltanto uno, qualcosa del tipo
    --reject-with full-tcp-reset :-)