Detección automática de un servidor web comprometido

7

Estoy tratando de averiguar si es posible detectar automáticamente el hecho de que un atacante ha manipulado o modificado los archivos HTML o javascript de un servidor.

Nuestro sitio web, por ejemplo, www.example.com/index.html , cuando se carga en un navegador, también carga https://www.example.com/scripts/example.min.js dentro de una etiqueta <script></script> . Si alguien pirateara de alguna manera mi servidor y cambiara el archivo example.min.js con uno modificado, ¿hay alguna forma en que pueda detectar automáticamente dicha intrusión?

Una forma de hacerlo sería ejecutar un programa en un servidor seguro independiente que consultara enlace cada pocos minutos y comparara el SHA del index.html y example.min.js a los últimos valores buenos conocidos.

Pregunta 1: asumiendo que el intervalo de sondeo es aceptable, ¿es esta una defensa lo suficientemente fuerte? ¿Podría el código malicioso engañar al código de sondeo?

Pregunta 2: - ¿Existe una forma mejor de reducir la ventana de riesgo que no sea la reducción del intervalo de sondeo, lo que genera un tráfico innecesario?

    
pregunta Ruchir Godura 24.08.2015 - 21:22
fuente

3 respuestas

5

Hay una serie de procesos locales que verán los archivos y directorios en busca de cambios, escrituras, eliminaciones y accesos. Cuando ocurren estos eventos, el proceso crea un registro de eventos a través de syslog. Esto puede suceder en un segundo.

Si las entradas de syslog se envían a un servidor remoto (como debería ser), recibirá alertas casi instantáneas sobre los cambios de archivos, sin la posibilidad de "engañar" a nada, sin ningún tráfico web "innecesario".

Hay un software preempaquetado para hacer esto, o también se puede hacer usando scripts personalizados (el software preempaquetado y probado suele ser mejor).

    
respondido por el schroeder 24.08.2015 - 21:36
fuente
3
  

Pregunta 1: asumiendo que el intervalo de sondeo es aceptable, ¿es esta una defensa lo suficientemente fuerte? ¿Podría el código malicioso engañar al código de sondeo?

No, no es una defensa lo suficientemente fuerte. Sí, el código malintencionado puede identificar el servidor / servicio de sondeo por su IP, User Agent, etc. y entregar el archivo limpio a su agente de sondeo mientras continúa brindando archivos maliciosos a otros. Claro, puede intentar prevenir la detección cambiando las IP y los Agentes de Usuario de su agente con regularidad, pero el código malicioso puede adaptarse para detectar su cambio.

Si bien la entrega de contenido diferente en función del cliente es en sí misma algo trivial, el hecho de que el atacante sepa que existe tal salvaguarda no es trivial (es más como una seguridad a través de la oscuridad). La forma en que un atacante puede conocer tal salvaguarda es cuando conoce su arquitectura (amenaza interna) o si pasa por los ciclos de compromiso > fix- > compromise el tiempo suficiente para que pueda reducir la causa de la detección de compromiso.

  

Pregunta 2: - ¿Existe una forma mejor de reducir la ventana de riesgo que no sea la reducción del intervalo de sondeo, lo que genera un tráfico innecesario?

La mejor manera de reducir el riesgo es tener defensa en profundidad :

  • Tenga herramientas de integridad de archivos basadas en host como tripwire para ver los archivos en cuestión.
    • Derrotar esta defensa requerirá un compromiso del host
  • Dependiendo de qué tan sensibles sean los archivos y su nivel de paranoia, configure sus herramientas de implementación para reconstruir sus archivos cada n horas.
    • La derrota de esta defensa requerirá un compromiso de la red.
  • Monitoreo remoto de sus archivos como lo describió.
    • Derrotar esta defensa requerirá 1.) un compromiso de la máquina remota o 2.) suficiente conocimiento / reconocimiento de su sistema.
  • Implemente herramientas de detección / prevención de intrusiones basadas en host como snort , fail2ban , denyhosts para detectar la intrusión.
    • Derrotar esta defensa requerirá un ataque que no genere mucho ruido en los archivos de registro y / o evade la detección basada en firmas, por ejemplo. fallas en la capa de aplicación.
  • Implementar un firewall de aplicación web, por ejemplo. ModSecurity para detectar anomalías en el nivel de la aplicación.
    • Derrotar esto requerirá un ataque de nivel inferior que debería idealmente ser detectado en el punto mencionado anteriormente.

Incluso con todas las medidas anteriores no puede garantizar la seguridad, sin embargo, reducen la superficie de ataque y dificultan un compromiso exitoso y no detectado.

    
respondido por el CodeExpress 25.08.2015 - 03:00
fuente
0

En lo que respecta a la Pregunta 1, sería fácil que el código malicioso engañe al código de sondeo. Como ejemplo, muchos programas maliciosos de PHP miran las cadenas de User Agent y devuelven códigos 404 a Google, Bing, Yahoo y otros. Sería casi tan fácil realizar un seguimiento de las direcciones IP que realizan solicitudes repetitivas, y falsificarlas. Dado un oponente dedicado, todo se convertiría en una carrera de armamentos: quién puede escribir las pruebas más sutiles para la autenticidad, y quién puede falsificar las pruebas sutiles para la autenticidad. Eso no quiere decir que se produzca una carrera de armamentos de este tipo, o que usted personalmente no pueda ganar una carrera de armamentos de este tipo, sino que, en general, código malicioso y código de prueba de tontos.

Creo que su problema está muy relacionado con la dificultad de simplemente monitorear un servicio a través de la red. Incluso algo como una llamada a un procedimiento remoto o una interfaz REST puede ser difícil de monitorear correctamente frente a bugs bastante extraños. Habiendo probado esto en el pasado, puedo asegurarle que terminará en una "carrera de armamentos" contra insectos más raros y raros.

    
respondido por el Bruce Ediger 24.08.2015 - 21:36
fuente

Lea otras preguntas en las etiquetas