it-swarm-es.com

¿Reinstalar después de un compromiso de raíz?

Después de leer esta pregunta sobre el compromiso de un servidor , comencé a preguntarme por qué la gente sigue creyendo que pueden recuperar un sistema comprometido usando herramientas de detección/limpieza, o simplemente arreglando el agujero que solía hacer comprometer el sistema.

Dadas todas las diversas tecnologías de rootkits y otras cosas que un pirata informático puede hacer, la mayoría de los expertos sugieren que debería reinstalar el sistema operativo .

Espero tener una mejor idea de por qué más personas no simplemente despegan y nuclear el sistema desde la órbita.

Aquí hay un par de puntos que me gustaría que se abordaran.

  • ¿Existen condiciones en las que un formateo/reinstalación no limpiaría el sistema?
  • ¿En qué tipos de condiciones cree que se puede limpiar un sistema y cuándo debe realizar una reinstalación completa?
  • ¿Qué razonamiento tiene en contra de realizar una reinstalación completa?
  • Si opta por no volver a instalarlo, ¿qué método utiliza para estar razonablemente seguro de que ha limpiado y evitado que se produzcan más daños?.
58
Zoredache

Una decisión de seguridad es, en última instancia, una decisión empresarial sobre el riesgo, al igual que una decisión sobre qué producto llevar al mercado. Cuando lo enmarca en ese contexto, la decisión de no nivelar y reinstalar tiene sentido. Cuando lo consideras estrictamente desde una perspectiva técnica, no es así.

Esto es lo que normalmente implica esa decisión comercial:

  • ¿Cuánto nos costará nuestro tiempo de inactividad en una cantidad mensurable?
  • ¿Cuánto nos costará potencialmente cuando tengamos que revelar un poco a los clientes por qué estábamos deprimidos?
  • ¿De qué otras actividades tendré que alejar a las personas para realizar la reinstalación? ¿Cuánto cuesta?
  • ¿Contamos con las personas adecuadas que sepan cómo hacer que el sistema aparezca sin errores? Si no es así, ¿cuánto me va a costar si solucionan errores?

Y por lo tanto, cuando suma los costos como esos, se puede considerar que continuar con un sistema "potencialmente" aún comprometido es mejor que reinstalar el sistema.

31
K. Brian Kelley

Basado en una publicación que escribí hace años cuando todavía podía molestarme en escribir un blog.

Esta pregunta sigue siendo formulada repetidamente por las víctimas de los piratas informáticos que ingresan a su servidor web. Las respuestas rara vez cambian, pero la gente sigue haciendo la pregunta. No estoy seguro de por qué. Quizás a las personas simplemente no les gustan las respuestas que han visto cuando buscan ayuda, o no pueden encontrar a alguien en quien confíen para que les dé un consejo. O quizás las personas leen una respuesta a esta pregunta y se enfocan demasiado en el 5% de por qué su caso es especial y diferente de las respuestas que pueden encontrar en línea y se pierden el 95% de la pregunta y la respuesta cuando su caso es lo suficientemente parecido como el que leen en línea.

Eso me lleva a la primera pepita importante de información. Realmente aprecio que seas un copo de nieve único y especial. Aprecio que su sitio web también lo sea, ya que es un reflejo de usted y su negocio o, al menos, de su arduo trabajo en nombre de un empleador. Pero para alguien desde afuera que mira hacia adentro, ya sea una persona de seguridad informática que está mirando el problema para tratar de ayudarlo o incluso el propio atacante, es muy probable que su problema sea al menos un 95% idéntico a todos los demás casos que hayan tenido. alguna vez mirado.

No tome el ataque como algo personal, y no tome las recomendaciones que siguen aquí o que reciba de otras personas personalmente. Si estás leyendo esto después de convertirte en víctima de un hackeo de un sitio web, lo siento mucho, y realmente espero que puedas encontrar algo útil aquí, pero este no es el momento para dejar que tu ego se interponga en lo que necesitas. hacer.

Acaba de descubrir que sus servidores fueron pirateados. ¿Y ahora qué?

No entrar en pánico. Absolutamente no actúes con prisa, y absolutamente no intentes y finjas que las cosas nunca sucedieron y no actúes en absoluto.

