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

Después de leer esta pregunta sobre un compromiso del servidor , comencé a preguntarme por qué las personas continúan creyendo que pueden recuperar un sistema comprometido utilizando herramientas de detección / limpieza, o simplemente arreglando el agujero que se utilizó para comprometer el sistema.

Dadas todas las diversas tecnologías del kit raíz y otras cosas que un hacker puede hacer, la mayoría de los expertos sugieren que debe reinstalar el sistema operativo .

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

Aquí hay un par de puntos que me gustaría ver abordados.

• ¿Existen condiciones en las que un formato / reinstalación no limpiaría el sistema?
• ¿En qué tipo de condiciones cree que se puede limpiar un sistema y cuándo debe realizar una reinstalación completa?
• ¿Qué razonamiento tiene contra hacer una reinstalación completa?
• Si elige no volver a instalar, entonces, ¿qué método utiliza para estar razonablemente seguro de que ha limpiado y evitado que ocurran daños adicionales nuevamente?

Una decisión de seguridad es, en última instancia, una decisión comercial 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 considera estrictamente desde una perspectiva técnica, no lo hace.

Esto es lo que generalmente entra en 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 a los clientes un poco sobre por qué estábamos deprimidos?
• ¿De qué otras actividades tendré que alejar a las personas para que realicen la reinstalación? ¿Cuánto cuesta?
• ¿Tenemos las personas adecuadas que saben cómo abrir el sistema sin error? Si no es así, ¿cuánto me va a costar para solucionar los 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.

Basado en una publicación que escribí hace mucho tiempo atrás, cuando todavía podía molestarme en blog.

Esta pregunta sigue siendo formulada repetidamente por las víctimas de los piratas informáticos que irrumpieron en 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 al buscar ayuda, o no pueden encontrar a alguien en quien confíen para que les dé consejos. O tal vez las personas leen una respuesta a esta pregunta y se centran demasiado en el 5% de por qué su caso es especial y diferente de las respuestas que pueden encontrar en línea y pierden el 95% de la pregunta y responden cuando su caso es lo suficientemente similar 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, su arduo trabajo en nombre de un empleador. Pero para alguien en el exterior que mira hacia adentro, ya sea una persona de seguridad informática que busca el problema para tratar de ayudarlo o incluso al atacante mismo, es muy probable que su problema sea al menos 95% idéntico a cualquier otro caso alguna vez mirado.

No tome el ataque personalmente, y no tome las recomendaciones que siguen aquí o que reciba personalmente de otras personas. Si está leyendo esto después de ser víctima de un hack de un sitio web, lo siento mucho y realmente espero que pueda encontrar algo útil aquí, pero este no es el momento para permitir que su ego se interponga en lo que necesita. hacer.

Acabas de descubrir que tus servidores fueron pirateados. ¿Ahora que?

No te asustes. Absolutamente no actúes apresuradamente, y absolutamente no intentes fingir que las cosas nunca sucedieron y no actúes en absoluto.

Primero: entienda que el desastre ya ha sucedido. Este no es el momento para la negación; Es el momento de aceptar lo que sucedió, de ser realista al respecto y de tomar medidas para manejar 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. El medicamento puede tener un sabor horrible, pero a veces tienes que pasarlo por alto si realmente quieres que funcione la cura.

Evite que el problema empeore de lo que ya es:

1. Lo primero que debe hacer es desconectar los sistemas afectados de Internet. Cualesquiera otros problemas que tenga, dejar el sistema conectado a la web solo permitirá que el ataque continúe. Me refiero a esto literalmente; haga que alguien visite físicamente el servidor y desconecte los cables de red si eso es lo que se necesita, pero desconecte a la víctima de sus asaltantes antes de intentar hacer 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í, tienes razón, esto podría ser excesivo; por otro lado, podría no serlo. No sabes de ninguna manera, ¿verdad?
3. Verifica tus otros sistemas. Preste especial atención a otros servicios de Internet y a aquellos que contienen datos financieros u otros datos comerciales sensibles.
4. Si el sistema contiene los datos personales de alguien, haga una revelación completa y franca a cualquier persona potencialmente afectada a la vez. Sé que este es duro. Sé que este 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 eso.

¿Todavía dudando en dar este último paso? Entiendo, lo hago. Pero míralo así:

En algunos lugares, es posible que tenga un requisito legal para informar a las autoridades y / o las víctimas de este tipo de violación de la privacidad. Por más molestos que estén tus clientes por que les cuentes un problema, estarán mucho más molestos si no les cuentas, y solo se enteran por sí mismos después de que alguien cobra $ 8,000 en bienes utilizando los datos de la tarjeta de crédito robado de su sitio.

