Feda /dev/ - No Javascript allowed | Página 1915

GaN2 #57421 20 Jul Inocente

#57413 Como va a ser culpa de MS? Crowdstrike actúa a nivel de kernel, MS en este caso poco más va a poder hacer salvo poner algún mecanismo para que en caso de fallo no pete el SO. Es como si tengo una aplicación que se dedica a crear kernel panics y le echo la culpa al fabricante del SO porque le peto sus software…

Volviendo a tu ejemplo del coche, es como si le meto un mecanismo que controle toda señal eléctrica del coche y en mitad de la autopista la corta because potato. La culpa es del coche?

#57420

Si fuesen solo servidores, se restaura todo en menos de 15 mins si lo tienes bien montado en el 90% de los casos...

No conozco a ninguna empresa que tenga de RTO 15 minutos en su plan de contingencia contra desastres para servidores en su infraestructura y menos aún usando backup/restore. Además de que en este caso una réplica a un data center en standby no te vale porque en el momento que se replique el update te va a hacer un brick cojonudo del servidor y suerte para levantarlo. Lo único una réplica con time travel que esté X minutos/horas por detrás y teniendo en cuenta como se ha hecho el rollout de la actualización suerte para buscar el punto en el tiempo exacto para lanzar la réplica y hacerlo antes del que el time travel expire…

2 respuestas

Slowbro #57422 20 Jul

#57421

#57421GaN2:
Como va a ser culpa de MS? Crowdstrike actúa a nivel de kernel, MS en este caso poco más va a poder hacer salvo poner algún mecanismo para que en caso de fallo no pete el SO

Voy a decir una tremenda cuñadez, pero no estaría bien en 2024 pedirle a un OS que en caso de arranque fallido tenga rollback a ultima configuración (por lo menos kernel y drivers) valida? Ojo, lo digo sin desmerecer a CS, que ha hecho historia.

Si windows es un sistema critico, tendrá que empezar a seguir las reglas y pasar certificaciones.

4 respuestas

desu #57423 20 Jul

#57422 1 comentario ignorado [Mostrar]

1 1 respuesta

Slowbro #57424 20 Jul

#57423 Me voy a arrepentir, pero.

¿Hay algún motivo por el que no se pueda hacer eso desde alguno de los bootloaders en windows?

1 respuesta

r2d2rigo #57425 20 Jul Inocente

#57422 pero si precisamente así es como se resuelve el problema, arrancando en recovery mode.

2 respuestas

desu #57426 20 Jul

#57424 mi mensaje era una indirecta a que el usuario con el que discutes te va a ignorar

es su mecanismo de escape cuando se siente acorralado en una discusión

soy más gracioso de lo q os pensáis

1 respuesta

Slowbro #57427 20 Jul

#57425 Si, pero me refiero a la parte de cargar automáticamente un estado previo medio funcional (a nivel de usuario). Algo así como: a) arranque normal, b) arranque automático a estado previo (normalmente checkeando contra drivers de terceros), c) recovery.

#57426 Te pasas mucho con gan2, es el googler que más me ha respondido (incluyendo issues en repos y mensajes en google-groups), con bastante diferencia xD

1

Konishi #57428 20 Jul :psyduck:

#57422 desde la barra del bar, me imagino que el principal problema es determinar de forma automática en qué puntos se deberia generar ese punto de rollback y sin que afecte en gran medida al rendimiento del equipo/servidor.

En este caso ha sido Crowdstrike, pero me imagino que en la mayoría de casos habrán varios servicios que caerían en el mismo saco, y tampoco es que M$ no la pueda liar y meter sus propios bugs en un sistema como ese. ¿Cómo lo validarían si cada proveedor puede acabar causando algún problema o solapándose en el "backup"?

Y luego aunque en unos meses M$ diga "hemos creado un nuevo sistema 100% seguro no fake Copilot approved para impedir Crowdstrike 2.0", ¿a cuántas empresas (no precisamente pequeñas) tienen que convencer para adaptarlo hasta que se considere el nuevo estandar?

Que creo que evidentemente se deberían replantear como están las cosas actualmente y que se puede hacer para mejorarlo, pero conseguir tal cambio con tantos involucrados de por medio no me parece nada fácil.

2

GaN2 #57429 20 Jul Inocente

#57422 Como te dice #57425, para ello tienes el recovery mode en Windows o Linux por si alguno de los ficheros de configuración tiene un error y tienes que arreglarlo. Es complicado el tema porque, donde pones el mecanismo que chequee la configuración? Por ejemplo, esta es la secuencia de arranque de Linux:

La ponemos en el paso 3 por si acaso hay alguna cagada cuando se definió el boot device? En el paso 4 por si el usuario jodió el grub.cfg? En el paso 5 si algún servicio crítico no levanta? O en el paso 6/7? Que hacemos cuando las configuraciones no pertenecen al mismo punto en el tiempo? Es decir, paso 5 funciona pero paso 7 falla. En ese caso que configuración usamos? Como aseguramos que hay una consistencia a nivel de configuración? También hay que tener en cuenta el tiempo de arranque, si le metes pasos extra a la secuencia para chequear que la configuración es valida y revertir cambios se puede hacer eterna.