Primero: comprenda que el desastre ya ocurrió. Este no es el momento de la negación; es el momento de aceptar lo sucedido, ser realistas y tomar medidas para gestionar las consecuencias del impacto.

Algunos de estos pasos van a doler, y (a menos que su sitio web tenga una copia de mis datos) realmente no me importa si ignora todos o algunos de estos pasos, pero hacerlo mejorará las cosas al final. La medicina puede tener un sabor horrible, pero a veces tienes que pasarlo por alto si realmente quieres que la cura funcione.

Evite que el problema se vuelva peor de lo que ya es:

  1. Lo primero que debe hacer es desconectar los sistemas afectados de Internet. Independientemente de los otros problemas que tenga, dejar el sistema conectado a la web solo permitirá que el ataque continúe. Me refiero a esto bastante literalmente; Consiga que alguien visite físicamente el servidor y desconecte los cables de red si eso es lo que hace falta, pero desconecte a la víctima de sus asaltantes antes de intentar hacer cualquier otra cosa.
  2. Cambie todas sus contraseñas para todas las cuentas en todas las computadoras que están en la misma red que los sistemas comprometidos. No realmente. Todas las cuentas. Todas las computadoras. Sí, tiene razón, esto podría ser excesivo; por otro lado, puede que no. No sabes de ninguna manera, ¿verdad?
  3. Verifique sus otros sistemas. Preste especial atención a otros servicios de Internet y a aquellos que contienen datos financieros o comercialmente sensibles.
  4. Si el sistema contiene los datos personales de alguien, haga una divulgación completa y franca a cualquier persona potencialmente afectada de inmediato. Sé que este es duro. Sé que este te va a doler. Sé que muchas empresas quieren barrer este tipo de problema debajo de la alfombra, pero me temo que tendrás que lidiar con él.

¿Sigues dudando en dar este último paso? Lo entiendo, lo hago. Pero míralo así:

En algunos lugares, es posible que tenga la obligación legal de informar a las autoridades y/o las víctimas de este tipo de violación de la privacidad. Sin importar cuán molestos puedan estar sus clientes de que usted les cuente sobre un problema, se molestarán mucho más si no se lo dice, y solo se enterarán por sí mismos después de que alguien cobra $ 8,000 en bienes usando los detalles de la tarjeta de crédito que robado de su sitio.

¿Recuerdas lo que dije anteriormente? Lo malo ya pasó . La única pregunta ahora es qué tan bien lo maneja.

Comprender el problema completamente:

  1. NO vuelva a poner los sistemas afectados en línea hasta que esta etapa esté completamente completa, a menos que desee ser la persona cuya publicación fue el punto de inflexión para que yo decidiera escribir este artículo. No voy a vincular la publicación para que la gente se ría barata; Te estoy enlazando para advertirte de las consecuencias de no seguir este primer paso.
  2. Examine los sistemas 'atacados' para comprender cómo los ataques lograron comprometer su seguridad. Haga todo lo posible por averiguar de dónde "provienen" los ataques, de modo que comprenda qué problemas tiene y necesita abordar para que su sistema sea seguro en el futuro.
  3. Examine de nuevo los sistemas 'atacados', esta vez para comprender dónde fueron los ataques, de modo que pueda comprender qué sistemas se vieron comprometidos en el ataque. Asegúrese de seguir cualquier consejo que sugiera que los sistemas comprometidos podrían convertirse en un trampolín para atacar aún más sus sistemas.
  4. Asegúrese de que las "puertas de enlace" utilizadas en todos y cada uno de los ataques se comprendan completamente, de modo que pueda comenzar a cerrarlas correctamente. (por ejemplo, si sus sistemas se vieron comprometidos por un ataque de inyección SQL, entonces no solo necesita cerrar la línea de código defectuosa particular por la que ingresaron, sino que también querrá auditar todo su código para ver si el mismo tipo de error se hizo en otro lugar).
  5. Comprenda que los ataques pueden tener éxito debido a más de un defecto. A menudo, los ataques tienen éxito no al encontrar un error importante en un sistema, sino al juntar varios problemas (a veces menores y triviales por sí mismos) para comprometer un sistema. Por ejemplo, al usar ataques de inyección SQL para enviar comandos a un servidor de base de datos, descubrir que el sitio web/aplicación que está atacando se está ejecutando en el contexto de un usuario administrativo y usar los derechos de esa cuenta como un trampolín para comprometer otras partes de un sistema. O como les gusta llamar a los hackers: "otro día en la oficina aprovechando los errores comunes que comete la gente".

