Esta es una pregunta canónica sobre la seguridad del servidor: respuesta a eventos de incumplimiento (piratería informática)
Consulte también:

• Consejos para asegurar un servidor LAMP
• ¿Reinstalar después de un compromiso de raíz?

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

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

Versión original

2011.01.02 - Estoy de camino al trabajo a las 9.30 p. M. Un domingo porque nuestro servidor se ha visto comprometido de alguna manera y estaba provocando un ataque de DOS en nuestro proveedor. El acceso de los servidores a Internet se ha cerrado, lo que significa que más de 5-600 de los sitios de nuestros clientes ya no funcionan. Ahora esto podría ser un hack FTP, o alguna debilidad en el código en alguna parte. No estoy seguro hasta que llegue allí.

¿Cómo puedo rastrear esto rápidamente? Nos enfrentaremos a una gran cantidad de litigios si no obtengo el servidor de respaldo lo antes posible. Cualquier ayuda es apreciada. Estamos ejecutando Open SUSE 11.0.

---

2011.01.03 - Gracias a todos por su ayuda. Afortunadamente, no era la única persona responsable de este servidor, solo la más cercana. Logramos resolver este problema, aunque puede que no se aplique a muchos otros en una situación diferente. Detallaré lo que hicimos.

Desconectamos el servidor de la red. Estaba realizando (intentando realizar) un ataque de Denegación de Servicio en otro servidor en Indonesia, y la parte culpable también estaba allí.

En primer lugar, tratamos de identificar de qué parte del servidor provenía esto, teniendo en cuenta que tenemos más de 500 sitios en el servidor, esperábamos estar ocultos durante algún tiempo. Sin embargo, con el acceso SSH aún, ejecutamos un comando para encontrar todos los archivos editados o creados en el momento en que comenzaron los ataques. Afortunadamente, el archivo ofensivo se creó durante las vacaciones de invierno, lo que significa que no se crearon muchos otros archivos en el servidor en ese momento.

Luego pudimos identificar el archivo ofensivo que estaba dentro de la carpeta de imágenes cargadas dentro de un sitio web de ZenCart .

Después de un breve descanso para fumar, concluimos que, debido a la ubicación de los archivos, debe haber sido cargado a través de una instalación de carga de archivos que no estaba asegurada adecuadamente. Después de buscar en Google, descubrimos que había una vulnerabilidad de seguridad que permitía cargar archivos, dentro del panel de administración de ZenCart, para una imagen para una compañía discográfica. (La sección que en realidad nunca usó), al publicar este formulario, se subió cualquier archivo, no se verificó la extensión del archivo y ni siquiera se verificó si el usuario había iniciado sesión.

Esto significaba que cualquier archivo podía cargarse, incluido un archivo PHP para el ataque. Aseguramos la vulnerabilidad con ZenCart en el sitio infectado y eliminamos los archivos ofensivos.

El trabajo estaba hecho y yo estaba en casa a las 2 de la mañana.

---

La Moraleja : siempre aplique parches de seguridad para ZenCart o cualquier otro sistema CMS. Como cuando se lanzan las actualizaciones de seguridad, todo el mundo se da cuenta de la vulnerabilidad. - Siempre haga copias de seguridad y respalde sus copias de seguridad. - Emplee o haga arreglos para alguien que estará allí en momentos como estos. Para evitar que alguien confíe en una publicación de pánico en Server Fault.

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

No se asuste

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

1. Es difícil determinar cuándo ocurrió la intrusión.
2. No le ayuda a cerrar el "agujero" que les permitió entrar por última vez, ni a lidiar con las consecuencias de cualquier "robo de datos" que también pudo haber tenido lugar.

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, eso depende de usted. Pero seguirlos adecuadamente 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, puede que no. No sabes de ninguna manera, ¿verdad?
3. Verifica tus otros sistemas. Preste especial atención a otros servicios orientados a Internet y a aquellos que contienen datos financieros u otros datos comerciales sensibles.
4. Si el sistema contiene los datos personales de alguien, informe inmediatamente a la persona responsable de la protección de datos (si no es usted) e INSTA a una divulgación completa. 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 la empresa tendrá que lidiar con eso, y debe hacerlo con la vista puesta en todas y cada una de las leyes de privacidad relevantes.

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 voy a vincular a esa publicación para que la gente pueda reírse de forma barata, pero la verdadera tragedia es cuando la gente no puede aprender 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 "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. (por ejemplo, si sus sistemas se vieron comprometidos por un ataque de inyección SQL, entonces no solo necesita cerrar la línea de código defectuosa en particular por la que entraron, sino que también deberí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".

