Pregunta ¿Cómo trato con un servidor comprometido?


Esto es un Pregunta canónica sobre Server Security - Respondiendo a eventos de incumplimiento (Hacking)
  Ver también:

Versión canónica
Sospecho que uno o más de mis servidores están comprometidos por un pirata informático, un virus u otro mecanismo:

  • ¿Cuáles son mis primeros pasos? Cuando llego al sitio, ¿debo desconectar el servidor, conservar la "evidencia", hay otras consideraciones iniciales?
  • ¿Cómo hago para volver a obtener servicios en línea?
  • ¿Cómo evito que lo mismo vuelva a suceder inmediatamente?
  • ¿Existen las mejores prácticas o metodologías para aprender de este incidente?
  • Si quisiera armar un plan de respuesta a incidentes, ¿por dónde empezar? ¿Debería ser esto parte de mi recuperación de desastres o planificación de continuidad de negocios?

Versión original 

2011.01.02 - Estoy en camino al trabajo a las 9.30 p.m. un domingo porque nuestro servidor ha sido comprometido de alguna manera y resultó en una    DOS ataque a nuestro proveedor. Los servidores acceden a internet.   ha sido cerrado, lo que significa que más de 5-600 de los sitios de nuestros clientes están ahora   abajo. Ahora bien, esto podría ser un hack FTP, o alguna debilidad en el código   algun lado. No estoy seguro hasta que llegue allí.

¿Cómo puedo rastrear esto rápidamente? Estamos en una gran cantidad de   litigios si no consigo la copia de seguridad del servidor lo antes posible. Cualquier ayuda es   apreciado. Estamos ejecutando Open SUSE 11.0.


2011.01.03 - Gracias a todos por vuestra ayuda. Por suerte, no era la única persona responsable de este servidor, solo la más cercana. Nos las arreglamos   para resolver este problema, aunque puede que no se aplique a muchos otros en una   situación diferente Voy a detallar lo que hicimos.

Desenchufamos el servidor de la red. Estaba realizando (intentando   realizar) un ataque de denegación de servicio en otro servidor en Indonesia,   y el culpable también tenía su base allí.

En primer lugar, tratamos de identificar de dónde venía el servidor,   considerando que tenemos más de 500 sitios en el servidor, esperamos ser   Moonlighting por algún tiempo. Sin embargo, con el acceso SSH todavía, corrimos un   comando para encontrar todos los archivos editados o creados en el momento en que los ataques   empezado. Por suerte, el archivo ofensivo fue creado durante el invierno.   vacaciones, lo que significa que no se crearon muchos otros archivos en el   servidor en ese momento.

Entonces pudimos identificar el archivo ofensivo que estaba dentro del   carpeta de imágenes subidas dentro de una ZenCart sitio web.

Después de una breve pausa para el cigarrillo llegamos a la conclusión de que, debido a los archivos   ubicación, debe haber sido cargado a través de una instalación de carga de archivos que   fue asegurado inadecuadamente Después de un poco de googlear, encontramos que había   una vulnerabilidad de seguridad que permitía subir archivos, dentro de la   Panel de administración de ZenCart, para una imagen para una compañía discográfica. (La sección   que en realidad nunca se usó), publicando este formulario solo subí cualquier   archivo, no comprobó la extensión del archivo, y ni siquiera   Compruebe si el usuario ha iniciado sesión.

Esto significó que cualquier archivo podría ser cargado, incluyendo un archivo PHP para   el ataque. Aseguramos la vulnerabilidad con ZenCart en los infectados.   sitio, y eliminó los archivos ofensivos.

El trabajo fue hecho, y yo estaba en casa por 2 a.m.


La moral   - Siempre aplique parches de seguridad para ZenCart, o cualquier otro sistema CMS para el caso. Como cuando se lanzan las actualizaciones de seguridad, el conjunto   El mundo es consciente de la vulnerabilidad.   - Siempre haga copias de seguridad, y haga copias de seguridad de sus copias de seguridad.   - Emplear o hacer arreglos para alguien que estará allí en momentos como estos. Para evitar que alguien confíe en una publicación panicy en el servidor   Culpa.


578
2018-01-02 21:31


origen


