Barrapunto

1. la máquina del administrador no está conectada a ninguna red?
2. cuántas máquinas lo llevarán? cuántas no?
3. habrá soporte desde cualquier sistema operativo?
4. para páginas estáticas perfecto, pero.. y si tengo que generarlas a partir de una base de datos? también será sólo-lectura?

Me parece matar mosquitos a cañonazos.

Si quieres un servidor web seguro, te montas un sistema operativo seguro, configurado de una manera minimalista, haces funcionar el servidor como un usuario nada privilegiado leyendo páginas de una partición donde no tiene permiso de escritura. Si eres muy exagerado, remontas la partición en sólo-lectura, y si lo eres más remontas TODAS las particiones del sistema de sólo-lectura. Si eres exageradamente exagerado, le metes OpenBSD . ;-)

La pregunta que han formulado antes es verdad: ¿qué pasa con las páginas dinámicas que requieren acceso a escritura en el disco?

¡¡Me parece una SALVAJADA duplicar hardware para conseguir tan poco!!

Si he entendido bien (que seguro que no), el administrador tiene que estar conectado al servidor con un cable para poder utilizar la cabeza de lectura/escritura... Pues qué bien, a la mierda la gestión remota...

Y ya puestos, si hay que estar delante del servidor, pues utilizo un mísero disquete con la pestañita quitada y ya no se puede escribir en él... O si las páginas no caben en un disquete, se puede usar un cd-rw, lo grabas en la tostadora y luego lo metes en el lector...

No sé, se me debe escapar algo... O a lo mejor es a ellos...

En fin, voy a currar un poco,
 

Estoy de acuerdo en los comentarios que se han hecho (no podria haber paginas dinámicas, se pueden montar las particiones en modo sólo lectura...), pero esto del CD y del diskete me parece una tontería, con todos mis respetos.

Acordaos de que un servidor web tiene que ser lo más rápido posible. Por tanto, la tasa de transferencia de un diskete o un CD, comparadas con la de un buen disco duro, es de risa. Esta solución no es una opción a tener en cuenta en un servidor serio. ¿Os imaginais a google tirando de disketes? :-)

Un saludo.

Lo de que el cd y el disquete son mucho más lentos, ya lo sabía... Quizá me faltó el ;-)

Aunque con los mega-lectores a toda caña de cd's, quizá para un server modesto podría tirar... No sé, es cuestión de probar

De todas formas, me sigue pareciendo igual de chorrada el tener que irte al servidor con el portatil y el cablecito para cambiar un web por miedo a que los 'jakers' malosos te pongan un 'y0 h3 3sta0 4qu1' ;-)

En fin, que sigo currando... (más o menos xDD)

     

Así a ojo y rapidillo, esto se me ocurre q les falla:

• Escritura de logs: uso de syslogd y similares contra servidor remoto -> Seguro q si ejecutan codigo con un exploit, se puede acceder a traves de lan a la q administra los logs :)
• BBDD atacada contra otra makina -> explotabilidad exportada :)
• Passthru de archivos a traves de la makina desde inet a sistema RW, mas de lo mismo.
• Directorio temporal para queues, spools... vamos, q si no en /var en /tmp debes poder escribit, y sino el archivico de paginacion de bindous. Total, que en algun sitio, aunke sea un ram disk, algo se puede meter :P
• CGIs puede haber y funcionaran, pero implementando carajas como las aki arriba citadas, sin librarnos de casi ning´un bug de los servers.

No sólo de disco duro vive el server, el sistema es, en resumen, un puto CDRW pegado a caja de disco duro, los sistemas de arranque desde Filesystems RO, necesitan zonas de escritura temporal, generalmente en ramdrives.

En resumen: Fantasmada mercantilista de la esfera Get-Afraid-From-The-Internet.

Best regards,

Kenneth Peiruza
Unix Networks Engineer
GnuNetworks @ Barcelona

PS: Sorry 4 accents, i'm tired of writing html's acute & grave ;)

Ni tanto ni tan poco ;)

El 90% de las webs son estaticas: el sistema operativo hace cach´e de la entrada/salida, por lo que, con un buen dimensionamiento, puede servir webs a la misma velocidad desde CDROM q desde HD o disquetera una vez esta en cache. Probad a copiar un archivo en casi *unix a disquetera, leer ese archivo es INMEDIATO ;)