¿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 asegurarse de que tiene el control del sistema es reconstruirlo. Si bien hay mucho valor en encontrar y corregir el exploit utilizado para entrar en el sistema, no puede estar seguro de qué más se le ha hecho una vez que los intrusos obtuvieron el control (de hecho, no es inaudito para los piratas informáticos que reclutan sistemas en una botnet para parchear los exploits que usaron ellos mismos, para proteger "su" nueva computadora de otros hackers, así como instalar su rootkit).

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 otros 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 ser adecuadamente 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 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 entrar en 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. De nuevo, 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 se ven 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.

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

Parece que estás un poco 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 necesita a alguien para clasificar a los clientes; Sin duda, alguien ya lo es. Alguien necesita estar al teléfono con ellos para explicarles lo que está sucediendo, lo que se está haciendo para manejar la situación y responder 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 informado a su gerente y equipo ejecutivo de las principales acciones que realice; esto incluye trabajar con un equipo de respuesta, deshabilitar servidores, hacer copias de seguridad de datos y volver a poner las cosas en línea. No necesitan detalles sangrientos, pero deberían saber de usted cada 30 minutos más o menos.

2. Ser realista. No eres un profesional de seguridad, y hay cosas que no sabes. Está bien. Al iniciar sesión en los servidores y mirar los datos, debe comprender sus límites. Pisar suavemente. En el curso de su investigación, asegúrese de no pisotear información vital o cambiar algo que pueda necesitarse más adelante. Si te sientes incómodo o estás adivinando, es un buen lugar para detenerte y conseguir que un profesional experimentado se haga cargo.

3. Obtenga una memoria USB limpia y discos duros de repuesto. Recolectarás evidencia aquí. Haga copias de seguridad de todo lo que sienta que puede ser relevante; comunicación con su ISP, descargas de red, etc. Incluso si la policía no se involucra, en caso de una demanda, querrá que esta evidencia pruebe que su empresa manejó el incidente de seguridad de 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, debe tirar de su cable de red; si no puedes, tira del poder.

5. A continuación, debe quitar el atacante y cerrar los agujeros. Presumiblemente, el atacante ya no tiene acceso interactivo porque desconectó la red. Ahora necesita identificar, documentar (con copias de seguridad, capturas de pantalla y sus propias notas de observación personales; o preferiblemente incluso quitando las unidades de los servidores afectados y haciendo una copia completa de la imagen del disco), y luego eliminar cualquier código y procesos que dejó . La siguiente parte apestará si no tienes copias de seguridad; Puede intentar desenredar al atacante del sistema a mano, pero nunca estará seguro de tener todo lo que dejó atrás. Los rootkits son viciosos, y no todos son detectables. La mejor respuesta será identificar la vulnerabilidad que solía tener, hacer copias de imagen de los discos afectados, y luego borrar los sistemas afectados y volver a cargarlos desde una copia de seguridad buena conocida. Don' No confíes ciegamente en tu respaldo; verificarlo! Repare o cierre la vulnerabilidad antes de que el nuevo host vuelva a conectarse a la red y luego conéctelo.

6. Organice todos sus datos en un informe. En este punto, la vulnerabilidad está cerrada y tienes tiempo para respirar. No caigas en la tentación de saltarte este paso; Es aún 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 para su gestión y como defensa en una demanda potencial.

Esa es una revisión altísima de qué hacer; la mayor parte del trabajo es simplemente documentación y manejo de respaldo. No se asuste, puede hacer eso. Yo fuertemente recomiendo que llegue la ayuda profesional de seguridad. Incluso si puede manejar lo que está sucediendo, su ayuda será invaluable y generalmente vienen con equipos para hacer el proceso 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.