Sé cómo te sientes: ¡hemos sido muy afortunados con los hackers "útiles" en este sitio, donde nos cuentan lo que han hecho! Espero con impaciencia respuestas excelentes a esta pregunta, en caso de que recibamos invitados "no tan útiles" en el futuro. - Jarrod Dixon♦
¡Llama a un profesional para que te ayude! - marcog
No quiero sonar inteligente o antipático (no lo soy) y, por supuesto, ignoro los detalles de su situación, pero si usted es la única persona responsable de la configuración de un sitio de 500-600, podría Ser un defecto fundamental en cómo se ejecuta este servidor. Algunas compañías emplean un administrador de sistemas dedicado que no hace nada más en todo el día sino que mantiene servidores, una tarea que es no Automáticamente dentro del alcance de un programador, aunque pueda parecer así. Tal vez sea algo que valga la pena considerar cuando la crisis haya terminado. De todos modos, ahora mismo, la mejor de las suertes para resolver la situación actual. - Pekka 웃
No necesariamente asuma que tiene un kit completo de root del kernel y que su contraseña de root está comprometida. Es posible que solo sea un guión de bash / perl astuto, y es posible limpiarlo sin formarlo a pesar de lo que el coro hace de aquí ... serverfault.com/questions/639699/… - Hayden Thring


Respuestas:


Es difícil dar consejos específicos de lo que has publicado aquí, pero sí tengo algunos consejos genéricos basados ​​en una publicación que escribí hace años cuando todavía podía molestarme en el blog.

No se asuste

Lo primero es lo primero, no hay "soluciones rápidas" que no sean la restauración de su sistema desde una copia de seguridad realizada antes de la intrusión, y esto tiene al menos dos problemas.

  1. Es difícil señalar cuándo ocurrió la intrusión.
  2. No le ayuda a cerrar el "agujero" que les permitió romper la última vez, ni a lidiar con las consecuencias de cualquier "robo de datos" que también haya ocurrido.

Esta pregunta sigue siendo repetida por las víctimas de 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 no les gustan las respuestas que han visto cuando buscan ayuda, o no pueden encontrar a alguien en quien confían 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 se pierden el 95% de las preguntas y respuestas donde su caso es lo mismo. 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 en el exterior que mira hacia adentro, ya sea una persona de seguridad informática que busque el problema para tratar de ayudarlo a usted o incluso al atacante, es muy probable que su problema sea al menos el 95% idéntico a cualquier otro caso que tengan. alguna vez mirado

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

Usted acaba de descubrir que su servidor (s) fue hackeado. ¿Ahora que?

No te asustes. Absolutamente no actúe apresuradamente, y absolutamente no intente fingir que las cosas nunca sucedieron y no actuó en absoluto.

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

Algunos de estos pasos van a doler, y (a menos que su sitio web contenga una copia de mis datos) realmente no me importa si ignora todos o algunos de estos pasos, eso depende de usted. Pero seguirlos adecuadamente mejorará las cosas al final. El medicamento puede tener un sabor horrible, pero a veces hay que pasarlo por alto si realmente desea que la cura funcione.

Evita que el problema empeore de lo que ya está:

  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. Quiero decir esto muy 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 atracadores 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 una exageración; por otro lado, podría no ser así. Usted no sabe de ninguna manera, ¿verdad?
  3. Revisa tus otros sistemas. Preste especial atención a otros servicios de Internet y a aquellos que poseen datos financieros u otros datos comerciales sensibles.
  4. Si el sistema contiene los datos personales de cualquier persona, informe de inmediato a la persona responsable de la protección de datos (si no es usted) e INSTE una divulgación completa. Sé que este es duro. Sé que esta va a doler. Sé que muchas empresas quieren resolver este tipo de problemas debajo de la alfombra, pero la empresa tendrá que lidiar con eso, y debe hacerlo con un ojo en todas y cada una de las leyes de privacidad relevantes.

Por muy molestos que estén sus clientes si usted les habla sobre un problema, ellos se sentirán mucho más molestos si no les cuenta, y solo se enterarán por sí mismos después de que alguien haya cobrado un valor de $ 8,000 en productos utilizando los detalles de la tarjeta de crédito. robó de su sitio.

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

