[LACNIC/Seguridad] Presentacion sobre seguridad en TCP/IP en KCA 2009

[Fernando Gont]

José Miguel Parrella Romero wrote:

>> Que cosa probaste? EL algoritmo "hash-based" que proponiamos nosotros, o
>> el esquema de aleatorizacion simple (basicamente, uso de "random()" que
>> algunos proponen?)
> 
> Probé grsecurity durante un tiempo para unos clientes del sector
> militar. El atractivo principal de grsec desde el punto de vista de
> redes era que promovía un algoritmo de aleatorización de puertos¹ en
> sistemas Linux.
> 
> Sin embargo, me preocupa bastante que para aplicaciones mainstream puede
> haber una incidencia importante de problemas de interoperatibilidad, yo
> no las he experimentado.

Si el algoritmo hace una aleatorizacion trivial (lease, simplemente
llama a randon() ), entonces es posible que encuentres problemas en
aquellos escenarios de red en los que se realizan muchas conexiones a un
determinado servicio en muy poco tiempo. (fijate la discusión sobre
"collisions of connection-id's" en draft-ietf-tsvwg-port-randomization o
en el doc de UK CPNI de TCP disponible en http://www.gont.com.ar/papers).

El algoritmo que propusimos nosotros ("hash-based", o aun mejor la
version mejorada que es "double-hash based") no tiene este problema, ya
que tiene las mismas propiedades de interoperatividad que el algoritmo
tradicional de los sistemas BSD que elige los numeros de puerto de
manera incremental.



> ¿Piensan que un mecanismo de transición en el cual se incorporen algunas
> de las recomendaciones que están en draft en ciertos escenarios podría
> ayudar a la adopción de las recomendaciones?

mm... no te entiendo bien... a que te referis con "mecanismo de transición"?



> Por ejemplo, la prueba que
> hice de grsecurity era para estaciones de trabajo de usuario final en un
> ente de Defensa; con una masa crítica importante de usuarios probando
> las recomendaciones "en producción" ¿habría algún impacto "político"?

Si te referis a "que es lo que podriamos hacer para que estas mejoras se
implementen", mmm... no estoy muy seguro.

Lamentablemente, muchos fabricantes parecen tener una postura de que,
salvo que haya suficiente presion por parte de la prensa (lease, que por
ejemplo haya una vulnerabilidad muy publicitada), no van a incorporar
contramedidas en sus sistemas. En mi humilde opinión, Cisco cae bastante
en ese area.

Otros fabricantes, como Juniper, han tenido al menos una intención de
incorporar contramedidas... pero no sé en que ha quedado.

Finalmente, en lo que respecta a sistemas operativos de software libre,
creo que la cosa es basicamente asi: si uno produjera el parche, es
bastante probable que la contremedida se adopte. Sin embargo, si uno
espera que los parches los generen los propios developers de esos
sistemas, la cuestion puede llevar mucho tiempo, e incluso no
concretarse nunca. En lo personal sigo con la idea de hacer un poco de
kernel-hacking en el corto plazo, y generar parches para los *BSD, para
Linux, y posiblemente para OpenSolaris. Pero como sería algo en mi
"tiempo libre", y ahora estoy a las corridas con el trabajo, es probable
que esto me lleve un buen tiempo.

Otra cuestion interesante es que la IETF ha adoptado los dos documentos
de UK CPNI (el de TCP y el de IP) para su futura publicacion como RFC. Y
si bien obviamente esto no es garantia de que las mejoras se
implementen, creo que va a contribuir para "llamar la atencion" de los
desarrolladoras, con la posibilidad de que muchos decidan incorporar al
menos algunas de las propuestas.



> ¹ BTW, ahora que leo en detalle los features, grsec también usa campos
> IP ID aleatorios, el resto de las cosas interesantes las hace PaX

En lo que respecta a grsecurity, creo haberles pedido a los developers
que me dieran un lisado de que mecanismos implementaba, asi podia
incluir referencias en todos los lugares y documentos en los que fuera
adecuado... Pero nunca me enviaron tal listado... y no estaba (ni estoy)
con tiempo para mirar el codigo a descifrar que es lo que estan haciendo.

Saludos cordiales,
-- 
Fernando Gont
e-mail: fernando en gont.com.ar || fgont en acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1