Bajo mi punto de vista es un problema que tiene dificil solución y especificamente en el caso de la cagada de CrowdStrike dudo que hubiera solucionado el problema. Además, prefiero pensar que alguien ya ha tenido esta idea y que por A o por B se ha escartado.

3 1 respuesta

Konishi #57430 20 Jul :psyduck:

Me he vuelto al bar a por el café.

Dándole algunas vueltas, si no recuerdo mal una de las mayores putadas a nivel enterprise fue entornos Azure. No sé si esto es extrapolable a otras tecnologías de virtualización o contenedores, pero me quiere sonar que docker internamente genera diferentes capas según los pasos definidos en su Dockerfile (a coste de algo de rendimiento).

¿Igual en arquitecturas similares se podría convertir este tipo de updates en una capa propia a la que poder hacer rollback?

1 respuesta

GaN2 #57431 20 Jul Inocente

#57430 Los contenedores en docker no tienen acceso al kernel del sistema operativo donde corren. El problema es que el agente de CrowdStrike, como muchos otros agentes de monitorización, antivirus, alerta de amenazas, etc. requiren acceso como super usuario ademas de acceso a nivel de kernel en algunos casos.

1

B

[Borrado] #57432 20 Jul

#57421 Si en 15 mins no restauras un servidor es que lo tienes mal montado y me puedes decir misa... que yo trabajo de eso, he montado toda la infraestrucura de la empresa y te recupero un servidor en 15 mins. No tengo capas de mierda y mierda metidas en mi servidor... Si se hizo en una actualización automática, se hace a un ahora que coincide justo despues de u backup. ¿Se rompe? Restauro... habrá servidores ultra tochos de la hostia que se van a ese 10%.

Hablo desde mi mundo, linux... de windows no tengo ni puta idea.

EDIT:
Para aprovisionar servidor y desplegar todos los servicios: poetry run ansible-playbook node.yml .... listo... ya está todo levantado y funcionando.
Para restaurar todos los servicios: poetry run ansible-playbook recovery.yml .... listo... ya está todo recuperado.

** Obviamente todo se puede hacer a más grano fino... pero a grandes rasgos ese sería mi gran proceso de mover un servidor a otro lado.

1 respuesta

GaN2 #57433 20 Jul Inocente

#57432 en mi homelab también te restauró todo en 15 minutos, lo cual no implica que mi situación sea adaptable a empresas grandes. La restauración del disco de boot la puedes hacer en 15 minutos si el disco no es grande y tu herramienta te da la opción de desmontar el disco, restaurarlo y volverlo a montar. O si tienes snapshots y restauras desde el mismo (y con toda seguridad tendrás pérdida de dato). El problema es la restauración end to end, el proceso completo no lo haces en 15 minutos en una empresa medianamente grande ni de coña.

Viendo tu Edit entiendo que tienes un playbook en Ansible y lo que haces es desplegar otro servidos y restaurar ficheros, es así??

1 respuesta

Slowbro #57434 20 Jul

#57429 En mi cabeza se ejecutaría en la segunda fase de un bootloader, tener algún registro de drivers validos en el rootfs y una copia/overlay del equivalente a los /lib/modules que han sido cargados en el arranque previo y el sistema a sobrevivido para contarlo. Cada instalación/carga de un driver nuevo está en candidate hasta que la próxima secuencia de arranque lo marque como valid. Si la primera ejecución de un driver en candidate casca, se marca como tainted y se logea en sistema. Sería opt-in para casos de uso donde tenga sentido.

Es algo muy parecido a las cosas que se hacen en sistemas que se actualizan por OTA, no?

1 respuesta

vincen #57435 20 Jul Inocente

Joder

vincen #57436 20 Jul Inocente

Alonso no tenia 1 juego mas? Aun quedan 2 minitos

:Edit aqui no va JAJAJA

B

[Borrado] #57437 20 Jul

#57433 Si, mi sistema se basa en contenedores... puedo moverlos de un lado a otro y tener el sistema base preparado como quiero. Existe una capa de seguridad que yo no controlo (pfsense, snort, ...). Lo que es restaurar, es en el 99% de los servicios, mover la base de datos.

En caso de que el fallo ocurriese en un tiempo no optimo (un backup hecho hace horas), es tan sencillo como montar el disco en la nueva maquina, lanzar backup... y restaurar en la nueva maquina (se complica un poco más... e igual de 15 mins pasamos a 30).

En otro orden de cosas...

1 1 respuesta

GaN2 #57438 20 Jul Inocente

#57434 el bootloader no tiene acceso a los libs/módulos del sistema operativo, una vez que Grub sabe que sistema operativo tiene que cargar lo que hace es cargar el kernel en memoria y le da control del resto del proceso de arranque. Por eso actualmente no puedes poner los chequeos en ese lado.