CERT tiene un documento Pasos para recuperarse de un compromiso del sistema UNIX o NT que es bueno. Los detalles técnicos específicos de este documento están algo 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 o gestión de seguridad.
• Obtenga el control (desconecte la computadora)
• Analice la intrusión, obtenga registros, calcule qué salió mal
• Reparar cosas
  • ¡Instale una versión limpia de su sistema operativo! Si el sistema se ha visto comprometido, no puede confiar en él, punto.
• Actualice los sistemas para que esto no vuelva a suceder.
• Reanudar operaciones
• Actualice su política para el futuro y documente

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

E.1 Tenga en cuenta que si una máquina se ve comprometida, cualquier cosa en ese sistema podría haberse modificado, incluido el núcleo, los archivos binarios, los archivos de datos, los procesos en ejecución y la memoria. En general, la única forma de confiar en que una máquina está libre de puertas traseras y modificaciones de intrusos es reinstalar el funcionamiento

Si aún no tiene un sistema como Tripwire, no hay forma posible de que esté 100% seguro de haber limpiado el sistema.

1. Identifica el problema. Lee los registros.
2. Contener . Has desconectado el servidor, así que ya está.
3. Erradicar . Vuelva a instalar 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 viejo para recuperar trucos feos que no fueron respaldados y hacer análisis forenses para descubrir qué sucedió.
4. Recuperarse . Instale lo que sea necesario y recupere copias de seguridad para que sus clientes estén en línea.
5. Seguimiento . Averigua cuál fue el problema y evita que vuelva a suceder.

La respuesta de la "píldora amarga" de Robert es acertada pero completamente genérica (bueno, como fue su pregunta). Parece que tiene un problema de administración y necesita urgentemente un administrador de sistemas a tiempo completo si tiene un servidor y 600 clientes, pero eso no lo ayuda ahora.

Dirijo una empresa de alojamiento que ofrece un poco de ayuda en esta situación, por lo que trato con muchas máquinas comprometidas, pero también trato con las mejores prácticas para nosotros. 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 sea la víctima de un script kiddy que quería una plataforma de lanzamiento para ataques DoS, o rebotes IRC, o algo completamente ajeno a los sitios y datos de sus 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, puede hacer que su caja comprometida sea inútil para quien la tome prestada y mitigar el efecto en la red de su proveedor a cero.

Este proceso puede tomar algunas horas si no lo ha hecho antes y nunca ha considerado un firewall, pero podría ayudarlo a restaurar el servicio de sus clientes con el riesgo de continuar dando acceso al atacante a los datos de sus clientes . Dado que usted 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 poner su sistema en línea más rápido que auditar 600 sitios en busca de errores de seguridad antes de que vuelva a traer algo. Pero sabrá qué datos hay y qué tan cómodo se sentiría al tomar esa decisión.

Esto no es una práctica recomendada, pero si eso no es lo que le ha estado sucediendo a su empleador hasta el momento, mover su dedo hacia ellos y pedirles decenas de miles de libras a un equipo SWAT por algo que puedan sentir que es su culpa (¡aunque esté injustificado! ) no suena como la opción práctica.

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

Pero a largo plazo, debe planear 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 sistemas a su equipo, busque un acuerdo de alojamiento administrado en el que pague a su ISP por ayuda de administración de sistemas y respuesta las 24 horas para este tipo de cosas. Buena suerte :)

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

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

Pero lo único que debe hacer ahora es quitar su computadora de internet.

NOTA: Esto no es una recomendación. Mi protocolo específico de Respuesta a Incidentes probablemente no se aplica sin modificaciones al caso de Grant unwin.

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

Los primeros pasos en nuestro 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 poder? Por favor, vea una discusión por separado .
3. Verifique todos los otros sistemas
4. Arranque los servidores afectados desde un CD en vivo
5. (opcional) Tome las imágenes de todas las unidades del sistema condd

6. Comience a hacer el análisis forense post mortem. Mire los registros, calcule la hora del ataque, encuentre los archivos que se modificaron en ese momento. Intenta contestar el ¿Cómo? pregunta.

   • En paralelo, planifique y ejecute su recuperación.
   • Restablezca todas las contraseñas de usuario y root antes de reanudar el servicio.

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

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 núcleo es un poco menor. Además, es el sistema operativo hogareño para muchos autores de malware. La guía general es siempre reconstruir el servidor afectado desde cero, y es la guía general por una razón.