Entiende 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 mí que realmente decida escribir este artículo. No voy a enlazar a esa publicación para que la gente se pueda reír, pero la verdadera tragedia es cuando la gente no aprende de sus errores.
  2. Examine los sistemas 'atacados' para comprender cómo los ataques lograron comprometer su seguridad. Haga todo lo posible para averiguar de dónde provinieron los ataques, para que comprenda qué problemas tiene y necesita resolver para hacer que su sistema sea seguro en el futuro.
  3. Examine los sistemas 'atacados' otra vez, esta vez para entender dónde fueron los ataques, para que pueda entender qué sistemas se vieron comprometidos en el ataque. Asegúrate de seguir cualquier puntero que sugiera que los sistemas comprometidos podrían convertirse en un trampolín para atacar aún más a tus sistemas.
  4. Asegúrese de que las "puertas de enlace" utilizadas en todos los ataques se entiendan completamente, de modo que pueda comenzar a cerrarlos correctamente. (Por ejemplo, si sus sistemas se vieron comprometidos por un ataque de inyección de SQL, no solo necesita cerrar la línea de código defectuosa en particular por la que se interrumpieron, sino que también querría auditar todo su código para ver si existe el mismo tipo de error. fue hecho en otro lugar).
  5. Comprenda que los ataques pueden tener éxito debido a más de una falla. A menudo, los ataques tienen éxito no al encontrar un error importante en un sistema, sino al encadenar varios problemas (a veces pequeños y triviales por sí mismos) para comprometer un sistema. Por ejemplo, usar ataques de inyección SQL para enviar comandos a un servidor de base de datos, descubrir 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 a los hackers les gusta llamarlo: "otro día en la oficina aprovechando los errores comunes que cometen las personas".

¿Por qué no simplemente "reparar" el exploit o rootkit que ha detectado y volver a poner el sistema en línea?

En situaciones como esta, el problema es que ya no tienes control de ese sistema. Ya no es tu computadora.

la única forma de ser cierto que tienes el control del sistema es reconstruir el sistema. Si bien hay mucho valor en la búsqueda y reparación de la vulnerabilidad utilizada para ingresar al sistema, no se puede estar seguro de qué otra cosa se le hizo al sistema una vez que los intrusos obtuvieron el control (de hecho, no es algo desconocido para los hackers que reclutan sistemas en una red de bots para parchear los exploits que ellos mismos utilizaron, para proteger "su" nueva computadora de otros hackers, así como para instalar su rootkit.

Haga un plan de recuperación y vuelva a poner en línea su sitio web y apéguese a él:

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

Sin embargo, no ceda a la tentación de volver a conectarse en línea demasiado rápido. En vez de eso, muévase lo más rápido posible para comprender qué causó el problema y para resolverlo antes de volver a conectarse o, de lo contrario, una vez más será víctima de una intrusión, y recuerde que "hackearse una vez puede clasificarse como infortunio; para ser hackeado de nuevo directamente después parece descuido "(con disculpas a Oscar Wilde).

  1. Supongo que ha comprendido 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 lo necesitas. 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 se sienta tentado a volver a poner en línea el mismo servidor sin una reconstrucción completa. Debería ser mucho más rápido crear una nueva caja o "atacar al servidor desde la órbita y hacer 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 el sistema esté completamente limpio, o los procedimientos de implementación de su sitio web son un desastre impío. Es de suponer que tiene copias de seguridad y despliegues de prueba de su sitio que puede utilizar para crear el sitio en vivo, y si no lo hace, no es su mayor problema ser hackeado.
  4. Tenga mucho cuidado al reutilizar datos que estaban "en vivo" en el sistema en el momento del hackeo. 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 desde una copia de seguridad realizada antes de la intrusión. Si no puedes o no quieres hacer eso, debes tener mucho cuidado con esos datos porque están manchados. Debe ser especialmente consciente de las consecuencias para los demás si esta información pertenece a los clientes o visitantes del sitio en lugar de a usted.
  5. Supervise el sistema (s) cuidadosamente. Debería decidir hacer esto como un proceso continuo en el futuro (más abajo) pero se esfuerza por estar atento durante el período inmediatamente después de que su sitio vuelva a estar en línea. Es casi seguro que los intrusos regresarán, y si puedes detectarlos intentando ingresar de nuevo, podrás ver rápidamente si realmente has cerrado todos los agujeros que utilizaron antes, además de los que hicieron para sí mismos, y podrías reunirte como ú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 a lo largo de todo el ciclo de vida del diseño, implementación y mantenimiento de un sistema orientado a Internet, no es algo que pueda aplicar algunas capas sobre su código posteriormente, como barato pintar. Para estar bien asegurados, 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 eso es aburrido y ya lo ha escuchado todo y que "simplemente no me doy cuenta de la presión" de hacer que su servicio beta web2.0 (beta) entre en estado beta en la web, pero el hecho es que esto sigue repetirse porque era cierto la primera vez que se dijo y aún no se ha convertido en una 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 cómo administrar y reducir 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. ¿Fue la falla que permitió a las personas ingresar en su sitio un error conocido en el código del proveedor, para el cual había un parche disponible? Si es así, ¿necesita volver a pensar cómo enfoca las aplicaciones en sus servidores de Internet?
  2. ¿Fue la falla que permitió a las personas ingresar en su sitio un error desconocido en el código del proveedor, para el cual no había un parche disponible? Lo más seguro es que no defiendo cambiar de proveedor cuando algo como esto te molesta 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 le falla constantemente, entonces debería migrar a algo más robusto o, como mínimo, volver a diseñar su sistema para que los componentes vulnerables queden 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 volver a pensar su enfoque sobre cómo aprobar 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 utilizando técnicas de codificación bien documentadas). ).
  4. ¿Se debió la falla 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 donde sea posible? Estos 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 realizar en cada uno y, por lo tanto, minimizando la oportunidad de cometer un error. Lo mismo ocurre con la implementación del código: si necesita hacer algo "especial" para implementar la última versión de su aplicación web, entonces intente automatizarla y asegúrese de que siempre se haga de una manera consistente.
  5. ¿Podría haberse descubierto antes la intrusión con una mejor supervisión de sus sistemas? Por supuesto, el monitoreo las 24 horas o un sistema "de guardia" para su personal puede no ser rentable, pero hay compañías que pueden monitorear sus servicios web para usted y alertarlo en caso de un problema. Puede decidir que no puede pagar esto o que no lo necesita y eso está bien ... simplemente tómelo en cuenta.
  6. Use herramientas como tripwire y nessus cuando sea apropiado, pero no las use a ciegas porque 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 manera regular. Una vez más, puede decidir que no puede pagar esto o que no lo necesita y eso está bien ... simplemente tómelo en cuenta.

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

