/fox/ wrote:
| forse non va bene per i cinesi ma se abbiamo un filtro/firewall
aziendale si
analizziamo cos'e' successo negli anni:
preistoria: i filtri esistevano lato server, i client facevano quello
che volevano. i client avevano ip pubblico, i filtri d'accesso venivano
messi a livello di /etc/hosts.(allow|deny)
storia: i filtri iniziano ad esistere lato client. i client hanno ancora
ip pubblico, ma a livello aziendale ci sono i primi filtri del tipo "le
porte sotto la 1024 non sono contattabili" "gli ICMP non passano" "la
porta 6667 non esce" "solo la porta 25/80 e' contattabile direttamente".
storia moderna: i client sono nattati, escono su tutti i protocolli, si
iniziano a vedere i primi filtri un po' piu' selettivi. "la porta 6667
non esce, la 4662, i server di napster, il pattern di skype". in
ambienti un po' piu' grossi: "i client non escono. il proxy esce. i
client si devono autenticare sul proxy, cosi' possiamo loggare
utente:pagina_richiesta".
ora: i client sono nattati, c'e' content filter, passa quello che e'
permesso e non quello che non "e' previsto".
questo e' un generalismo, ambienti di piccole/medie/grosse dimensioni
hanno tecnologie e politiche differenti anche in relazione alla distanza
fisica-umana che c'e' tra chi gestisce l'IT dagli utenti.
comunque, qual'e' il senso di questo riassunto ?
prima si filtrava a livello ip,
poi a livello tcp (e gli utenti usavano posta/chat via web)
ora a livello di dominio web (e gli utenti usano posta/chat di quei
domini che non possono essere filtrato: google e yahoo, hotmail)
avete visto la strategia vincente dov'e' ? :P
secondo finale:
prima si filtrava a livello ip,
poi a livello tcp (e gli utenti facevano tunnel in udp),
ora a livello protocollo (se sei openvpn no, se sei http si) -> (e gli
utenti usano openvpn con l'opzione di incapsulamento del traffico in http).
domani ci sara' il proxy forzato ? e gli utenti useranno vpn over
XMLHTTPRequest/over flash/over XMPP
avete visto che tutti sta convergendo dentro il web ? e che i sistemi di
filtro sono molto meno efficaci se devono leggersi il contenuto di una
pagina web ? e che sono messi in ginocchio se devono leggere il
contenuto generato da javascript ?
(
http://freshmeat.net/projects/japcrypt/)
questo significa che, alzando il layer di comunicazione (ip e' basso
html e' alto), i sistemi di analisi/filtro sono messi in difficolta', e
noi dovremo usare questa lacuna tecnologica in questi anni, finche'
rimane, per infilarci il traffico che vogliamo noi.
quando anche questo non sara' piu' possibile, ci si potra' applicare
solo alla steganografia applicativa. a quel punto, l'utente si guardera'
indietro e vedra i tunnel come sistemi di steganografia molto grezza.
In quella, vedra' l'infinito e ne seguira' un ictuuuuuuuuuuuuuiopè+
