Recomendaci?n FEDORA.

Blu blu en daga.cl
Vie Oct 15 16:54:31 CLST 2004


On Fri, Oct 15, 2004 at 01:46:21PM -0300, Carlos Manuel Duclos Vergara wrote:
> >
> > Si no haces actualizaciones de seguridad todos los dias si que puedes
> > estar en aprietos.
> >
> 
> no necesariamente, puede causarte mas problemas de los que te solucione.
> Te propongo el siguiente ejemplo, tienes un datacenter que contiene una
> aplicacion propia para hacer analisis de tus datos y que es usada por tus 
> usuarios 16 horas al dia (no voy a poner el caso de 24 horas para que el
> ejemplo sea mas simple).
> Si aparece un problema o un exploit que afecte tu datacenter, no puedes
> llegar y hacer un update porque:

Digamos que es un exploit.

> 1.- No sabes si el update va a resolver el problema o el exploit

Obviamente eso hay que saberlo.

> 2.- No sabes si va a afectar el funcionamiento normal de tu datacenter y/o
> tu aplicacion

Con toda seguridad no, pero un parche proporcionado por el equipo de
seguridad de la distribucion afectada o el autor del software algo de
confianza se merece.

> 3.- Durante las 16 horas de uso no puedes llegar y updatear aun cuando
> las variables 1 y 2 esten controladas ya que podrias causar algun tipo de
> corrupcion en las transacciones en curso o bien podrias darle un dolor
> de cabeza a algun usuario que esta en el medio de una operacion

Bueno, aquí habria que sopesar el posible daño de molestar a los
usuarios durante un rato (se que puede ser caro), o arriesgarse a dejar
una máquina expuesta a un exploit que anda suelto durante varias horas,
lo que podría significar desde tener que reinstalar todo en el mejor de los
casos, a ver comprometidos datos sensibles en uno de los peores.

> para este caso tienes que usar un servidor gemelo del principal, parcharlo
> (sin bajar el otro) y correr pruebas para saber que tal se comporta. Lo mas
> importante es calcular cuanto tiempo requieres para hacer el cambio y
> que cosas vas a modificar. Si llegas a la conclusion de que resuelve el
> problema y que te demoras menos de 8 horas en tener todo andando, entonces
> una vez que tienes todo configurado en el servidor gemelo esperas la ventana
> de tiempo de 8 horas, subes el servidor gemelo y bajas el principal. Hecho
> esto configuras el servidor principal y en cuanto hayas corrido todas las
> pruebas lo vuelves a subir desconectando el servidor gemelo.
> Si las pruebas no son exitosas entonces tienes que buscar alguna medida de
> emergencia que te permita sobrellevar la situacion hasta que haya un update
> que si resuelva el problema (generalmente desconectando el servicio que causa
> problemas, prohibiendo la ejecucion de los comandos conflictivos, etc...).
> Esto implica no actualizar!!!
> Si el tiempo que te demoras es mayor que la ventana de tiempo que hay tienes
> que programar el update para mas adelante cuando si dispongas de tiempo (por
> ejemplo un dia sabado o un domingo). Esto implica no actualizar y planificar
> el update para mas adelante.

Me parece muy bien ese método, muy robusto y no se molesta a los
usuarios, pero es aplicable cuando se tienen los recursos, el tiempo y
el risgo de compromiso es bajo. Al menos yo preferiría que me lumearan
por bajar un servicio en hora de trabajo, a que me crucifiquen porque se
robaron la base de datos o porque el dominio apareció de pronto en todas
las listas negras del mundo.

Blu.



Más información sobre la lista de distribución Linux