Si decide que el "riesgo" del piso inferior de las inundaciones de su hogar es alto, pero no lo suficientemente alto como para justificar la mudanza, al menos debe mover las reliquias familiares irreemplazables arriba. ¿Derecha?

  1. ¿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 asegura 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 robar información que usted no tiene, y el segundo punto es que cuanto menos almacena, menos necesita mantener y codificar, y por lo tanto hay menos posibilidades de que los errores se deslicen. 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 de una base de datos, asegúrese de que la cuenta que usa la aplicación web para este servicio solo tiene acceso de lectura, no le permita el acceso de escritura y, ciertamente, no el 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 ejecuta un pequeño sitio web hablando sobre cómo escribir el código de la aplicación de escritorio y decide comenzar a vender aplicaciones de escritorio pequeñas desde el sitio, considere "subcontratar" el sistema de pedidos de su tarjeta de crédito a alguien como Paypal.
  5. Si es posible, haga que la recuperación de los sistemas comprometidos sea parte de su plan de Recuperación ante Desastres. Podría decirse que este es solo otro "escenario de desastre" con el que podría encontrarse, simplemente uno con su propio conjunto de problemas y problemas que son distintos de los habituales "sala de servidores se incendió".

... Y finalmente

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

Por encima de todo: No te asustes. 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.


988
2018-01-02 21:46



+1 por un excelente post para tener a mano para que la gente comience en una dirección. Sé lo común que es para los administradores de servidores de aficionados entrar en este modo de pánico la primera vez que les sucede un "hack". Es un enorme error estar en ese lugar, pero sucede. La esperanza sería que esto no le pasaría a la misma persona, dos veces. - Andrew Barber
+1 "... pero este no es el momento de dejar que tu ego se interponga en lo que necesitas hacer". Esto es importante para que los administradores de sistemas entiendan a veces. No importa qué tan informado esté, siempre hay personas (a veces maliciosas) que tienen más conocimientos o son más inteligentes que usted. - Grahamux
Gran respuesta. Sin embargo, no estoy seguro de por qué todo el mundo trata el paso de "llamar a la policía" como opcional. Si usted es responsable de los datos de otras personas (y le preocupa el litigio), esta debe ser una de las primeras cosas en su lista de cosas que hacer. - wds
Muy buena redacción, solo una pregunta: "haga una revelación completa y franca a cualquier persona potencialmente afectada a la vez". Honorable, pero no siempre correcto. Al responder a un compromiso, es posible que tenga que recortar algunos aspectos de la gobernanza, y su empresa generalmente le dará un poco de holgura, sin embargo ... la divulgación o no, específicamente cuando existen implicaciones de protección de datos, puede ser un tema por encima de su calificación de pago y Podría tener implicaciones legales. Puede ser mejor sugerir que informe de inmediato a la persona responsable de la protección de datos (si no es usted) y URGE una divulgación completa. - TheoJones
Los hosts de las máquinas virtuales de @GilesRoberts suelen tener un panel de control que le permite manipular la configuración de sus invitados e incluso controlarlos de forma remota sin usar RDP o SSH para iniciar sesión en el invitado. Debería poder aislar al huésped usando los controles del host para hacerlo, luego usar sus herramientas de visualización remota para investigar al huésped en su tiempo libre. - Rob Moir