Extiende esto al resto de pasos, el paso anterior no tiene porque tener acceso necesariamente a los ficheros de configuración del paso siguiente y los chequeos como tal ocurren durante la ejecución del último en cada paso. La única opción de comprobar que la configuración es correcta es básicamente intentar hacer un inicio completo y en cada paso que falle devolver al comienzo el proceso de arranque para que empiece de cero con la configuración correcta de cada paso.

La otra opción es que cada paso sea capaz de recuperar una configuración correcta de sí mismo en caso de que la última falles lo cual no es buena idea por temas de consistencia.

Todo esto desde la barra del bar

1 1 respuesta

Kaledros #57439 20 Jul

#57437 Rust lleva un tiempo en el kernel y cada vez va metiendo más la patita.

zombietoads #57440 20 Jul Orca Asesina

#57408 No.

Soltrac #57441 20 Jul MV Wizard

#57413 esta frase me la esperaba en un medio generalista que no tiene ni idea de nada.

Leerlo aquí hace llorar al niño Jesús.

1 1 respuesta

Slowbro #57442 20 Jul

#57438GaN2:
el bootloader no tiene acceso a los libs/módulos del sistema operativo, una vez que Grub sabe que sistema operativo tiene que cargar lo que hace es cargar el kernel en memoria y le da control del resto del proceso de arranque. Por eso actualmente no puedes poner los chequeos en ese lado.

Que yo sepa un bootloader puede leer y escribir prácticamente donde quiera, así que con un poco de gestión de particiones no veo porqué no se podrían sobrescribir los módulos que han cascado con los marcados como validos. Ojo, que no digo que sea una buena idea, ni como se podría implementar decentemente, ni cuantos agujeros de seguridad abres; pero no me parece inviable.

Y bueno, no haría falta revisar cada paso del arranque. Si no te has cargado el kernel y los módulos están bien, el sistema debería llegar hasta init, no? Aunque haya funcionalidades que petardeen.

2 respuestas

r2d2rigo #57443 21 Jul Inocente

#57442 de toda la vida de dios un bootloader es lo minimo necesario para darle el control al kernel, si a partir de ahora un bootloader va a ser un monstruo de tropomil megas redundantes para hacer lo que tu dices, apaga y vamonos.

1 respuesta

GaN2 #57444 21 Jul Inocente

#57442 A ver que el bootloader se almacena en la MBR y tiene un tamaño de 512 bytes, tampoco le pidamos peras al olmo... Y de esos 512 bytes el bootloader solo usa 440 bytes aproximadamente:

Y bueno, no haría falta revisar cada paso del arranque. Si no te has cargado el kernel y los módulos están bien, el sistema debería llegar hasta init, no? Aunque haya funcionalidades que petardeen.

No necesariamente, durante el init puedes tener un kernel panic y a tomar por culo el arranque.

Que no digo que la idea sea inviable, lo que digo es que con el paradigma actual no se puede hacer sin tener que rediseñar el proceso de arranque de arriba a abajo.

2 respuestas

B

[Borrado] #57445 21 Jul

#57444 Con UEFI-GPT se tiene más cancha... ya va todo en la partición ESP ... pero vamos, ni idea de que se podría o no hacer... me imagino que siempre habrá un punto de ruptura y/o de mantener las cosas bien. Tener un software que en base a una lista de firmas me dice que todo está OK... ahora tengo que proteger esa lista... y me sacan un software que me comprueba que esa lista es chachi piruli, incluso la mejoran... y vuelta a empezar xD

2 respuestas

Runig666 #57446 21 Jul 2 Fast 2 Ralli

Que digo yo...igual, solo igual...la solución es no ser gilipollas y no subir un fichero todo a 0 a las malas y forzar a todo cristo a actualizarse tanto si te gusta, como si no.

La burrada que ha pasado es de saltarse controles como churros y ya veremos al final de donde ha salido esto, porque a más cosas salen, mas parece algo de una empresa con un junior montando todo con puede y bastante si tiene el código subido correctamente.

En vez de estar buscando formas de salvar un kernel panic, que llevamos ya unos cuantos años sin que sea norma, pues igual lo mejor es revisar bien quien tiene acceso a meter mano hasta la cocina. Tocas kernel, te jodes bailas y haces un trabajo lo más perfecto posible porque estás trabajado con mierda delicada.

Lo que más me quedo claro en cuanto a seguridad informática es que da igual cuantos parches pongas, cuantas medidas pongas y cuantas redundancias pocas...siempre te ganará la maldad o la estupidez humana, y siempre será la contraria de la que crees

Hasta el peor de los servers solo por tener Windows o Linux tienen más opciones de resurrección que un Mac o Android...y justamente esos dos se quedan como buenos ladrillos a la mínima que les da un aire rarito en una actualización.

(Hablando de recuperación con datos...que ya sabemos todos la """""recuperación""""" que hace Apple con sus equipos)

1 respuesta

GaN2 #57447 21 Jul Inocente

#57445 Totalmente cierto, UEFI-GPT permite mayor tamaño para las particiones de boot.

#57446 Que tienes razón, todo esto se evitaría si CrowdStrike hubiera hecho las cosas como las tenía que hacer. Aquí simplemente estamos elucubrando sobre mecanismos para evitar este tipo de situaciones.