Formatea ese cachorro.

Pero, si no puede reconstruir (o los poderes fácticos no le permitirán reconstruirlo contra su insistente insistencia de que lo necesita), ¿qué busca?

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 los rastros de cómo ingresaron hayan sido pisoteados 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 eso no implica ejecutar nada en la caja y se puede hacer mientras el servidor está activo y haciendo lo que sea. Suponiendo, por supuesto, que 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. Obtener tráfico inusual será una fuerte evidencia de que el sistema aún está comprometido y necesita ser aplanado. Puede ser lo suficientemente bueno como para convencer a TPTB de que un reformateo realmente vale el tiempo de inactividad.

De lo contrario, tome una copia dd de las particiones de su sistema y móntelas en otra caja. Comience a comparar contenido con un servidor en el mismo nivel de parche que el comprometido. Debería ayudarlo a identificar lo que se ve diferente (esos md5sums nuevamente) y puede apuntar a áreas ignoradas en el servidor comprometido. Esto es MUCHO tamizar a través de directorios y binarios, y será bastante laborioso. Incluso puede ser más laborioso de lo que sería un reformateo / reconstrucción, y puede ser otra cosa para golpear a TPTB sobre hacer el reformateo que realmente necesita.

Yo 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 implementados (en general).

Prefiero separar esto en varias partes separadas 1) Triaje, AKA Cómo tratar con los clientes y las implicaciones legales, e identificar a dónde ir desde allí (enumerado muy bien por Robert y @blueben 2) Mitigación del impacto 3 ) Respuesta a incidentes 4) Análisis forense post mortem 5) Elementos de remediación y cambios de arquitectura

(Inserte aquí la declaración de respuesta certificada SANS GSC estándar) Con base 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 en cuestión. La pregunta original del OP realmente solo se refiere directamente a # 2 y # 3, básicamente, cómo detener el ataque, lograr 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 formas de evitar que suceda en el futuro y de responder mejor.

Realmente depende del presupuesto del OP y en qué sector de la industria se encuentran, cuál es su solución deseada, etc.

Tal vez necesiten contratar una SA dedicada en el sitio. Quizás necesiten una persona de seguridad. O tal vez necesitan una solución totalmente administrada, 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 que intenten desarrollar eso. O, tal vez ya sean una organización bastante técnica y puedan tomar las decisiones de contratación correctas y contar con un equipo dedicado a tiempo completo.

Después de ponernos a trabajar y echar un vistazo al servidor, logramos resolver el problema. Afortunadamente, los archivos ofensivos se cargaron al sistema un domingo, cuando la oficina está cerrada y no se deben crear archivos, aparte de los registros y los archivos de caché. Con un simple comando de shell para averiguar qué archivos se crearon ese día, los encontramos.

Todos los archivos ofensivos parecen haber estado dentro de la carpeta / images / en algunos de nuestros sitios más antiguos de zencart. Parece que hubo una vulnerabilidad de seguridad que permitió (usando curl) a cualquier idiota subir imágenes que no sean en la sección de carga de imágenes en la sección de administración. Eliminamos los archivos .php ofensivos y arreglamos los scripts de carga para rechazar cualquier carga de archivos que no sean imágenes.

En retrospectiva, fue bastante simple y planteé esta pregunta en mi iPhone de camino al trabajo. Gracias por toda su ayuda chicos.

Para referencia de cualquiera que visite esta publicación en el futuro. Yo no recomendaría tirar del enchufe de alimentación.

Tengo poco que aportar a las amplias respuestas técnicas, pero también tenga en cuenta algunas de estas:

Acciones no técnicas:

• Reporte el incidente internamente.
  Si aún no tiene un plan de respuesta a incidentes, puede parecer una técnica CYA, pero el departamento de TI no es el único y, a menudo, ni siquiera el mejor lugar para determinar el impacto comercial de un servidor comprometido.
  Los requisitos comerciales pueden superar sus preocupaciones técnicas. No diga "se lo dije" y que la prioridad de las preocupaciones comerciales es la razón por la que tiene este servidor comprometido en primer lugar. (" Deje eso para el informe posterior a la acción ").