Suena como si estuvieran ligeramente por encima de tu cabeza; está bien. Llame a su jefe y comience a negociar un presupuesto de respuesta de seguridad de emergencia. $ 10,000 podría ser un buen lugar para comenzar. Luego necesita que alguien (un PFY, un compañero de trabajo, un gerente) comience a llamar a las compañías que se especializan en la respuesta a incidentes de seguridad. Muchos pueden responder dentro de las 24 horas y, a veces, incluso más rápido si tienen una oficina en su ciudad.

También necesitas a alguien para clasificar a los clientes; Sin duda, alguien ya lo es. Alguien debe estar en el teléfono con ellos para explicar qué está sucediendo, qué se está haciendo para manejar la situación y para responder a sus preguntas.

Entonces, necesitas ...

  1. Mantén la calma Si está a cargo de la respuesta a incidentes, lo que haga ahora debe demostrar la máxima profesionalidad y liderazgo. Documente todo lo que hace y mantenga a su gerente y equipo ejecutivo al tanto de las acciones principales que toma; esto incluye trabajar con un equipo de respuesta, deshabilitar servidores, realizar copias de seguridad de los datos y volver a conectar las cosas. No necesitan detalles sangrientos, pero deberían saber de usted cada 30 minutos aproximadamente.

  2. Ser realista. No eres un profesional de la seguridad, y hay cosas que no sabes. Está bien. Cuando inicie sesión en los servidores y mire los datos, debe comprender sus límites. Pise con cuidado. En el curso de su investigación, asegúrese de no pisar información vital o cambiar algo que podría ser necesario más adelante. Si se siente incómodo o si está adivinando, ese es un buen lugar para detenerse y conseguir que un profesional experimentado se haga cargo.

  3. Consigue una memoria USB limpia y discos duros de repuesto. Usted recogerá pruebas aquí. Haga copias de seguridad de todo lo que crea que puede ser relevante; comunicación con su ISP, volcados de red, etc. Incluso si la policía no se involucra, en caso de una demanda, querrá que esta evidencia demuestre que su compañía manejó el incidente de seguridad de una manera profesional y apropiada.

  4. Lo más importante es detener la pérdida. Identifique y corte el acceso a servicios, datos y máquinas comprometidos. Preferiblemente, deberías tirar de su cable de red; Si no puedes, entonces tira el poder.

  5. A continuación, debe eliminar el atacante y cerrar el (los) agujero (s). Es de suponer que el atacante ya no tiene acceso interactivo porque usted eliminó la red. Ahora necesita identificar, documentar (con copias de seguridad, capturas de pantalla y sus propias notas de observación personal; o preferiblemente, incluso eliminando las unidades de los servidores afectados y haciendo una copia completa de la imagen del disco), y luego eliminar cualquier código y proceso que haya dejado atrás. . La siguiente parte será mala si no tienes copias de seguridad; Puedes tratar de desenredar el atacante del sistema a mano, pero nunca estarás seguro de que tienes todo lo que dejó atrás. Los rootkits son viciosos, y no todos son detectables. La mejor respuesta será identificar la vulnerabilidad que utilizó para ingresar, hacer copias de imagen de los discos afectados y luego borrar los sistemas afectados y volver a cargarlos desde una copia de seguridad válida. No confíes ciegamente en tu respaldo; verificalo Repare o cierre la vulnerabilidad antes de que el nuevo host vuelva a conectarse a la red y luego vuelva a conectarlo.

  6. Organiza todos tus datos en un informe. En este punto la vulnerabilidad está cerrada y tienes tiempo para respirar. No tengas la tentación de saltarte este paso; Es incluso más importante que el resto del proceso. En el informe, debe identificar qué salió mal, cómo respondió su equipo y los pasos que está tomando para evitar que este incidente vuelva a ocurrir. Sé tan detallista como puedas; esto no es solo para usted, sino también para su administración y como defensa en una demanda potencial.

Esa es una revisión a cielo abierto de qué hacer; la mayor parte del trabajo es simplemente documentación y manejo de copias de seguridad. No te asustes, puedes hacer eso. yo fuertemente Recomiendo obtener ayuda profesional de seguridad. Incluso si puede manejar lo que está pasando, su ayuda será invaluable y, por lo general, vienen con equipos para hacer que el proceso sea más fácil y rápido. Si su jefe se resiste al costo, recuérdele que es muy pequeño en comparación con el manejo de una demanda.