Obviamente, otra historia es una BBDD o, en general, un sistema q deba tocar bantantes megas e archivos (binarios, webs, ...) aki se nos puede disparar la ram.

Vamos, que para algunos sites basta con el diskete, sin ir mas lejos, LRP, un router/firewall en un diskete, va lento? no, solo arranca lento.

perdon, pero las cockies se guardan en el lado cliente. ejem...

supongamos esta maquina:

  ordenador que arranca de un cdrom, mostrando una pagina web que esta en ese cd-rom o en este disco duro de solo lectura. Bien,en principio nadie
va a cambiar las paginas estatisc, pues estan en un dispositivo de solo lectura. PERO ME ES IGUAL. Rompemos la seguridad del servidor de paginas y lo hacemos mostrar paginas de alguna otra parte y ya esta. Esto se puede hacer con un overflow o con cualquier otro bug del servidor de paginas

O envenenar la cache del DNS secundario y machacar el primario, direccionar contra ficheros creados en ramdrive, modificar la conf del apache en ese tempdir y reiniciarlo, DOS, local DOS, DDOS...

un apunte:
  es muy atractivo tener un webserver sin partes moviles y solo lectura. Si aun asi necesitamos logs, o algun sistema de ficheros temporales, porque lo exige apache o el programa que sea, aun podemos dedicar una parte de la memoria a disco duro virtual, por ejemplo 512 MB y almacenar ahi toda esa informacion. Asi que yo no veo tanto problema. En el resto de tu mensaje estoy absolutamente de acuerdo, los programas tienen vulnerabilidades, muchas porque son muy complejos y no se diseñan como software seguro (que seria caro y serian lentos) con una de estas entramos en la maquina y hacemos el destrozo, por ejemplo enseñar una pagina porno en lugar de la que se pretendia.

He visto One Disk Linuxes con thttpd, Wendigo hizo uno q tiraba bastante bien, si esto, en vez de FD se hace con CDROM, tienes una imagen de arranque de 2.88 mB, de sobras para eso y mas, puedes arrancar desde un fs comprimido gzip y un kernel "concatenados" o bien un kernel cuyo root fs apunte al dispositivo del CDrom.

En referencia a los logs del apache, yo los guardar´ia bien, no en un ramdrive, ya q un reinicio/cuelgue te los envia ATPC. Y son tu primera prueba de intrusion.

Cierto, pero las sesiones son server-side, y si no vas contra BBDD, usa un directorio temporal y 1 fichero x session.

Vamos, q cookies no son, pero problemas hay: lo de siempre, ramdisk, total, si hay q reiniciar el sistema, las sesiones caducan =mente ;)

bueno, en la misma línea, antes creo que uno podia proteger contra escritura el disco a través de la BIOS... jeje

bueno, si tienes abiertas sessiones sobre una base de datos imagino que al colgarse un servidor "se pierden", jejeje.. pero desde luego no las cockies, se puede tener una cockie configurada para durar un año, coger el webserver, pegarle fuego, y volver a montarlo con otro ordenador, utilizando una copia de seguridad. El cockie ni lo notara. Y lo de los ficheros temporales, ya se ha hablado, no es que sea precisamente util, pero se los puede tener en ram. Y si nos ponemos bordes, yo creo que se podria abrir conexiones tcp para exportar la salida de logs a otra maquina. Asi que si que es posible tener webservers tirando de solo lectura, incluso desde un disquete solo lectura, si quieres. Ejemplos habra por ahi.. aunque no lo he mirado.

La idea suena bastante graciosa pero me parece que la seguridad de un sitio web no depende solo del tipo de acceso al disco duro, vale que es un control de seguridad extra, con mas inconvenientes que ventajas, creo yo pero una vez te has colado en el server que te impide por ejemplo montar en ramdisk las paginas web modificadas y reiniciar el server con otra configuracion?. O modificar la configuracion del server para que redirija los accesos a otro server. Y si lo que quieren es proteger contra el borrado de datos por que no usan un proxy? no veo clara la idea, bueno si, sacar pasta, pero la utilidad ...

lo próximo que será?, memoría RAM de solo lectura? ô_O
Mis conocimientos de hacker son mínimos, pero si no me equivoco, se podría producir un buffer overflow y desviar el flujo de datos de la memoria RAM produciendo la ejecución de código malicioso ...