¿Cómo sabe que su servidor ha sido comprometido?

UPDATED

Verificaría lo siguiente:

1. Registros. Si tienes acceso de root, deberías verificar cosas como history que te dará el historial de comandos y los archivos de registro en /var/logs .

2. Línea de base. Si tiene una línea de base como hashes de archivos con los que trabajar para aplicaciones y archivos de sistema, esto será de gran ayuda. También puede utilizar copias de seguridad para comparar un estado anterior. Si usa una copia de seguridad para comparar archivos, use una más antigua si puede. Es posible que el sitio haya estado comprometido hace un tiempo y es solo ahora que se ha activado la redirección.

3. Comprueba cualquier incluye. Los archivos pueden no estar en su servidor. Pueden ser secuencias de comandos incluidas como etiquetas de tipo <script src=”http://baddomain.com/s.js” /> o iframe . Además, no excluya imágenes, archivos PDF de Flash (SWF), archivos de video. Es un truco bastante común para incrustar enlaces en archivos de un tipo de contenido diferente. Le sugiero que los inspeccione a mano, especialmente al principio y al final de un archivo. El archivo puede ser completamente un enlace / html / javascript o puede ser un archivo de imagen legítimo con un enlace al final del archivo.

4. Compruebe si hay fechas, tamaños y permisos inusuales de archivos, por ejemplo. 777.

5. Revisa los trabajos cron para trabajos inusuales. Alguien que está comprometiendo un sistema a menudo dejará una puerta trasera para volver a entrar una y otra vez. Cron es una forma muy popular de hacerlo si lograron llegar tan lejos.

6. Comprueba la ausencia de archivos, es posible que no puedas acceder a los registros, pero su ausencia es igualmente una señal de que alguien ha limpiado después de ellos mismos.

7. Usa motores de búsqueda. No es sorprendente que los motores de búsqueda sean excelentes para encontrarlo todo. Use directivas como site: e.g. site:yoursitehere.com baddomain.com ve si recibes algún golpe.

8. A menudo se confunde un enlace o una redirección, por lo que el código javascript largo con variables de una sola letra debe analizarse cuidadosamente.

9. Realice una captura de paquetes con una herramienta como Wireshark o tcpdump desde una estación de trabajo segura al sitio. Guárdelo en un archivo y busque en el archivo una parte de la URL.

10. Compruebe los registros de la base de datos que pueden consultarse o actualizarse. El enlace podría ser inyectado en la base de datos, no en el PHP.

11. No excluya la estación de trabajo del cliente. Utilice un escáner de virus en línea gratuito si es necesario. También verifique nslookup y vea a qué se resuelve. Verifique las extensiones del navegador, borre la caché y verifique los archivos hosts .

Para limpiarlo (si está comprometido), realmente necesita volver al metal y reinstalarlo. Es doloroso, pero en realidad es la única forma de estar seguro de que lo tienes todo.

Para evitarlo en el futuro, debería hacer lo siguiente (aunque es posible que ya esté haciendo algo de esto):

1. Servidores Harden, incluido el uso de recomendaciones de proveedores en configuraciones seguras, usando software actualizado. Aplique un estricto control de seguridad como permisos, políticas de contraseña. También vea permiso de carpeta y permiso de archivo consejo compartido del host .

2. Implemente procedimientos de control de calidad, como pruebas en entornos de baja seguridad, revisión de código y pruebas.

3. Haga que su aplicación web / vulnerabilidad de sitio web sea probada por un probador profesional certificado al menos una vez. Busque EC-Council, ISO 27001 y probadores certificados PCI. enlace

4. Visite OWASP www.owasp.org y enlace para obtener recursos de seguridad de aplicaciones web.

5. Use las herramientas del Sistema de prevención de intrusiones (IPS). Sin embargo, dependiendo de su proveedor de alojamiento, puede tener limitaciones en lo que puede usar. Las herramientas IPS basadas en host deberían estar bien si tiene una máquina virtual dedicada.

Espero que ayude. De lo contrario, ¿quizás podría proporcionar más información sobre los sistemas que está ejecutando?

Como dijo @Dgarcia, un método rápido es usar algo como Tripwire u otra herramienta que supervise los archivos o los hashes de los archivos para verificar los cambios. Esto funciona para identificar servidores comprometidos por muchos tipos de ataques.

1. Puede que no funcione para aquellos en los que se haya instalado un rootkit que contrarreste este proceso.
2. No funcionará para servidores que hayan sido víctimas de un compromiso de solo memoria o que no toque los archivos que está monitoreando.

Para 1, tu única opción es una reconstrucción desde cero

Para 2, su mejor opción es una reconstrucción desde cero, ya que cualquier compromiso podría implementar puertas traseras que romperán cualquier cosa que intente arreglar, pero otros pasos podrían ser útiles:

• compruebe las versiones de su servidor web y php y utilícelas para buscar en vulnerabilidades conocidas en la lista de Avisos; esto le ayudará a identificar las áreas que pueden haber sido comprometidas. Entonces
• verifique el código de su aplicación web
• revise sus configuraciones de servidor web
• compruebe la máquina del cliente (para el archivo de hosts, DNS, etc.), ya que puede ser el problema

Esta es una pregunta difícil de responder porque es muy amplia. Hay dos categorías de "hacks" en mi libro: menor y serio. Clasificaría un rootkit en la categoría seria y su ataque de inyección de script promedio como menor. Si bien con ataques menores puede limpiarlos, no puede estar 100% seguro de haberlos eliminado o haber cerrado todos los accesos para repetir el ataque, pero puede estar seguro al 99% analizando el ataque en busca de factores clave como " ¿Era esta persona un buen programador? y "¿Cuál fue la intención de la persona?" Los rootkits son negocios asquerosos. Eliminar un rootkit requiere una limpieza y restauración completas. Detectar uno de forma remota es casi imposible: para estar seguro, debe tener acceso físico a la máquina y un disco de arranque.

Más importante es la prevención. El dicho "una onza de prevención vale una libra de cura" es completamente cierto en este contexto. Instale un software que le permita monitorear varios aspectos del sistema y envíe informes diarios o incluso por hora. Se mencionó Tripwire, pero también hay otras herramientas. Recomiendo usar un par de herramientas diferentes: las de cosecha propia son más difíciles de localizar y no son difíciles de crear. Quieres construir una defensa sólida y limitar el acceso al sistema. No permita que nadie en el mundo tenga acceso al puerto SSH (al menos, restréguelo por dirección IP / pequeño rango de IP). Coloque un firewall dedicado frente a cada servidor para que haya una capa adicional de protección. No quieres que la caja sea la única línea de defensa. Solo administre datos críticos con el servidor a través de SSH / SSL, de modo que todo esté encriptado y libre de miradas indiscretas. Nunca administres tus servidores desde redes WiFi abiertas.

Muchos sitios utilizan MySQL o una base de datos similar. Detectar cosas como ataques XSS u otros datos deshonestos en una base de datos no es fácil porque hay problemas que dependen del esquema. No he visto ninguna solución para este problema, pero no dudaría de que existan.

Un método rápido es tener el md5 de todos los archivos que sabes que están en buen estado. Si sospecha que su sitio se está comportando mal o como una inspección regular, puede verificar los archivos. Si alguno de los md5 no coincide, puede diferenciar los archivos y examinar los cambios.

Obviamente, esto no funciona con archivos dinámicos: registros, volcados de bases de datos, etc. Si no puede realizar un seguimiento de los cambios.

Hay, por supuesto, múltiples métodos (inspeccionar registros ...) y prevención, pero esta es una manera fácil y rápida.