Haga un plan de recuperación y vuelva a poner su sitio web en línea y cúmplalo:

Nadie quiere estar desconectado por más tiempo del necesario. Eso es un hecho. Si este sitio web es un mecanismo de generación de ingresos, la presión para que vuelva a estar en línea rápidamente será intensa. Incluso si lo único en juego es la reputación de usted o de su empresa, esto seguirá generando mucha presión para volver a poner las cosas rápidamente.

Sin embargo, no ceda a la tentación de volver a conectarse demasiado rápido. En lugar de eso, muévase lo más rápido posible para comprender qué causó el problema y resolverlo antes de volver a conectarse o, de lo contrario, es casi seguro que volverá a ser víctima de una intrusión, y recuerde, "ser pirateado una vez puede considerarse una desgracia; volver a ser pirateado inmediatamente después parece un descuido "(con disculpas a Oscar Wilde).

  1. Supongo que ha entendido todos los problemas que llevaron a la intrusión exitosa en primer lugar incluso antes de comenzar esta sección. No quiero exagerar el caso, pero si no lo ha hecho primero, entonces realmente lo necesita. Lo siento.
  2. Nunca pague dinero por chantaje/protección. Este es el signo de una marca fácil y no querrás que esa frase se use para describirte.
  3. ¡No se sienta tentado a volver a poner los mismos servidores en línea sin una reconstrucción completa Debería ser mucho más rápido construir una nueva caja o "destruir el servidor desde la órbita y hacer una limpieza instalar "en el hardware antiguo de lo que sería auditar cada rincón del sistema antiguo para asegurarse de que esté limpio antes de volver a ponerlo en línea. Si no está de acuerdo con eso, probablemente no sepa lo que realmente significa asegurarse de que un sistema esté completamente limpio, o los procedimientos de implementación de su sitio web son un desastre profano. Es de suponer que tiene copias de seguridad e implementaciones de prueba de su sitio que puede usar para construir el sitio en vivo, y si no lo hace, el problema no es ser pirateado.
  4. Tenga mucho cuidado con la reutilización de datos que estaban "activos" en el sistema en el momento del ataque. No diré "nunca lo hagas" porque simplemente me ignorarás, pero, francamente, creo que debes considerar las consecuencias de mantener los datos cuando sabes que no puedes garantizar su integridad. Idealmente, debería restaurar esto a partir de una copia de seguridad realizada antes de la intrusión. Si no puede o no quiere hacer eso, debe tener mucho cuidado con esos datos porque están contaminados. Especialmente debe ser consciente de las consecuencias para los demás si estos datos pertenecen a clientes o visitantes del sitio y no directamente a usted.
  5. Supervise los sistemas con atención. Debería decidir hacer esto como un proceso continuo en el futuro (más abajo) pero se esfuerza más por estar alerta durante el período inmediatamente posterior a que su sitio vuelva a estar en línea. Es casi seguro que los intrusos regresarán, y si puede verlos tratando de entrar de nuevo, seguramente podrá ver rápidamente si realmente ha cerrado todos los agujeros que usaron antes, además de los que ellos mismos hicieron, y podría obtener información útil. información que puede transmitir a la policía local.

Reducir el riesgo en el futuro.

Lo primero que debe comprender es que la seguridad es un proceso que debe aplicar durante todo el ciclo de vida del diseño, la implementación y el mantenimiento de un sistema orientado a Internet, no algo que pueda colocar con algunas capas sobre su código después como si fuera barato. Pintar. Para ser adecuadamente seguros, un servicio y una aplicación deben diseñarse desde el principio teniendo esto en cuenta como uno de los principales objetivos del proyecto. Me doy cuenta de que es aburrido y lo ha escuchado todo antes y que "simplemente no me doy cuenta de la presión" de hacer que su servicio beta web2.0 (beta) pase al estado beta en la web, pero el hecho es que esto mantiene repetirse porque era verdad la primera vez que se dijo y aún no se ha convertido en mentira.