Tienes mis consuelos para tu situación. Buena suerte.


199
2018-01-02 22:16



+1 Gran respuesta. Parece que el OP no tiene una "respuesta de emergencia" predefinida y su publicación, entre otras cosas buenas, debería indicarles cómo configurarla. - Rob Moir


CERT tiene un documento Pasos para recuperarse de un compromiso del sistema UNIX o NT eso es bueno. Los detalles técnicos específicos de este documento están un poco desactualizados, pero muchos de los consejos generales aún se aplican directamente.

Un resumen rápido de los pasos básicos es este.

  • Consulte su política de seguridad o gestión.
  • Obtener el control (desconectar la computadora)
  • Analiza la intrusión, obtén registros, imagina qué salió mal.
  • Reparar cosas
    • Instala una versión limpia de tu sistema operativo! Si el sistema ha sido comprometido, no puede confiar en él, punto.
  • Actualiza los sistemas para que esto no vuelva a suceder.
  • Reanudar operaciones
  • Actualiza tu política para el futuro y el documento.

Me gustaría señalarle específicamente a la sección E.1.

E.1.   Tenga en cuenta que si una máquina es   comprometido, cualquier cosa en ese sistema   podría haber sido modificado, incluyendo   El kernel, binarios, archivos de datos,   Procesos en ejecución, y memoria. En   general, la única manera de confiar en que un   La máquina está libre de puertas traseras y   modificaciones intruso es reinstalar   la operacion

Si no tiene un sistema ya implementado como Tripwire, no hay forma de que esté 100% seguro de haber limpiado el sistema.


105
2018-05-08 09:02



Incluso entonces tripwire puede ser engañado con módulos del núcleo y tal. Reinstalar. - reconbot
La pregunta relacionada sobre como responder en una crisis También puede ser útil aquí. - Zoredache


  1. Identificar el problema. Lea los registros.
  2. Contiene. Has desconectado el servidor, así que eso está hecho.
  3. Erradicar. Reinstalar el sistema afectado, lo más probable. Sin embargo, no borre el disco duro del pirateado, use uno nuevo. Es más seguro, y es posible que necesites el anterior para recuperar los trucos feos de los que no se hizo una copia de seguridad, y hacer pruebas forenses para averiguar qué sucedió.
  4. Recuperar. Instale lo que sea necesario y recupere copias de seguridad para que sus clientes estén en línea.
  5. Seguir. Averigua cuál era el problema y evita que vuelva a suceder.

64
2018-01-02 21:49





La respuesta de la "píldora amarga" de Robert es acertada pero completamente genérica (bueno, como era tu pregunta). Parece que tienes un problema de administración y necesitas un administrador del sistema a tiempo completo si tienes un servidor y 600 clientes, pero eso no te ayuda ahora.

Dirijo una empresa de alojamiento que proporciona un poco de control en esta situación, por lo que trato con muchas máquinas comprometidas, pero también trato con las mejores prácticas para la nuestra. Siempre les decimos a nuestros clientes comprometidos que reconstruyan a menos que no estén absolutamente seguros de la naturaleza de un compromiso. No hay otra ruta responsable a largo plazo.

Sin embargo, es casi seguro que solo eres víctima de un script kiddy que quería una plataforma de lanzamiento para los ataques DoS, los bouncers de IRC, o algo completamente ajeno a los sitios y datos de tus clientes. Por lo tanto, como medida temporal mientras reconstruye, puede considerar la posibilidad de abrir un firewall de salida pesado en su caja. Si puede bloquear todas las conexiones UDP y TCP salientes que no son absolutamente necesarias para el funcionamiento de sus sitios, fácilmente puede hacer que su caja comprometida sea inútil para quien la está tomando prestada, y mitigar el efecto en la red de su proveedor a cero.

Este proceso puede tardar algunas horas si no lo ha hecho antes y nunca ha considerado un firewall, pero puede ayudarlo a restaurar el servicio de sus clientes. a riesgo de continuar brindándole al atacante acceso a los datos de sus clientes. Como dice que tiene cientos de clientes en una máquina, supongo que está alojando pequeños sitios web de folletos para pequeñas empresas, y no 600 sistemas de comercio electrónico llenos de números de tarjetas de crédito. Si ese es el caso, este puede ser un riesgo aceptable para usted y volver a conectar su sistema más rápido que la auditoría de 600 sitios para detectar errores de seguridad. antes de Traes algo de vuelta. Pero sabrá qué datos hay y qué tan cómodo estaría tomando esa decisión.

