Descubrir cómo se hackeó un servidor pirateado

Estaba navegando por el sitio y encontré esta pregunta: Mi servidor ha sido hackeado EMERGENCIA . Básicamente la pregunta dice: mi servidor ha sido pirateado. ¿Qué tengo que hacer?

La mejor respuesta es excelente, pero me planteó algunas preguntas. Uno de los pasos sugeridos es:

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.

No he hecho ningún trabajo de administrador del sistema, así que no tengo idea de cómo comenzaría a hacerlo. ¿Cuál sería el primer paso? Sé que podría buscar en los archivos de registro del servidor, pero como atacante, lo primero que haría sería borrar los archivos de registro. ¿Cómo "entenderías" cómo tuvieron éxito los ataques?

Comenzaré diciendo esto, si NO TIENE ARCHIVOS DE REGISTRO , entonces hay una posibilidad razonablemente buena de que NUNCA entenderá dónde o cómo tuvo éxito el ataque. Incluso con archivos de registro completos y correctos, puede ser extremadamente difícil comprender completamente quién, qué, dónde, cuándo, por qué y cómo.

Entonces, sabiendo lo importantes que son los archivos de registro, comienza a comprender cuán seguro tiene que mantenerlos. Es por eso que las empresas hacen y deberían invertir en información de seguridad y gestión de eventos o SIEM para abreviar.

En pocas palabras, la correlación de todos sus archivos de registro en eventos específicos (basados ​​en el tiempo o no) puede ser una tarea extremadamente desalentadora. Eche un vistazo a los syslogs de su firewall en modo de depuración si no me cree. ¡Y eso es solo de un aparato! Un proceso SIEM coloca estos archivos de registro en una serie de eventos lógicos que hacen que descubrir lo que sucedió sea mucho más fácil de entender.

Para comenzar a comprender mejor el cómo, es útil estudiar las metodologías de penetración .

También es útil saber cómo se escribe un virus . O cómo escribir un rootkit .

También puede ser extremadamente beneficioso configurar y estudiar un honeypot .

También ayuda tener un analizador de registros y ser competente con él.

Es útil recopilar una línea de base para su red y sistemas. ¿Qué es el tráfico "normal" en su situación frente al tráfico "anormal"?

CERT tiene una excelente guía sobre qué hacer después de que su computadora ha sido pirateada, más notablemente (que corresponde directamente a su pregunta específica) la sección sobre "Analizar la intrusión":

• Busque modificaciones realizadas en el software del sistema y los archivos de configuración
• Busque modificaciones en los datos.
• Busque las herramientas y los datos que dejó el intruso.
• Revisar archivos de registro
• Busque signos de un sniffer de red
• Verifique otros sistemas en su red
• Verifique los sistemas involucrados o afectados en sitios remotos

Hay muchas preguntas similares a las suyas que se han formulado en SF:

1. Cómo hacer una autopsia de un hack de servidor
2. Elementos extraños en el archivo de hosts y Netstat
3. ¿Es este un intento de pirateo?
4. ¿Cómo puedo aprender Linux desde el punto de vista de piratería o seguridad?

Este puede ser un proceso extremadamente complicado e involucrado. La mayoría de las personas, incluido yo, solo contrataría a un consultor si se involucrara más de lo que mis dispositivos SIEM podrían reunir.

Y, aparentemente, si alguna vez quiere COMPLETAMENTE cómo se piratearon sus sistemas, debe pasar años estudiándolos y abandonar a las mujeres.

La respuesta a ese pequeño bit puede ser de un millón de millas de ancho y alto, y desentrañar lo que le sucedió a un servidor pirateado puede ser casi una forma de arte tanto como cualquier otra cosa, así que nuevamente daré puntos de partida y ejemplos en lugar de un conjunto definitivo de pasos a seguir.

Una cosa a tener en cuenta es que una vez que haya enfrentado una intrusión, puede auditar su código, la administración / configuración de sus sistemas y los procedimientos con el conocimiento de que definitivamente hay una debilidad allí. Eso ayuda a impulsar la motivación más que la búsqueda de una debilidad teórica que puede o no estar allí. Muy a menudo las personas ponen cosas en línea mientras saben que el código podría haber sido auditado un poco más difícil, si solo tuviéramos el tiempo; o el sistema se bloqueó un poco más firmemente, si no fuera tan inconveniente; o procedimientos un poco más estrictos, si tan solo no fuera una molestia para el jefe recordar contraseñas largas. Todos sabemos dónde están nuestros puntos débiles más probables, así que comience con esos.

En un mundo ideal, tendrá registros almacenados en un servidor syslog diferente (con suerte no comprometido) , no solo de los servidores sino de cualquier firewall, enrutador, etc. que también registre el tráfico. También hay herramientas como Nessus disponibles que pueden analizar un sistema y buscar debilidades.

Para software / framworks de terceros, a menudo hay guías de mejores prácticas que puede usar para auditar su implementación, o puede prestar más atención a las noticias de seguridad y los horarios de parches y descubrir algunos agujeros que podrían haberse utilizado.

Por último, la mayoría de las intrusiones dejan un spoor ... si tienes el tiempo y la paciencia para encontrarlo. Las intrusiones para niños con guiones "Drive by" o las intrusiones mediante kits de herramientas de piratería tienden a centrarse en las debilidades comunes y pueden dejar un patrón que lo orienta en la dirección correcta. Lo más difícil de analizar puede ser una intrusión dirigida manualmente (por ejemplo, alguien no quería piratear "un" sitio web, sino que quería piratear "su" sitio web específicamente), y estas son, por supuesto, las cosas más importantes para entender.

Para alguien que realmente no sabe por dónde comenzar (o incluso para personas experimentadas que tienen otras tareas), el primer paso es probablemente contratar a alguien con buena experiencia en los pasos anteriores. Otra ventaja de ese enfoque es que analizarán su configuración sin ninguna noción preconcebida o interés personal en las respuestas.

"Sé que puedes mirar en los archivos de registro del servidor, pero como atacante, lo primero que haría sería borrar los archivos de registro".

Dependiendo del tipo de compromiso, el atacante puede no tener privilegios lo suficientemente altos en el servidor comprometido para poder borrar los registros. También es una buena práctica mantener los registros del servidor fuera de caja en otro servidor, para evitar la manipulación (exportados automáticamente a ciertos intervalos).

Más allá de los registros comprometidos del servidor, todavía hay registros de red (firewall, enrutador, etc.), así como registros de autenticación del servicio de directorio, si hay uno (Active Directory, RADIUS, ect)

Por lo tanto, mirar los registros sigue siendo una de las mejores cosas que se pueden hacer.

Cuando se trata de una caja comprometida, examinar los registros siempre es una de mis principales formas de reconstruir lo que sucedió.

-Josh