No se puede eliminar el riesgo. Ni siquiera deberías intentar hacer eso. Sin embargo, lo que debe hacer es comprender qué riesgos de seguridad son importantes para usted y comprender cómo administrar y reducir tanto el impacto del riesgo y la probabilidad de que ocurra el riesgo.

¿Qué pasos puede tomar para reducir la probabilidad de que un ataque tenga éxito?

Por ejemplo:

  1. ¿La falla que permitió a las personas ingresar a su sitio fue un error conocido en el código del proveedor, para el cual había un parche disponible? Si es así, ¿necesita reconsiderar su enfoque sobre cómo parchear aplicaciones en sus servidores conectados a Internet?
  2. ¿Fue la falla que permitió a las personas ingresar a su sitio un error desconocido en el código del proveedor, para el cual no había un parche disponible? Ciertamente no recomiendo cambiar de proveedor cada vez que algo como esto te muerde porque todos tienen sus problemas y te quedarás sin plataformas en un año como máximo si adoptas este enfoque. Sin embargo, si un sistema lo decepciona constantemente, entonces debe migrar a algo más robusto o, al menos, rediseñar su sistema para que los componentes vulnerables permanezcan envueltos en algodón y lo más lejos posible de los ojos hostiles.
  3. ¿Fue la falla un error en el código desarrollado por usted (o un contratista que trabaja para usted)? Si es así, ¿necesita reconsiderar su enfoque sobre cómo aprueba el código para la implementación en su sitio en vivo? ¿Podría haberse detectado el error con un sistema de prueba mejorado o con cambios en su "estándar" de codificación (por ejemplo, si bien la tecnología no es una panacea, puede reducir la probabilidad de un ataque de inyección SQL exitoso usando técnicas de codificación bien documentadas ).
  4. ¿El defecto se debió a un problema con la forma en que se implementó el servidor o el software de la aplicación? Si es así, ¿utiliza procedimientos automatizados para crear e implementar servidores donde sea posible? Estos son de gran ayuda para mantener un estado de "línea base" consistente en todos sus servidores, minimizando la cantidad de trabajo personalizado que debe realizarse en cada uno y, por lo tanto, con suerte, minimizando la oportunidad de cometer un error. Lo mismo ocurre con la implementación de código: si necesita que se haga algo "especial" para implementar la última versión de su aplicación web, intente automatizarla y asegúrese de que siempre se haga de manera coherente.
  5. ¿Podría haberse detectado la intrusión antes con una mejor supervisión de sus sistemas? Por supuesto, el monitoreo de 24 horas o un sistema "de guardia" para su personal puede no ser rentable, pero hay compañías que pueden monitorear sus servicios web por usted y alertarlo en caso de un problema. Puede decidir que no puede pagar esto o que no lo necesita y está bien ... solo téngalo en consideración.
  6. Use herramientas como tripwire y nessus cuando sea apropiado, pero no las use a ciegas porque yo lo dije. Tómese el tiempo para aprender a usar algunas buenas herramientas de seguridad que sean apropiadas para su entorno, mantenga estas herramientas actualizadas y utilícelas con regularidad.
  7. Considere contratar expertos en seguridad para "auditar" la seguridad de su sitio web de forma regular. Nuevamente, puede decidir que no puede pagar esto o que no lo necesita y está bien ... solo téngalo en cuenta.

¿Qué pasos puede tomar para reducir las consecuencias de un ataque exitoso?

