Detección de inyección de código en servidores web

4

Recientemente encontré uno de mis servidores web pirateado con un código malicioso inyectado en sitios web alojados allí. No fue exactamente mi culpa, ya que compartí el servidor con otras personas y alguien puso un script / sitio web inseguro en el servidor. Por suerte para mí no hubo daños ni pérdida de datos. Pero me dejó pensando. Me enteré de la violación totalmente por accidente. Simplemente intenté extraer algunas actualizaciones de otro script de mi repositorio de Git y me devolvió un error sobre los archivos modificados sin confirmar en mi copia de trabajo.

En la mayoría de los casos, no hay acceso al shell en servidores web (alojamiento compartido) y usted actualiza los sitios web subiéndolos a través de FTP y simplemente sobrescribiendo archivos. ¿Cómo detectar la inyección de código es tal situación?

Y qué pasa con la situación en la que tiene acceso al shell en su servidor web. ¿Hay alguna otra (y mejor) forma / herramienta para detectar la inyección de código?

    
pregunta Michal M 19.02.2012 - 23:10
fuente

2 respuestas

5

Resumen. La mejor defensa contra la inyección de código es evitarlo en primer lugar. En general, una vez que el código malicioso se ha introducido en su sistema, no existe una forma confiable de detectarlo. Sé que estaba preguntando sobre la detección, pero le recomiendo que se se centre en la prevención , no en la detección.

Prevención. Entonces, ¿cómo se evita la inyección de código? En general, a través del control de acceso, la buena higiene de seguridad y los procesos seguros de desarrollo de software.

  • Si tiene un servidor web, no lo comparta con otras personas. Es bastante fácil usar la virtualización para proporcionar aislamiento entre varios inquilinos. Por ejemplo, si compra un alojamiento compartido de un servicio de alojamiento compartido comercial, utilizarán algún tipo de virtualización para aislar a sus clientes entre sí. (Esto no tiene nada que ver con el acceso FTP frente al acceso de shell. Mientras los clientes estén aislados entre sí, no importa si el proveedor de alojamiento proporciona acceso de shell o acceso de FTP. Solo necesitan asegurarse de que otros clientes obtengan acceda solo a sus contenedores virtuales, y no a los suyos.) Del mismo modo, no comparta sus contraseñas o claves criptográficas con otros.

  • Practique buenas prácticas de administración de sistemas para evitar que su servidor se vea comprometido. Mantenga su software totalmente actualizado y parcheado. Use los cortafuegos para limitar el acceso solo a los servicios que desea exponer. Utilice SSH con autenticación de clave pública para el inicio de sesión remoto. Si necesita utilizar contraseñas, asegúrese de elegir contraseñas largas y seguras, nunca las comparta y solo envíelas por canales cifrados.

  • Practique buenos procesos de desarrollo de software. Evite introducir vulnerabilidades de seguridad en el software que escribe. Se han escrito libros completos sobre cómo hacer eso, así que no intentaré explicar en detalle aquí; Simplemente lo marcaré como algo que es importante, para garantizar que el software esté libre de vulnerabilidades de seguridad.

respondido por el D.W. 20.02.2012 - 02:08
fuente
1

En parte, estoy de acuerdo con DW , la prevención es mayor que la detección pero solo cuando funciona. Una vez que su máquina se vea comprometida, se pateará por no tener implementados mecanismos de detección mejores (¡o ninguno!). En general, trato de dividir mi enfoque en ambos, y en algunos puntos la detección puede obtener un poco más de atención.

Alguien con su perfil de riesgo (propietario de una pequeña empresa con un proveedor de alojamiento compartido básico, etc.), generalmente no tiene la capacidad de gastar el tiempo, dinero y esfuerzo o hacer los cambios necesarios para invertir completamente en una solución de seguridad. Recomendaría un enfoque de 3 puntas que consiste en prevención , detección y recuperación .

Nota, esta no es una discusión exhaustiva sobre cada una de estas "puntas", sino que están aquí para poner en marcha sus pensamientos. ¡Me encantaría escuchar lo que decida implementar, junto con el de cualquier otra persona!

Prevention

No dedicaré mucho tiempo a la prevención, hay mucho que cubrir. D.W. señaló algunos puntos de partida en su publicación , y hay un montón de recursos en línea relacionados con la codificación segura. Le sugiero que comience con las guías de OWASP y Mozilla:

enlace

enlace

enlace

enlace

Detection

Algunos programas maliciosos modernos (y los intrusos) tienen la capacidad de enraizarse tan profundamente en las entrañas del sistema operativo de la víctima que la eliminación verificable parece imposible. Sin embargo, no sugeriría poner todos sus huevos en una canasta, por ejemplo, solo enfocándose en la prevención. Enfocarse solo en la prevención deja mucho espacio después del compromiso que podría haber estado reuniendo artefactos y pruebas.

Los entornos de alojamiento compartido no siempre son los mejores para su personalización en términos de lo que debe suceder para una iniciativa de seguridad, por lo que es muy dependiente del proveedor. (consulte ¿Cómo mantener seguro un servidor de alojamiento web compartido? )

Es probable que su incidente forme parte de un compromiso masivo, por ejemplo, la inyección de SQL de un sitio en su host compartido que lleve al compromiso del sistema operativo. Ese script luego busca * .php para inyectarse en. Una vez infectado, el gusano / atacante pasa al siguiente host (es). Si bien esto puede no ser exactamente lo que sucedió, es un caso común y demuestra un patrón de ataque común que no es un ataque sofisticado o una tarea imposible de detectar y limpiar.

Dependiendo de lo que se pueda implementar localmente, su mejor opción es utilizar un servicio de terceros que busque signos de infecciones, por ejemplo,

enlace

enlace

Otra opción es usar un script simple para comparar las sumas de comprobación de todos tus archivos y enviarte un correo electrónico cuando sea diferente. Luego, podría usar los ganchos de git para actualizar la configuración de su script con las sumas de verificación "buenas" actuales. También he tenido suerte con scripts simples como este para otras cosas, por ejemplo, verificación de certificados SSL, verificación de encabezados, etc.

Recuperación

Ahora que tiene instalado un mecanismo de detección, ¿qué sucede cuando recibe ese temido correo electrónico a las 3 am? Tener un proceso claro en el lugar reducirá en gran medida el tiempo de inactividad y los cabellos grises.

Como mencionó git en su pregunta, asumiré que usted es un usuario actual. Hay algunas publicaciones buenas sobre cómo usar Git para administrar un sitio web. Recomendaría utilizar un proceso similar al detallado en:

enlace

enlace

enlace

Recuerde, ese es solo su código, no necesariamente todos sus datos, por ejemplo, bases de datos y contenido cargado.

    
respondido por el Gerry 21.02.2012 - 17:59
fuente

Lea otras preguntas en las etiquetas