Tire de la red o el poder? (para mantener un servidor rooteado)

Cuando un servidor se rootea ( por ejemplo, una situación como esta ), una de las primeras cosas que puede decidir hacer es la contención . Algunos especialistas en seguridad aconsejan no ingresar la remediación inmediatamente y mantener el servidor en línea hasta que se complete el análisis forense. Esos consejos son generalmente para APT . Es diferente si tiene infracciones ocasionales de script kiddie , por lo que puede decidir remediar (arreglar las cosas) antes. Uno de los pasos en la remediación es la contención del servidor. Citando la respuesta de Robert Moir : "desconecta a la víctima de sus asaltantes".

Se puede contener un servidor tirando del cable de red o del cable de alimentación .

¿Qué método es mejor?

Teniendo en cuenta la necesidad de:

1. Proteger a las víctimas de daños mayores.
2. Ejecutar forenses exitosos
3. (Posiblemente) Protección de datos valiosos en el servidor

Editar: 5 supuestos

Asumiendo:

1. Lo detectó temprano: 24 horas.
2. Desea recuperarse temprano: 3 días de 1 administrador de sistemas en el trabajo (forense y recuperación).
3. El servidor no es una máquina virtual o un contenedor capaz de tomar una instantánea capturando el contenido de la memoria del servidor.
4. Decide no intentar el enjuiciamiento.
5. Sospecha que el atacante puede estar utilizando algún tipo de software (posiblemente sofisticado) y este software todavía se está ejecutando en el servidor.

Si se enfrenta a un APT, entonces su mejor opción es configurar un honeypot e investigar a fondo todo el tráfico que fluye dentro y fuera de él, además de monitorear el servidor.

La medida de pasar por la memoria es tan costosa en términos de tiempo y esfuerzo que generalmente no vale la pena a menos que haya intentado con cualquier otro método, y si determina que vale la pena, generalmente es mejor configurar un honeypot que le permita volcar fácilmente la memoria y el estado del sistema a otra máquina sobre la marcha para que pueda hacer análisis con menos amenaza de ser detectado mientras la máquina está en funcionamiento.

Tuve una situación en la que el atacante guardaba todo en la memoria en la medida en que, excepto los registros, la máquina se veía exactamente como su imagen una vez apagada y encendida. Luego volverían a hackear y comenzarían a usarlo nuevamente porque la vulnerabilidad aún estaba allí; no necesitaban dejar puertas traseras para ellos. Una evaluación de memoria podría haber ayudado aquí, pero observar el tráfico fue suficiente en este caso para identificar la vulnerabilidad rápidamente.

Por lo tanto:

La única razón para evitar desconectar el poder y hacer una evaluación de disco fuera de línea es si vas a pasar por el dolor de hacer un análisis exhaustivo de la amenaza mientras está en su lugar y operando. Si ha llegado al punto en que esto es necesario, entonces no hay razón para desconectar ninguno de los enchufes.

Si no está haciendo un análisis de memoria, entonces su mejor opción es desconectar el cable de alimentación: extraer el ethernet (o usar un comando de apagado) solo le avisará con anticipación al software del atacante, lo cual es importante ocasionalmente.

Entonces:

Tire de ambos, a menos que esté haciendo un análisis de memoria, en cuyo caso, no tire tampoco.

El análisis forense de RAM (por ejemplo, / dev / shm) puede ser útil.

Pero prefiero desconectar el cable de alimentación (pero intente iniciar sesión y rsync / proc justo antes).

Las razones para utilizar el cable de alimentación son:

1. Cuando haces análisis forenses en un sistema pirateado, estás "pasando por la escena del crimen"
2. El kit raíz sigue ejecutándose; no es tan difícil para el malintencionado ejecutar algo (por ejemplo, eliminación del sistema) en el evento Network Link Down .

Kyle Rankin dio una buena introducción a la charla forense : allí recomienda tirar del cable de alimentación.

Desconecta la red. El atacante no puede obtener ninguna información adicional si no hay conexión de red. Es muy difícil (léase: imposible) hacer análisis forenses sin poder.

En la actualidad, podría ser una máquina virtual, por lo que cualquiera de los métodos es fácil e incluso se puede hacer de forma remota. (Las máquinas virtuales también dan lugar a la posibilidad de utilizar instantáneas, por supuesto)

Sugeriría desconectarse de la red como un primer paso automático, porque esto le da tiempo para reflexionar sobre cuál debería ser el siguiente paso, ya sea que el siguiente paso sea desconectar el cable de alimentación u otra cosa. Si sabe que sus "procedimientos de respuesta de seguridad" corporativos no le permitirán pasar tiempo cavando en la máquina en detalle, entonces preservar el contenido de RAM podría no ser tan importante.

Sugeriría que hacer "separar a la víctima de sus asaltantes" de cualquier manera es más importante que el cómo, por lo que ambos enfoques son válidos. Yo no tendría problemas para tirar del cable de alimentación, pongamoslo así.

Esta no es una o una situación. En general, desea hacer ambas cosas: desea realizar ciertos análisis forenses (volcado de procesos en ejecución, escucha de enchufes, archivos en / tmp, etc.) en un sistema que se ha eliminado de la red y luego realizar los diagnósticos restantes desde una caja fuerte entorno (es decir, un CD en vivo). Sin embargo, hay situaciones en las que ninguno de los enfoques es el correcto, y debe pensar y comprender cuáles podrían ser esos en su organización.