¿Recuerdas lo que dije anteriormente? Lo malo ya ha sucedido . La única pregunta ahora es qué tan bien lo manejas.

Comprende el problema completamente:

1. NO vuelva a poner en línea los sistemas afectados hasta que esta etapa esté completamente completa, a menos que quiera ser la persona cuya publicación fue el punto de inflexión para que yo realmente decida escribir este artículo. No estoy enlazando a la publicación para que la gente pueda reírse de forma barata; Me conecto para advertirle 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 para averiguar de dónde "vinieron" los ataques, de modo que entienda qué problemas tiene y necesita abordar para que su sistema sea seguro en el futuro.
3. Examine los sistemas 'atacados' nuevamente, esta vez para comprender a dónde fueron los ataques, para que entienda qué sistemas se vieron comprometidos en el ataque. Asegúrese de seguir cualquier indicador 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 entiendan completamente, para que pueda comenzar a cerrarlas correctamente. (p. ej., 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 en particular por la que entraron, también querría auditar todo su código para ver si el mismo tipo de error fue hecho 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 unir 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 ejecuta 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 a los hackers les gusta llamarlo: "otro día en la oficina aprovechando los errores comunes que cometen las personas".

Haga un plan de recuperación y vuelva a poner en línea su sitio web y sígalo:

Nadie quiere estar desconectado por más tiempo del que tiene que estar. Eso es un hecho. Si este sitio web es un mecanismo generador de ingresos, la presión para volver a ponerlo en línea rápidamente será intensa. Incluso si lo único que está en juego es la reputación de su empresa, esto generará mucha presión para que las cosas vuelvan a funcionar rápidamente.

Sin embargo, no cedas a la tentación de volver a conectarte 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, seguramente será víctima de una intrusión una vez más, y recuerde, "ser pirateado una vez puede clasificarse como una desgracia; ser pirateado nuevamente inmediatamente después parece descuido "(con disculpas a Oscar Wilde).

1. Supongo que has 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 has hecho primero, entonces realmente necesitas hacerlo. Lo siento.
2. Nunca pague chantaje / dinero de protección. Este es el signo de una marca fácil y no desea que esa frase se use para describirlo.
3. No caiga en la tentación de volver a poner en línea los mismos servidores 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 realizar una instalación limpia" en el hardware antiguo de lo que sería auditar cada esquina del sistema antiguo para asegurarse de que esté limpio antes de volver a colocarlo en línea de nuevo. Si no está de acuerdo con eso, entonces 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. Presumiblemente tiene copias de seguridad y despliegues de prueba de su sitio que puede usar para construir el sitio en vivo, y si no lo hace, entonces ser pirateado no es su mayor problema.
4. Tenga mucho cuidado con la reutilización de datos que estaban "en vivo" en el sistema en el momento del hack. 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, debe restaurar esto desde una copia de seguridad realizada antes de la intrusión. Si no puede o no quiere hacer eso, debe tener mucho cuidado con esa información porque está contaminada. Debe tener especialmente en cuenta las consecuencias para los demás si estos datos pertenecen a clientes o visitantes del sitio y no directamente a usted.
5. Monitoree los sistemas con cuidado. Debe resolver hacer esto como un proceso continuo en el futuro (más abajo) pero se esfuerza más para estar atento durante el período inmediatamente posterior a que su sitio vuelva a estar en línea. Es casi seguro que los intrusos volverán, y si puedes verlos intentando entrar nuevamente, podrás ver rápidamente si realmente has cerrado todos los agujeros que usaron antes, además de los que hicieron por sí mismos, y podrías obtener información útil. información que puede transmitir a la policía local.

Reduciendo 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 con conexión a Internet, no es algo que luego pueda aplicar algunas capas sobre su código como algo barato. pintar. Para que sea seguro, 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 has escuchado todo antes y que "simplemente no me doy cuenta de la presión" de poner tu servicio beta web2.0 (beta) en estado beta en la web, pero el hecho es que esto mantiene repitiéndose porque era cierto la primera vez que se dijo y aún no se ha convertido en una mentira.

No puedes 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 como la probabilidad de que ocurra.

¿Qué pasos puedes tomar para reducir la probabilidad de que un ataque sea exitoso?

Por ejemplo:

1. ¿Fue la falla que permitió a las personas ingresar a su sitio un error conocido en el código del proveedor, para el cual había un parche disponible? Si es así, ¿necesita repensar su enfoque sobre cómo parchear aplicaciones en sus servidores con conexión a Internet?
2. ¿Era la falla que permitía a las personas entrar en 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 lo muerde porque todos tienen sus problemas y se quedará sin plataformas en un año como máximo si adopta este enfoque. Sin embargo, si un sistema te decepciona constantemente, entonces debes migrar a algo más robusto o, como mínimo, rediseñar tu 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 repensar su enfoque sobre cómo aprueba el código para la implementación en su sitio en vivo? Si el error se detecta 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 utilizando técnicas de codificación bien documentadas )
4. ¿La falla se debió a un problema con la forma en que se implementó el servidor o el software de la aplicación? Si es así, ¿está utilizando procedimientos automatizados para construir e implementar servidores cuando sea posible? Estas son una gran ayuda para mantener un estado de "línea de base" consistente en todos sus servidores, minimizando la cantidad de trabajo personalizado que se debe hacer en cada uno y, por lo tanto, minimizando la oportunidad de cometer un error. Lo mismo ocurre con la implementación de código: si necesita hacer algo "especial" para implementar la última versión de su aplicación web, intente automatizarla y asegúrese de que siempre se realice 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 de Internet y alertarlo en caso de un problema. Podrías decidir que no puedes pagar esto o no lo necesitas y eso está bien ... solo tenlo en cuenta.
6. Use herramientas como tripwire y nessus cuando corresponda, pero no las use solo a ciegas porque se 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 úselas regularmente.
7. Considere contratar expertos en seguridad para 'auditar' la seguridad de su sitio web de forma regular. Una vez más, puede decidir que no puede permitirse esto o no lo necesita y eso está bien ... solo tómelo en consideración.

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

