Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
Horney Patches
Uno de los debates que tiempo ha han dedicado mis mejores broncas en algunos de los más perdidos bares es el tema de confundir el Uptime del servidor con el Uptime del Servicio. Existes seres que cuentan el tiempo que lleva su servidor sin reiniciarse como el que cuenta los intereses de la cuenta naranja de ING y luego se defienden como gato panza arriba cuando les preguntas por los parches. Las respuestas pueden ser de lo más peculiares que yo las he ido catalogando:
A) Servidor Chuck Norrix: Son los que usan esta distribución de Linux al más puro estilo Ranger y están por encima del bien y del mal. La respuesta suele ser:
¿Parches? Mi server es un hax0r y no tiene bugs y no necesita parches…
B) IT Pro Sherlock Holmes: Son los que ante la pregunta de por qué su servidor lleva 400 días de uptime responden:
¿Parches? Me los reviso uno a uno y sólo he instalado los que aplican a mi entorno. Y como mi equipo no tiene ni kernel, pues no le he tenido que aplicar ninguna.
¿Qué tienes majo, un Furby server?
C) El servidor en escabeche: Los servidores son como las anchoas, se conservan sin tocarlos, por lo que los servidores NO se parchean. Eso, y si puedes ponlos de cara a Internet y sin contraseñas, que tengo unos amigos locos por visitar tú servidor. Os dejo un mail de un sufrido lector de este blog:
Fijaros el trabajo que duro es. PRIMERO: Haz el parche y comunica a todo el mundo que hay un parche nuevo. SEGUNDO: Comunica a todo el mundo que no lo instale. Trabajar en Spectra es duro.
El mail lo deja claro..."Nosotros te lo instalamos, pero que sepas que... SE TE VA A JODER EL UPTIME sólo por 57 actualizaciones críticas de mierda".
D) Horney Patches: No, eso de reiniciar tras aplicar un parche es un atraso desde que existen las estrategias de parcheo en caliente.
Nosotros parcheamos on fly…
Es este último tipo de respuesta el que más me preocupa. Vaya por delante que generalmente la peña que da una de estas tres respuestas suele estar excusando una negligencia supina que se ha basado en no aplicar ninguna solución de parcheo y que lo único que busca es salir airoso del rincón donde se encuentra atrapado. La verdad es que sí tiene parches, no se ha revisado todos los parches de todos los productos que están corriendo en su servidor uno a uno y, por supuesto, no parchea en caliente.
Parchear en caliente es una solución delicada. Los sistemas MS Windows, desde Windows Server 2003 SP1, realizan, automáticamente, parcheos en caliente si está habilitada la opción de hotpatching. Para ello, los parches en caliente (que no cachondos) de los sistemas Windows llevan asociado el hotpatch, con los cambios que se deben realizar a la imagen cargada en memoria, y el coldfile, con el nuevo fichero que debe suplantarse.
Sin embargo, esto no siempre se puede realizar por lo que están catalogadas algunas limitaciones conocidas y algunos problemas de compatibilidad (que se habrán descubierto "por las malas"). Hay que tener en cuenta que el número de software instalado en un equipo es difícil de cuantificar y siempre queda la opción de que pueda darse alguna incompatibilidad que te fastidie "tu uptime".
Si el utilizar estrategias de parcheo en caliente con el software del sistema es complejo, el aplicarlo con componentes ejecutándose con altos privilegios que no vienen preparados para hotpatching es aun más temerario. La idea es que existen herramientas para que tú te crees el parche adecuado para esos componentes, es decir, el hotpach y el coldbinary utilizando herramientas externas. Esto, si estamos hablando de un servidor tan crítico que no puede ser reiniciado es una temeridad por si se produce cualquier fallo: tanto de incompatibilidad o como de cagada humana.
En resumen, si tu servicio es tan crítico que no se puede detener, entonces monta una estructura multiserver que para eso existen los clusters, los sistemas de réplica o las arquitecturas distribuidas. Si no es tan crítico el servicio, aplica los parches en la mejor franja horaria y reinicia cuando el fabricante te lo diga. Y si la has cagado a lo grande y el servicio no puede ser parado y has diseñado una arquitectura mono-servidor, entonces, y sólo entonces aplica la opción B) (por si tienes suerte) y la D) (para ver si salimos de esta).
Saludos Malignos!
A) Servidor Chuck Norrix: Son los que usan esta distribución de Linux al más puro estilo Ranger y están por encima del bien y del mal. La respuesta suele ser:
¿Parches? Mi server es un hax0r y no tiene bugs y no necesita parches…
B) IT Pro Sherlock Holmes: Son los que ante la pregunta de por qué su servidor lleva 400 días de uptime responden:
¿Parches? Me los reviso uno a uno y sólo he instalado los que aplican a mi entorno. Y como mi equipo no tiene ni kernel, pues no le he tenido que aplicar ninguna.
¿Qué tienes majo, un Furby server?
C) El servidor en escabeche: Los servidores son como las anchoas, se conservan sin tocarlos, por lo que los servidores NO se parchean. Eso, y si puedes ponlos de cara a Internet y sin contraseñas, que tengo unos amigos locos por visitar tú servidor. Os dejo un mail de un sufrido lector de este blog:
Fijaros el trabajo que duro es. PRIMERO: Haz el parche y comunica a todo el mundo que hay un parche nuevo. SEGUNDO: Comunica a todo el mundo que no lo instale. Trabajar en Spectra es duro.
El mail lo deja claro..."Nosotros te lo instalamos, pero que sepas que... SE TE VA A JODER EL UPTIME sólo por 57 actualizaciones críticas de mierda".
D) Horney Patches: No, eso de reiniciar tras aplicar un parche es un atraso desde que existen las estrategias de parcheo en caliente.
Nosotros parcheamos on fly…
Es este último tipo de respuesta el que más me preocupa. Vaya por delante que generalmente la peña que da una de estas tres respuestas suele estar excusando una negligencia supina que se ha basado en no aplicar ninguna solución de parcheo y que lo único que busca es salir airoso del rincón donde se encuentra atrapado. La verdad es que sí tiene parches, no se ha revisado todos los parches de todos los productos que están corriendo en su servidor uno a uno y, por supuesto, no parchea en caliente.
Parchear en caliente es una solución delicada. Los sistemas MS Windows, desde Windows Server 2003 SP1, realizan, automáticamente, parcheos en caliente si está habilitada la opción de hotpatching. Para ello, los parches en caliente (que no cachondos) de los sistemas Windows llevan asociado el hotpatch, con los cambios que se deben realizar a la imagen cargada en memoria, y el coldfile, con el nuevo fichero que debe suplantarse.
Sin embargo, esto no siempre se puede realizar por lo que están catalogadas algunas limitaciones conocidas y algunos problemas de compatibilidad (que se habrán descubierto "por las malas"). Hay que tener en cuenta que el número de software instalado en un equipo es difícil de cuantificar y siempre queda la opción de que pueda darse alguna incompatibilidad que te fastidie "tu uptime".
Si el utilizar estrategias de parcheo en caliente con el software del sistema es complejo, el aplicarlo con componentes ejecutándose con altos privilegios que no vienen preparados para hotpatching es aun más temerario. La idea es que existen herramientas para que tú te crees el parche adecuado para esos componentes, es decir, el hotpach y el coldbinary utilizando herramientas externas. Esto, si estamos hablando de un servidor tan crítico que no puede ser reiniciado es una temeridad por si se produce cualquier fallo: tanto de incompatibilidad o como de cagada humana.
En resumen, si tu servicio es tan crítico que no se puede detener, entonces monta una estructura multiserver que para eso existen los clusters, los sistemas de réplica o las arquitecturas distribuidas. Si no es tan crítico el servicio, aplica los parches en la mejor franja horaria y reinicia cuando el fabricante te lo diga. Y si la has cagado a lo grande y el servicio no puede ser parado y has diseñado una arquitectura mono-servidor, entonces, y sólo entonces aplica la opción B) (por si tienes suerte) y la D) (para ver si salimos de esta).
Saludos Malignos!
11 comentarios:
Pahaberse matao! con la respuesta al mail! Madre mia, esta chusma se merece una buena denuncia!
No se mucho del mundo empresarial, pero creo que es bastante patético que se mida la calidad del servicio por el valor del uptime (si es que es así...).
saludos!
Newlog
Hola,
Desgraciadamente, la única forma de conseguir que los sysadmins apliquen los parches de seguridad es contratar una auditoría externa e incluirlo en los resultados.
Si no es así, y dado que ellos son los que se encargan de que el servicio corra 24/7, tienes que tirar de abrir una petición, imputarle horas, ... y acaba en todo en el olvido.
Saludos,
Eduardo.
Yo se de un ISP (del que no diré el nombre) que me dijo que el SP2 de un W2003 daba problemas y por eso no lo habían instalado..."Si quiere instalarlo firme esta hoja librándonos de cualquier problema"
Y eso que el server es suyo... a mi no me mola el "si algo está bien, no lo toques", ya que si fuera así, iríamos en burro aún.
Claro Eduardo, los sysadmins vivimos del aire el resto del año.. (barre pa casa si eso, Sr. auditor.. de hecho si los técnicos hiciesemos todos bien nuestro trabajo los auditores casi casi que sobrarían)
Hace años que está fuera de criterio hablar de uptime de servidores/servicios en entorno empresa, al menos en la mía es una bobada medir eso. (Salvando lo obvio de algún SLA, claro)
Yo creo que Chema va mas por la falta de esfuerzo de muchos a la hora de hacer su trabajo. No vale decir que sean entornos de producción críticos o cualquier blablabla que se le ocurra a cualquier técnico, es desidia, que para eso existe la virtualizacion y los entornos de pre.
/ironic.. el año pasado eras tu Chema el que estabas midiendo el uptime de algunos justamente para dar cera a Canonical, por el interés andres..xD
Saludos!
@Centos, yo se que me alovius, y que has dicho eso recordando que hablaba de uptime de SERVICIO y no de SERVIDORES ;)
Felices amorosas fiestas!
@Anónimo CentOS
"Claro Eduardo, los sysadmins vivimos del aire el resto del año.."
En ningún lado he dicho tal cosa ... pero tenéis otros intereses (backups, caídas de servicio, mantenimiento de aplicaciones, ...) y desde luego son opuestos a los de los auditores, al menos muchas veces. Aparte, son más que de sobras para no tener tiempo para otras cosas. Cada cual lo suyo.
Y precisamente como nadie, ni los auditores, hace bien su trabajo, los técnicos no sobráis. Así os podemos cobrar una pasta por decir algo que, normalmente, ya sabéis que había que corregir. Muchas veces las auditorías son contratadas como forma de obligar a cambios internos que, de otra forma, tendrían mucha oposición y no podrían hacerse.
Es como funciona el mundo.
Desde el respeto a los auditores te puedo decir que para qué se va a contratar a nadie externo para que nos diga obviedades a los técnicos de campo; Para eso están los jefes de mi propia empresa; a los que se les proponen tanto soluciones a problemas conocidos tanto como proactivamente intuir por donde puedan petar las cosas a corto/medio plazo y tratar de evitarlo.
Hablas de intereses durante el año y que no saquemos tiempo para todo, ese tampoco es problema de los que ya estén trabajando, si no sacan tiempo pues se contrata a mas gente pero no se dejan NUNCA cosas sin hacer. El resto es desidia/falta de informacion (A mi me daría vergüenza que tuviera que venir nadie a corregir mi trabajo, y mas aún siendo externo)
Auditorías las justas, para certificaciones y poco mas, que el trabajo de técnico ya sabemos hacerlo (o al menos para eso se nos contrata, ASÍ funciona el mundo)
Saludos
Wi®
@CentOs:
No siempre es así como tú dices ... Debería serlo, pero de allí a que lo sea ...
Hace un tiempo estuvimos en una empresa con recursos bastante limitados en cuanto a sysadmins, por así llamarlo, se refiere. Tenían una red bastante "agujererada" y un problema con fugas de información y virus.
La cosa es que esta gente, salvo que el director de sistemas lo dijera explicitamente, no podían dedicar ni un minuto a la seguridad, porque no lo tenían. Eran 3 o 4 y tenían otras prioridades más críticas - estoy hablando de un hospital, que es fácil imaginar que tiene otras prioridades más importantes, con su propio desarrollo web, etc ....
Al final, nos contrataron a nosotros para decirles algo que, hablando luego con ellos, ya sabían pero no podían cambiar porque los proyectos que tenían no los podían reordenar sin una auditoría externa que lo avalase.
Otras veces, y no pocas, he visto usar informes de PCI-DSS para cambiar en horas cosas que se había pedido meses atrás y que no se habían hecho por falta de tiempo ... Porque tú, como yo y como todos, ¿querrás irte del trabajo con la familia/novia/amigos/... antes de las 12 de la noche? ¿No?
Lo he visto un montón de veces. Y no es que fueran vagos, inútiles, que no supieran de qué iba la cosa ... Es que no podían. Otras veces si es cierto que las auditorías sacan agujeros de verdad importantes, pero no estamos hablando de eso.
¿¿Supongo que vivimos en mundos distintos??
Saludos, y pasa buenas fiestas.
Que va, vivimos en el mismo pero con otro enfoque, obviamente cada uno ve mas su trabajo que el del resto, y hablo de los dos..
Es evidente que para un hospital no prima la seguridad sobre otras cosas, incluso te podría contar de hace poco uno en cataluña al que le implantamos un CMS y descartaron una gran parte del diseño previo porque precisamente no priman la seguridad (de momento, que ya les llegará)
De lo del tiempo y salir tarde, pues cuando nos toca jodernos mil horas para cerrar brechas, parcheos o lo que toque pues me quedo y me jodo, pero ahí está también el director igual que cualquier otro quedándose también.. (y no es broma) Trabajo es trabajo y punto, que pa eso se nos paga..
Ahora bien, las auditorías tampoco garantizan nada, o acaso no estaba mas que superauditado WorldCom, Arthur Andersen, o tantas otras que se han caído luego quién sabe por qué..
Simplemente digo que una auditoría externa sólo se debe hacer cuando es necesario por falta de medios internos para llevar a cabo un trabajo similar desde sistemas (o quien sea el caso) Pero si nos vamos a la típica empresa con becarios sobreexplotados pues normal que veáis un nicho de mercado en ello, te aseguro que no os faltará trabajo; pero siendo pragmático es un grave error de los jefes ya bien por no formar adecuadamente a los trabajadores para lo que se les exija luego como por la explotación desmesurada de sus técnicos (y esa si es la lacra real a erradicar).
Felices fiestas you too!
Wi®
Ya lo ha comentado CentOS, un entorno virtualizado o de preproduccion...
Tambien es verdad que hay muchas variantes:
Personal, politica de empresa, administracion federada, criticidad...
En el debate auditores|tecnicos de Eduardo Abril y CentOS estoy deacuerdo con ambos en varios puntos.
Felices Fiestas!
Yo me se de alguno de mi universidad, que a la hora de instalar un equipo, decía... "Pero si los parches dan igual". No me lo comí de chiripa. Menudo rapapolvo le eché. Lo que nos comentó uno de vosotros hace unos meses: lo de decir lo que puede pasar no suele ser suficiente. Si se enseña visualmente ayuda más. Así es como al final seguro que aplican los parches.
Publicar un comentario