Si decide que el "riesgo" de que se inunde el piso inferior de su casa es alto, pero no lo suficientemente alto como para justificar la mudanza, al menos debe mover las reliquias familiares irremplazables arriba. ¿Correcto?

  1. ¿Puede reducir la cantidad de servicios expuestos directamente a Internet? ¿Puede mantener algún tipo de brecha entre sus servicios internos y sus servicios orientados a Internet? Esto asegura que incluso si sus sistemas externos están comprometidos, las posibilidades de usar esto como un trampolín para atacar sus sistemas internos son limitadas.
  2. ¿Está almacenando información que no necesita almacenar? ¿Está almacenando dicha información "en línea" cuando podría archivarse en otro lugar? Hay dos puntos en esta parte; la obvia es que la gente no puede robarle información que usted no tiene, y el segundo punto es que cuanto menos almacene, menos tendrá que mantener y codificar, por lo que hay menos posibilidades de que se introduzcan errores su código o diseño de sistemas.
  3. ¿Utiliza los principios de "acceso mínimo" para su aplicación web? Si los usuarios solo necesitan leer desde una base de datos, asegúrese de que la cuenta que usa la aplicación web para atender esto solo tenga acceso de lectura, no le permita acceso de escritura y ciertamente no acceso a nivel de sistema.
  4. Si no tiene mucha experiencia en algo y no es fundamental para su negocio, considere subcontratarlo. En otras palabras, si tiene un sitio web pequeño que habla de escribir código de aplicación de escritorio y decide comenzar a vender pequeñas aplicaciones de escritorio desde el sitio, considere "subcontratar" su sistema de pedidos con tarjeta de crédito a alguien como Paypal.
  5. Si es posible, haga que la práctica de la recuperación de sistemas comprometidos sea parte de su plan de recuperación ante desastres. Podría decirse que este es solo otro "escenario de desastre" que podría encontrar, simplemente uno con su propio conjunto de problemas y problemas que son distintos del habitual 'sala de servidores en llamas'/'fue invadido por servidores gigantes que comen furbies'. (editar, por XTZ)

... Y finalmente

Probablemente he dejado un sin fin de cosas que otros consideran importantes, pero los pasos anteriores deberían al menos ayudarlo a comenzar a resolver las cosas si tiene la mala suerte de ser víctima de los piratas informáticos.

Sobre todo: que no cunda el pánico. Piensa antes de actuar. Actúe con firmeza una vez que haya tomado una decisión y deje un comentario a continuación si tiene algo que agregar a mi lista de pasos.

30
Rob Moir

Siempre bombardearlo desde la órbita. Es la única forma de estar seguro.

alt text
(fuente: flickr.com )

La mayoría de los sistemas son entidades holísticas que tienen una confianza interna e implícita. Confiar en un sistema comprometido es una declaración implícita de que, para empezar, confía en quienquiera que cometió la violación de su sistema. En otras palabras:

No puedes confiar en él. No se moleste en limpiar. Desconecte y aísle la máquina inmediatamente. Comprenda la naturaleza de la infracción antes de continuar; de lo contrario, invitará a lo mismo de nuevo. Intente, si es posible, obtener la fecha y la hora de la infracción, para tener un marco de referencia. Necesita esto porque si restaura desde la copia de seguridad, debe asegurarse de que la copia de seguridad en sí no tenga una copia del compromiso. Limpie antes de restaurar, no tome atajos.

19
Avery Payne

Hablando en términos prácticos, la mayoría de las personas no lo hacen porque piensan que tomará demasiado tiempo o será demasiado perturbador. He advertido a innumerables clientes sobre la probabilidad de que continúen los problemas, pero una persona encargada de tomar decisiones a menudo rechaza una reinstalación por una de esas razones.

Dicho esto, en sistemas en los que estoy seguro de que conozco el método de entrada y el alcance total del daño (registros sólidos fuera de la máquina, generalmente con un IDS, tal vez SELinux o algo similar que limite el alcance de la intrusión), yo Hice una limpieza sin reinstalar sin sentirse demasiado culpable.

6
womble

Lo más probable es que no tengan una rutina de recuperación ante desastres que se haya probado lo suficiente como para que se sientan seguros al realizar una reconstrucción, o no está claro cuánto tiempo tomaría o cuál sería el impacto ... o las copias de seguridad no son confiables o sus analistas de riesgos no entiendo el alcance de un sistema comprometido. Puedo pensar en muchas razones.

Yo diría que es sobre todo algo que está mal en las rutinas y políticas básicas y que no es algo que quieras admitir abiertamente, y en su lugar adoptas una postura defensiva. Al menos no puedo ver o defenderme sin limpiar un sistema comprometido sin importar desde qué ángulo lo mires.

2
Oskar Duveborn

Previamente no he puesto bombas nucleares en el sistema para poder hacer un análisis del vector en el que entraron y un análisis posterior del uso y ver a dónde llegaron dentro.

Una vez que ha sido rooteado, tiene un honeypot en vivo y puede ofrecer mucho más que solo el truco. - especialmente para la policía.

  • dicho esto, he estado en desventaja para poder obtener un sistema limpio en espera en caliente y para poder ofrecer seguridad de red mejorada y rápida para aislar la caja rooteada.
2
littlegeek