• Encubrir un incidente de seguridad no es una opción.

• Informar a las autoridades locales.
  ServerFault NO es el lugar para asesoría legal, pero esto es algo que debe incluirse en un plan de respuesta a incidentes.
  En algunas localidades y / o industrias reguladas, es obligatorio informar (ciertos) incidentes de seguridad a las fuerzas del orden locales, los organismos reguladores o informar a los clientes / usuarios afectados.
  De todos modos, ni la decisión de informar ni el informe real se toman únicamente en el departamento de TI. Espere la participación de la gerencia y los departamentos de comunicaciones legales y corporativas (marketing).
  Probablemente no debería esperar demasiado, Internet es un gran lugar donde las fronteras tienen poco significado, pero los departamentos de delitos cibernéticos que existen en muchos departamentos de policía resuelven los delitos digitales y pueden llevar a los culpables ante la justicia.

Creo que todo se reduce a esto:

Si valora su trabajo, será mejor que tenga un plan y lo revise regularmente.

No planificar es fallar, y no es más cierto en ningún otro lado que en la seguridad de los sistemas. Cuando <redactado> golpea al ventilador, será mejor que estés listo para lidiar con eso.

Hay otro dicho (algo cliché) que se aplica aquí: más vale prevenir que curar .

Aquí ha habido una serie de recomendaciones para que los expertos auditen sus sistemas existentes. Creo que esto es hacer la pregunta en el momento equivocado. Esta pregunta debería haberse hecho cuando se puso en marcha el sistema y se documentaron las respuestas. Además, la pregunta no debería ser "¿Cómo podemos evitar que las personas entren"? Debería ser "¿Por qué las personas deberían poder entrar?" La auditoría de un montón de agujeros en su red solo funcionará hasta que se encuentren y exploten nuevos agujeros. Por otro lado, las redes que están diseñadas desde cero para responder solo de ciertas maneras a ciertos sistemas en un baile cuidadosamente coreografiado no se beneficiarán de una auditoría y los fondos serán un desperdicio.

Antes de poner un sistema en Internet, pregúntese: ¿esto debe ser 100% orientado a Internet? Si no, no lo hagas. Considere colocarlo detrás de un firewall donde pueda decidir qué ve Internet. Aún mejor, si dicho firewall le permite interceptar las transmisiones (a través de un proxy inverso o un filtro de paso de algún tipo), mire cómo usarlo para permitir que solo ocurran acciones legítimas.

Esto se ha hecho: hay (o hubo) una configuración de banca por Internet en algún lugar que tiene un proxy de equilibrio de carga frente a Internet que iban a usar para vectorizar ataques fuera de su grupo de servidores. El experto en seguridad Marcus Ranum los convenció de que adoptaran el enfoque opuesto, utilizando el proxy inverso para permitir solo URL válidas conocidas y enviar todo lo demás a un servidor 404 . Soportó la prueba del tiempo sorprendentemente bien.

Un sistema o red basado en el permiso predeterminado está condenado a fallar una vez que ocurre un ataque que no previó. La denegación predeterminada le brinda un control mucho mayor sobre lo que entra y lo que no, porque no permitirá que nada en el interior se vea desde el exterior a menos que sea necesario .

Dicho esto, todo esto no es motivo para ser complaciente. Aún debe tener un plan establecido durante las primeras horas después de una infracción. Ningún sistema es perfecto y los humanos cometen errores.

Un buen en línea me ayudó recientemente a descubrir cómo un atacante podría comprometer un sistema. Algunos crackers intentan ocultar sus rastros falsificando el tiempo de modificación en los archivos. Al cambiar el tiempo de modificación, el tiempo de cambio se actualiza (ctime). Puedes ver el ctime con stat.

Este revestimiento enumera todos los archivos ordenados por ctime:

find / -type f -print0 | xargs -0 stat --format '%Z :%z %n' | sort -nr > /root/all_files.txt

Entonces, si conoce aproximadamente el momento del compromiso, puede ver qué archivos se cambian o se crean.