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


11

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.

2
También puede visitar aquí: security.stackexchange.com
sysadmin1138


2
@Tom: no es un engaño, es una discusión de extensión de un punto específico de esa pregunta.
mfinni

3
@ sysadmin1138, prueba específicamente security.stackexchange.com/q/181/33
AviD

Respuestas:


6

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.


16

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.


+1 por "pisar la escena del crimen". A menos que sepa exactamente lo que está haciendo, o realmente no le importa recopilar pruebas forenses exactas, es posible que desee llamar a los expertos en lugar de contaminar la evidencia mientras aprende a hacer análisis forenses ...
dunxd

10

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.


3
Puede (y probablemente debería) realizar análisis forenses desde fuera de línea (A) a través de un CD en vivo, (B) moviendo el disco duro a un sistema diferente o (C) después de tomar imágenes de los discos duros afectados (a través de un CD en vivo) .
Aleksandr Levchuk

3
A menudo hay evidencia útil en la memoria. Esto debe permitirse antes de que se recomiende cualquier pérdida de energía.
Sirex

También piense en desconectar la interfaz LOM por seguridad :)
Kedare

7

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í.


+1 para la VM. Si desconecta la red, el rootkit sigue ejecutándose, no es tan difícil para los maliciosos ejecutar algo (por ejemplo, eliminación del sistema) en el evento Network Link Down
Aleksandr Levchuk

66
Las instantáneas del estado del sistema en ejecución son una gran idea. Estoy enojado conmigo mismo por no pensar en ello.
jgoldschrafe

@Alexsandr: he estado tratando de pensar en el ejemplo real y estoy dibujando un espacio en blanco, pero parece recordar un rootkit que permanece completamente en la memoria, por lo que se perdería cuando se desconecte el enchufe. Creo que es un caso de cualquier manera, existe el riesgo de perder evidencia.
Rob Moir

6

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.


Si desconecta la red, el rootkit sigue ejecutándose, no es tan difícil que el código malicioso ejecute algo (por ejemplo, borrado del sistema) en un evento Network Link Down .
Aleksandr Levchuk

Eso es definitivamente cierto, y es una oportunidad que tiene que evaluar y decidir si desea tomar, dependiendo de la sensibilidad de la situación. Algunos rootkits solo residen en la memoria, y si eliminas la energía del sistema, eliminas cualquier posibilidad de descubrir cómo llegó allí. Puede intentar bloquear el tráfico fuera del puerto del conmutador mientras mantiene el estado del enlace, pero cualquier rootkit es software y puede hacer cualquier cosa que cualquier otro software pueda hacer; no hay nada que les impida probar la puerta de enlace predeterminada y activar la misma bomba si no es accesible.
jgoldschrafe

4

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í.


1
Primero, creo que uno debería decidir ¿ Procesar o no? . Kyle Rankin en su charla ( goo.gl/g21Ok ). Comienza discutiendo esto. Para enjuiciar a uno tendría que proporcionar evidencia de pérdida sustancial de monitoreo.
Aleksandr Levchuk

1
@Aleksander En general, debe saber muy, muy temprano en el proceso, si puede reutilizar o no el hardware y los datos comprometidos o si tendrá que almacenarlo y construir un nuevo sistema a partir de piezas completamente nuevas. Esto es muy probable incluso antes de que haya demostrado pérdidas de reputación financiera o comercial. La preservación de la cadena de evidencia debe suceder en el momento en que alguien se da cuenta de que ha sucedido un evento potencialmente procesable.
sysadmin1138

A menudo, es mejor comenzar por mantener las opciones abiertas, volver a enjuiciar o no, ya que es posible que no sepa si existe una pérdida monetaria, por lo que en las primeras etapas haciendo todo por el libro, es importante mantener la cadena de custodia.
Rory Alsop

3

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.


+1 Esa es una de las razones por las que tener una puerta de enlace es una buena idea. Pero, ¿y si no tienes uno? Si desconecta el cable de red directo, el rootkit puede recibir el evento Network Link Down . ¿Y no es una mala idea iniciar sesión en el servidor rooteado y hacer algo allí el día 0?
Aleksandr Levchuk

2

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


1

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 ...

2
Creo que esto puede funcionar en una situación en la que puede moverlo rápidamente a un entorno simulado / aislado, pero tan pocas organizaciones pueden hacer esto que en realidad quieren ir al lado de 'minimizar el impacto' de las cosas, por lo que desconectan el poder o la red A menudo es la eliminación instantánea de esa amenaza. (Todavía te hice +1 como desearía que fuera así :-)
Rory Alsop

El problema de @Rory es que no puede minimizar el impacto, el servidor ya está pwned. No está recuperando eso, y cualquier información confidencial también puede ser robada, ya que no sabe cuánto tiempo han tenido acceso. Dicho esto, el entorno simulado es solo hielo, lo importante es el aislamiento, y creo que la mayoría de las organizaciones tienen un firewall sólido, cambian algunas reglas de acceso y eres oro. Esa es otra razón servidores accesibles deben estar en una DMZ - hace que la parte más fácil ....
Avid

Además, quiero aclarar algo: lo anterior se aplica cuando el sistema operativo está rooteado . Si hay alguna forma de vulnerabilidad a nivel de aplicación (por ejemplo, inyección de SQL) que se está explotando en su sitio web, ¡ CIERRE ABSOLUTAMENTE y tire de todos los cables que pueda tener en sus manos! Pero la raíz del sistema operativo es diferente: controlan toda la infraestructura de su máquina. Ya no tienes ningún control.
AviD

2
no, lo que quise decir fue minimizar el impacto más allá de esa máquina rooteada. Estoy de acuerdo en que se pierde totalmente, pero a menos que se puede lograr que rápidamente aislado, no hay manera de saber lo que el controlador podría hacer para el resto de sus sistemas
Rory Alsop

0

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.