Esta no es absolutamente la mejor práctica, pero si eso no es lo que le ha estado sucediendo a su empleador hasta ahora, moviendo su dedo hacia ellos y pidiendo decenas de miles de libras para un equipo SWAT por algo que ellos pueden sentir es su culpa (¡aunque sea injustificado! ) no suena como la opción práctica.

La ayuda de su ISP aquí será bastante crucial: algunos ISP proporcionar un servidor de consola y entorno de arranque de red (enchufe, pero al menos sabe qué tipo de servicio buscar) que le permitirá administrar el servidor mientras está desconectado de la red. Si esto es una opción, pídelo y úsalo.

Pero a largo plazo, debe planificar una reconstrucción del sistema basada en la publicación de Robert y una auditoría de cada sitio y su configuración. Si no puede agregar un administrador de sistema a su equipo, busque un alojamiento gestionado trate de pagar a su ISP por la ayuda de administrador de sistemas y la respuesta de 24 horas para este tipo de cosas. Buena suerte :)


49
2018-01-03 13:48





Necesita reinstalar. Guarda lo que realmente necesitas. Pero tenga en cuenta que todos sus archivos ejecutables pueden estar infectados y manipulados. Escribí lo siguiente en python: http://frw.se/monty.py que crea MD5-sumbs de todos sus archivos en un directorio determinado y la próxima vez que lo ejecute, verifica si se ha cambiado algo y luego muestra qué archivos se cambiaron y qué se cambiaron en los archivos.

Esto podría ser útil para usted, para ver si los archivos extraños se cambian regularmente.

Pero lo único que debes hacer ahora es eliminar tu computadora de Internet.


38
2018-05-08 08:02



Entonces ... has implementado Tripwire. - womble♦
Sí, algo malo con eso? - Filip Ekberg
+1 para desenchufar, analizar (hacer que alguien haga un análisis forense real) y limpiar - Oskar Duveborn
Dada la opción entre un script anónimo de Python y una solución estándar documentada, (en cierto modo) compatible y bien entendida, ¿espera que elijan la primera? - tripleee


NOTA: Esto no es una recomendación. Mi especifico Respuesta al incidente protocolo probablemente no lo haría No se aplica sin modificaciones al caso de Grant unwin.

En nuestras instalaciones académicas tenemos alrededor de 300 investigadores que solo hacen computación. Tienes 600 clientes con sitios web, por lo que tu protocolo probablemente será diferente.

Los primeros pasos en nuestra Cuando un servidor obtiene un protocolo comprometido es:

  1. Identifique que el atacante pudo obtener root (privilegios elevados)
  2. Desenchufe los servidores afectados. ¿Red o potencia? Por favor mira una discusión separada.
  3. Compruebe todos los demás sistemas
  4. Arranque los servidores afectados desde un cd en vivo
  5. (Opcional) Toma las imágenes de todas las unidades del sistema con dd
  6. Empieza a hacer los forenses post-mortem. Mire los registros, calcule la hora del ataque, encuentre los archivos que se modificaron en ese momento. Tratar de responder a la ¿Cómo? pregunta.

    • En paralelo, planifica y ejecuta tu recuperación.
    • Restablecer todas las contraseñas de usuario y root antes de reanudar el servicio

Incluso si "se han limpiado todas las puertas traseras y los rootkits", no confíe en ese sistema; vuelva a instalarlo desde cero.


34
2018-05-18 22:36



-1 ¿Desenchufar el servidor del poder? ¡Acabas de perder la mitad de tus datos forenses! - Josh Brower
@Josh, ajusté mi respuesta, ahora es neutral en la pregunta Qué desenchufar. - Aleksandr Levchuk
Los análisis forenses de RAM (por ejemplo, / dev / shm) pueden ser útiles. Prefiero desconectar el cable de alimentación (pero intente iniciar sesión y rsync / proc justo antes). También podemos introducir instantáneas frecuentes de VM para que la RAM forense sea posible. Las razones para optar por el cable de alimentación son (1) Cuando realiza análisis forenses en un sistema pirateado, está "pisando toda la escena del crimen"; (2) El kit raíz sigue funcionando: no es tan difícil para el malicioso ejecutar algo (por ejemplo, el borrado del sistema) en Enlace de red hacia abajo evento. Kyle Rankin en su agradable charla de Introducción a los Forenses (goo.gl/g21Ok) recomienda tirar del cable de alimentación. - Aleksandr Levchuk
No hay un tamaño que se adapte a todos los protocolos IR: algunas organizaciones pueden necesitar mantener el sistema comprometido en línea por un tiempo más, por cualquier motivo. (RAM y análisis forense de registro temporal, interacción con los intrusos, etc.) Lo que quiero decir es que sería mejor recomendar un protocolo IR genérico (como el de Jakob Borgs arriba) en lugar de uno que comience con "Desconecte el cable de alimentación del servidor comprometido. " - Josh Brower