Si decide que el "riesgo" de la inundación del piso inferior de su casa es alto, pero no lo suficientemente alto como para justificar el traslado, al menos debe trasladar las reliquias familiares insustituibles al piso de arriba. ¿Derecho?

1. ¿Se puede reducir la cantidad de servicios directamente expuestos a Internet? ¿Puede mantener algún tipo de brecha entre sus servicios internos y sus servicios orientados a Internet? Esto garantiza que incluso si sus sistemas externos están comprometidos, las posibilidades de usar esto como 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 las personas no pueden robarle información que no tiene, y el segundo punto es que cuanto menos almacene, menos necesita mantener y codificar, por lo que hay menos posibilidades de que los errores se escapen su código o diseño de sistemas.
3. ¿Está utilizando 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 dar servicio solo tenga acceso de lectura, no permita el acceso de escritura y ciertamente no el acceso a nivel del sistema.
4. Si no tiene mucha experiencia en algo y no es fundamental para su negocio, considere la posibilidad de externalizarlo. En otras palabras, si ejecuta un sitio web pequeño hablando de escribir código de aplicación de escritorio y decide comenzar a vender pequeñas aplicaciones de escritorio del sitio, entonces considere "externalizar" su sistema de pedido de tarjeta de crédito a alguien como Paypal.
5. Si es posible, haga que la recuperación práctica de sistemas comprometidos sea parte de su plan de recuperación ante desastres. Podría decirse que se trata simplemente de otro "escenario de desastre" que podría encontrar, simplemente uno con su propio conjunto de problemas y cuestiones que son distintas de la habitual 'sala de servidores incendiada' / 'fue invadida por el tipo de cosas de servidores gigantes que se alimentan de perturbaciones. (editar, por XTZ)

... Y finalmente

Probablemente he dejado de lado un sinfín 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 piratas informáticos.

Sobre todo: no se asuste. 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.

Siempre atáquelo desde la órbita. Es la única forma de estar seguro.

_{(fuente: flickr.com )}

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

No puedes confiar en eso. No te molestes con la limpieza. Desconecte y aísle la máquina de inmediato. Comprenda la naturaleza de la violación antes de continuar, de lo contrario, invitará a lo mismo nuevamente. Intente, si es posible, obtener la fecha y hora de la infracción, de modo que tenga 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.

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

Dicho esto, en los 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), haber hecho una limpieza sin reinstalar sin sentirme demasiado culpable.

Lo más probable es que no tengan una rutina de recuperación de desastres que se haya probado lo suficiente como para sentirse seguros de hacer 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 riesgo No entiendo el alcance de un sistema comprometido. Se me ocurren muchas razones.

Yo diría que es algo que está mal en las rutinas y políticas básicas y que no es algo que desearía admitir abiertamente, sino que adopta una postura defensiva. Al menos no puedo ver ni defender no borrar un sistema comprometido sin importar el ángulo que lo mires.

Anteriormente no he eliminado el sistema para poder hacer un análisis del vector en el que se encontraron y el posterior análisis del uso y ver dónde llegaron al interior.

Una vez que haya 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 condiciones de poder obtener un sistema limpio en espera activa y poder ofrecer una seguridad de red mejorada rápida para aislar la caja rooteada.