Antes de hacer nada, averigüe si necesita preservar la evidencia para un posible enjuiciamiento. El manejo de la evidencia es un tema muy complicado y no para personas poco capacitadas. Una vez que haya respondido eso, la persona forense en informática capacitada puede tomarlo desde allí.

No es necesario apagar el servidor. Simplemente puede deshabilitar la conectividad desde la puerta de enlace / enrutador fronterizo. Una regla de firewall será suficiente para descartar cualquier otro paquete enviado / recibido.

La respuesta depende en gran medida de lo que quiere decir con "enraizado". Por lo general, es una buena idea obtener el liderazgo de la red, especialmente si cree que se trata de un atacante humano activo que busca información confidencial.

Tirar del poder es mucho más difícil de responder. Si cree que hay código malicioso en ejecución que puede cubrir sus huellas, hágalo. Sin embargo, si cree que puede haber evidencia de un robo en la memoria, déjelo en funcionamiento.

En general, depende de si se trata de código malicioso, personal no voluntario o alguien con un objetivo específico en mente.

Si se equivoca por precaución, tire de la corriente. Perderá una pequeña cantidad de evidencia potencial, pero puede evitar la eliminación masiva de otra evidencia por código automatizado.

- Por otra parte, si siente que la máquina se ha visto comprometida y sabe que no tiene datos confidenciales, está muy seguro de la seguridad de su red en otro lugar y comprende las consecuencias de hacerlo, tal vez obtenga un boffin forense lo antes posible y vea si puede rastrear o comprender el ataque y avanzar desde allí. Aunque normalmente no es una buena idea

Mi respuesta fue antes de la edición, con los 5 supuestos.
Supuse que si su servidor se rooteó, está tratando con un atacante sofisticado y dirigido, y que no tiene forma de saber cuándo y de dónde vino el ataque. (Dado que la máquina estaba rooteada, obviamente no puedes confiar en nada de lo que te dice. Sin embargo, es posible que tengas información fuera de la caja, por ejemplo, IDS ...)
Supuse también que tienes interés en tratar con tu atacante, y no solo en saludar. fuera como una mosca molesta. Si el supuesto atacante es un script kiddie, esto sería diferente. También supuse que, dado que el atacante es específico y sofisticado, es probable que tenga un software personalizado ejecutándose en su máquina, que pueda responder a sus acciones en él ...

Ninguno.
Echa un vistazo a /security//q/181/33 , de cualquier manera es una mala idea.
Es como darle un par de vendas al caballero negro ... demasiado poco, demasiado tarde, simplemente no va a ayudar mucho.

Para todos aquellos que sienten que esta respuesta está demasiado lejos, o simplemente no es lo suficientemente "consciente de la seguridad", deben darse cuenta de que ya es demasiado tarde .
Ya no es su servidor, incluso si lo desconecta por completo. Incluso si cierra, ejecute todos sus AV y lo que sea, ya no lo posee, lo hacen.
Esa es la definición de "arraigado".

Ahora, suponiendo que lo poseen y que pueden ocultarle su propiedad, debe considerar: ¿qué logrará desconectarlo?
Lo único que logrará, ya que seguirá arraigado de todos modos, es hacerle saber a tu adversario que estás en ello. Lo que simplemente levanta a sus guardias y los hace comenzar a limpiar después de sí mismos (si aún no lo han hecho), lo que acaba con cualquier esperanza de los forenses.
Todavía no está protegiendo ese servidor ni ninguno de sus datos. ¿Cuánto tiempo ha sido arraigado? ¿Cómo sabrías?

Lo que es mejor que hagas:

• Deje el servidor en funcionamiento ...
• Aíslelo del resto de su red interna, otros servidores, etc., pero lo mejor es conectar algún tipo de simulación, por lo que parece estar conectado.
• Inicie silenciosamente análisis forense en tiempo real / de red, ejecute trazas, etc.
• Intenta averiguar la extensión y la duración del daño (obviamente es diferente si sucedió hace 2 horas o hace 2 meses).
• Continúa desde allí ... Solo después de mitigar el daño real , sigue adelante y límpialo.
• Por supuesto, no olvides investigar las causas raíz y aplicar los controles para garantizar que no vuelva a suceder ...

Después de revisar sus suposiciones, haga ambas cosas. Use un medio basado en CD / DVD para volcar el estado actual. Principalmente querrás poder determinar cómo te comprometiste. También puede intentar recuperar datos de usuario que no estén en sus imágenes de respaldo. yo

Luego reconstruya el sistema a partir de los últimos medios de respaldo que no estén contaminados. Verifique esto con sumas de verificación si es posible. Alternativamente, reinstale el software desde los medios de instalación y reconfigure. La reconfiguración debe ser automática si ha estado usando Puppet o cfEngine para configurar su servidor.

Vuelva a cargar los datos del usuario y escanee los componentes del kit raíz. Verifique que no tenga programas setuid o setgid en los directorios de datos.

Determine y cierre el método de acceso utilizado para infectar el sistema. Etapa de reactivación del servidor que permite tiempo para verificar que las aplicaciones se ejecuten como se esperaba. Monitoree cuidadosamente los nuevos intentos de infección.

Todo esto supone que la infección está en el nivel raíz. Las infecciones web se pueden hacer alterando el código ejecutado por el servidor web. Permitir que el servidor web escriba acceso a su código puede hacer que esto sea más fácil. Es posible que aún desee tratar este caso como si la cuenta raíz estuviera comprometida.

Si la raíz en un sistema se ha visto comprometida en un sistema, es posible que haya más sistemas comprometidos. Considere cuidadosamente a qué sistemas se puede acceder sin una contraseña del sistema infectado.