En mi experiencia limitada, los compromisos del sistema en Linux tienden a ser más "integrales" que en Windows. Es mucho más probable que los kits de raíz incluyan el reemplazo de binarios del sistema con código personalizado para ocultar el malware, y la barrera para parchear el kernel es un poco menor. Además, es el sistema operativo doméstico para muchos autores de malware. La guía general siempre es reconstruir el servidor afectado desde cero, y es la guía general por una razón.

Formato de ese cachorro.

Pero, si no puedes reconstruir (o los poderes no te dejarán reconstruir contra tu insistencia en que lo necesita), ¿qué buscas?

Como parece que ha pasado un tiempo desde que se descubrió la intrusión, y se realizó una restauración del sistema, es muy probable que las huellas de cómo entraron hayan sido pisoteadas en la estampida para restaurar el servicio. Desgraciado.

El tráfico de red inusual es probablemente el más fácil de encontrar, ya que no implica ejecutar nada en la caja y se puede hacer mientras el servidor está activo y haciendo lo que sea. Suponiendo, por supuesto, su equipo de red permite la expansión de puertos. Lo que encuentre puede o no ser diagnóstico, pero al menos es información. Conseguir tráfico inusual será una fuerte evidencia de que el sistema todavía está comprometido y necesita aplanamiento. Puede ser lo suficientemente bueno como para convencer a TPTB de que un cambio de formato realmente vale la pena el tiempo de inactividad.

Si falla, tome una copia dd de las particiones de su sistema y móntela en otra caja. Comience a comparar contenidos con un servidor en el mismo nivel de parche que el comprometido. Debería ayudarlo a identificar qué se ve diferente (esos md5sums nuevamente) y puede apuntar a áreas pasadas por alto en el servidor comprometido. Esto es un montón de tamizar a través de directorios y binarios, y será bastante laborioso. Incluso puede ser más intensivo en mano de obra que un reformateo / reconstrucción, y puede ser otra cosa a la TPTB para hacer el reformateo que realmente necesita.


28
2018-01-03 14:31



'Dar formato a ese cachorro'. - +1, sabio consejo. Ver también: "Destruye desde la órbita, es la única manera de estar seguro". - Avery Payne


Diría que @Robert Moir, @Aleksandr Levchuk, @blueben y @Matthew Bloch son bastante acertados en sus respuestas.

Sin embargo, las respuestas de los diferentes carteles difieren: algunas son más de alto nivel y hablan sobre los procedimientos que debe tener (en general).

Prefiero separar esto en varias partes separadas 1) Triage, AKA Cómo tratar con los clientes y las implicaciones legales, e identificar a dónde ir a partir de allí (Listado muy bien por Robert y @blueben 2) Mitigación de impacto. 3) respuesta a incidentes 4) Forensics post-mortem 5) Elementos de remediación y cambios de arquitectura.

(Inserte la declaración de respuesta certificada SANS GSC aquí) Basado en experiencias pasadas, diría lo siguiente:

Independientemente de cómo maneje las respuestas de los clientes, las notificaciones, los planes legales y futuros, preferiría centrarme en el problema principal que nos ocupa. La pregunta original del OP realmente solo se refiere directamente al # 2 y al # 3, básicamente, cómo detener el ataque, hacer que los clientes vuelvan a estar en línea lo antes posible en su estado original, que ha sido bien cubierto en las respuestas.

El resto de las respuestas son excelentes y cubren muchas de las mejores prácticas identificadas y las formas de evitar que esto suceda en el futuro y de responder mejor.

Realmente depende del presupuesto del OP y del sector de la industria en el que se encuentra, cuál es la solución deseada, etc.

Tal vez necesitan contratar un SA dedicado en el sitio. Tal vez necesitan una persona de seguridad. O tal vez necesitan una solución totalmente gestionada como Firehost o Rackspace Managed, Softlayer, ServePath, etc.

Realmente depende de lo que funcione para su negocio. Tal vez su competencia principal no está en la administración del servidor y no tiene sentido para ellos intentar desarrollarla. O tal vez ya sean una organización bastante técnica y puedan tomar las decisiones de contratación correctas y formar un equipo dedicado a tiempo completo.


28
2018-01-04 02:21



Sí, depende, lo sabemos. Decir que realmente no ayuda mucho. - DOK