Barrapunto

desde media tarde, tenéis disponible el aviso oficial. Además del post del que lo descubrió en Slashdot.. cómo era evidente, su site ha sido "slashdoteado", vamos, que se le han comido los 20GB de ancho de banda mensuales en un día, alegría, alegría... hace tiempo que se leen comentarios sobre lo irresponsable de algunos editores de Slashdot por publicar enlaces sin revisar si hay mirrors, cómo ejemplo reciente, la release de woody... pero eso es otra historia..

sobre la noticia: la clave de la cuestión no es si se trabaja o no con los digests.. es decir: hasta que punto se puede confiar en los servidores oficiales? porque si alguien puede comprometer el servidor y meter el paquete troyanizado, también puede volver a generar las sumas y subirlas (ya sé, no coincidirán con las que tiene la gente)... la única solución que se me ocurre es que alguién del proyecto firme el fichero que contiene las sumas.. aparte, claro, de blindar los servidores lo máximo posible a todos los niveles, porque los peligros no son pocos.
vamos, que espero sirva de algo, porque últimamente está proliferando el tema: fragroute, iirc y bitchx son los que me vienen a la cabeza..

más.. si leeis el advisory veréis que el troyano intenta conectarse al puerto 6667 de una dirección determinada, lo cual plantea otra cuestión: porqué generalmente se configuran los filtros de paquetes sólamente para el tráfico de entrada?? si se hiciera en los dos sentidos muchas de las intrusiones se quedarían en nada o mejor dicho, en poco.

Sobre los filtros de paquetes, se configuran de entrada porque la gente normalmente si tienes acceso a internet no sabes hacia qué dirección van los paquetes.

Me parece de todas maneras que el 6667 que es el de los servidores de chat en muchas organizaciones se filtra para que la gente no chatee. Así que ahí lo llevaba chungo el troyano.

Pero vamos, si quieres la seguridad de que a una máquina sólo te vas a conectar tú, pues filtras todos los paquetes de salida excepto para tu IP fija (aunque hay técnicas para engañar no son sencillas).

Sobre los filtros de paquetes, se configuran de entrada porque la gente normalmente si tienes acceso a internet no sabes hacia qué dirección van los paquetes.

qué?!! si vas a configurar un filtro, es evidente que tienes que no tienes que saber forzosamente su dirección IP, no me has entendido.. me refería a configurarlo denegado por defecto en ambos sentidos (de tráfico), es decir, sólo habilitar lo *estrictamente* necesario. Que ofreces http? pues habilitas 80/tcp de entrada. Que quieres enviar correo? 25/tcp de salida.. que quieres acceder a un servidor pop3 externo con una dirección definida? aceptas 110/tcp de salida hacía él.. fácil, no?

Ese sistema no ofrece tampoco ninguna garantía, nadie le impide al programador de un troyano hacer que su criatura realice las conexiones hacia el exterior por puertos standard, por ejemplo por el 80. Obviamente el puerto 80 no lo vas a poder restringir de ninguna manera, a no ser que solo naveges por barrapunto ;)

no es tan obvio, generalmente divides una red en zonas (las chapucillas no son atrayentes cómo objetivos finales sino como trampolines); imagina que tienes una DMZ y un pf con stateful inspection (fw-1,pf,ipf,iptables..): siguiendo tu ejemplo, necesitas navegar desde los servidores? no, así que se restringe el tráfico de salida y punto.

cuando habilitarlo? la excepción más problemática es un servidor de correo y las controlables serían, por ejemplo, un servidor dns transfiriendo zonas, ciertas actualizaciones programadas o ntp (y todos estos se pueden restringir).

coincidirás conmigo que, aunque no es perfecto, este sistema ofrece más garantias que no poner ninguna restricción al tráfico de salida.

Un par de cositas a comentar:
- Sobre el hackeo del sitio ftp de OpenBSD: el sitio en cuestion (ftp.openbsd.org) es un SunOS 4.1 (si, algo antiguo...) al que parece ser que se le ha entrado debido a las recientes vulnerabilidades de OpenSSL (cuando Theo dice que se deberia hacer un fork de OpenSSL es por algo...). No entiendo el revuelo que se ha montado con el hackeo de este sitio... !que es un SunOS 4.1! !Que no es OpenBSD! Ayer me canse de ver flamers en los canales de #openbsd que frecuento...
Si alguien quiere saber por que el server es SunOS en vez de OpenBSD, puede consultar como siempre la FAQ (resumiendo: Sun dona un canuto y un equipo que no puede permitirse pagar el proyecto OpenBSD).
- Respecto a lo del puerto 6667, imagino que todo servidor decente tendria que tener protegidos sus puertos de salida, y solo dejar abiertos los que tengan salida real... eso a menos que te dediques a chatear desde tu servidor :PP

No entiendo el revuelo que se ha montado con el hackeo de este sitio... !que es un SunOS 4.1! !Que no es OpenBSD! Ayer me canse de ver flamers en los canales de #openbsd que frecuento...

en Internet, cómo en todos lados, hay mucha gente que por ignorancia o por malícia se dedica a desinfomar, no se cómo te sorprendes. Más teniendo en cuenta la simpatía de algunos por Theo de Raadt. Espero que entendieses que hablaba genéricamente: los servidores primarios y los mirrors oficiales deben ser de fiar, porque parte de la seguridad de estos sistemas operativos se basa en la confianza que uno tiene cuando de descarga algo desde ahí.. que sea SunOS (cualquiera que haya leído la FAQ o haya hecho un ftp a ftp.openbsd.org lo sabe) es totalmente secundario, aparte de que las vulnerabilidades en openssl afectaron igualmente a OpenBSD.

- Respecto a lo del puerto 6667, imagino que todo servidor decente tendria que tener protegidos sus puertos de salida, y solo dejar abiertos los que tengan salida real... eso a menos que te dediques a chatear desde tu servidor :PP

esto que parece tan obvio no es, ni de lejos, habitual.