|
|
|
Secciones
Obrar mucho, y hablar poco; que lo demás es de loco.
Barrapunto © 1999-2007. Contenido disponible bajo licencia Creative Commons Reconocimiento 2.5
Aviso legal
Barrapunto © 1999-2007. Contenido disponible bajo licencia Creative Commons Reconocimiento 2.5
Aviso legal
Re:Me gustaría saber en qué ha basado este hombre.
(Puntos:1)( http://www.danielclemente.com/ | Última bitácora: Sábado, 08 Octubre de 2005, 18:08h )
kernels: sí, unas 20 veces, pero la primera vez ya quedó bien. Las siguientes fueron sólo para retocar detalles como: quitar USB, poner iptables, poner mejor iptables, y sobre todo, probar todas las opciones para ver si alguna hacía funcionar la tarjeta de red PCMCIA.
#!/bin/sh: conozco muy bien todo lo de ARP poisoning y cosas mucho más complicados, pero eso no me obliga a saber que hay que poner esa línea para que algo del cron funcione (¿la pones tú siempre en tus scripts?
ps aux: sí, hago ps y veo cosas que no sé que son; que yo no he pedido, por ejemplo inetd cuando no es necesario. No todo eran procesos; por el syslog iban saliendo MARKs y otros mensajes.
php: ¿te has leído el código de PHP? Yo no, ni lo entendería. El de thttpd es muy sencillo y sólo me lo miré por encima para comprobar el estilo de programación (si muy chapucero, bien hecho, ...)
apache: pues a Apache cada cierto tiempo le encuentran fallos, algunos MUY importantes. A thttpd no.
He corregido algunas cosas, si ves otros detalles avísame y te los explico o lo pongo en la web
thttpd no es más seguro que Apache
(Puntos:2)apache: pues a Apache cada cierto tiempo le encuentran fallos, algunos MUY importantes. A thttpd no.
Remote overflow in thttpd [seclists.org], ¿ok? Una simple búsqueda de google me ha llevado a eso.
Ahora vamos a la página de Jef (que he usado tanto thttpd como el micro de 150 lineas, por cierto). Visitamos concretamente la página del thttpd [acme.com].
Si miras los cambios de la versión 2.24 aparece: Fixed buffer overflow bug in defang().
¡Nada más! No hay información explícita de sobre problemas de seguridad... ¿eso hace este Software más seguro? ;)
Todos, repito TODOS los programas tienen fallos. Pero si thttpd no los gestiona adecuadamente... para mi no tiene suficientes garantías.
No digo que thttpd no sea un programa seguro. Hasta donde he leído código de ese tío, no puedo decir que no sepa lo que hace. Pero de ahí a suponerlo infalible... hay un trecho muy largo y complicado ;)
Los informes de error de Apache [apache.org] para mi sí son adecuados. ¿Qué se descubre un fallo? Pues se parchea/actualiza y punto.
Muy lógicas no son algunas de tus decisiones, la verdad. Cuando todo funcione bien, deberías revisar un poco tus esquemas. Aunque yo sí consideraría thttpd en un entorno con muy pocos recursos, creo que en tu caso sería subestimar la máquina de la que dispones ;)
Un saludo.