Necesito ayuda para rastrear una vulnerabilidad en mi servidor. Por segunda vez, mi servidor se ha visto comprometido con la sustitución de archivos por descargas repletas de virus.
Según las fechas del sistema de archivos, durante un período de 45 minutos, 4 archivos exe de mi servidor fueron reemplazados por versiones renombradas del mismo virus.
Mi servidor web está ejecutando Ubuntu 10.4.3 LTS con la versión del kernel 2.6.32-31-genérico, completamente actualizado y actualizado.
La única forma de acceder al shell es a través de SSH y una clave privada protegida por contraseña que tengo conmigo en una memoria USB. La contraseña de inicio de sesión de SSH está deshabilitada y los registros del servidor (que sé que pueden modificarse, pero tengo buenas razones para creer que no lo han hecho) indican que no se utilizó SSH para iniciar sesión en el servidor.
La pila de software de servicio web es muy complicada. Hay PHP (5.3.3-1) w / Suhosin v0.9.29, nginx 1.0.9 (ahora actualizado a 1.0.10), Tomcat (en una cárcel y sospecho que no está asociado), y MySQL 5.1.41.
Admito que en el momento del primer ataque, me había contentado con alegremente chmod -R 777 mi directorio web con el fin de mitigar el dolor de cabeza. Ahora ejecuto un completo lío de scripts PHP que incluyen, entre otros, WordPress, vBulletin y varios productos hechos en casa; los dos primeros están siempre actualizados y el último ha sido escrito con bastante cuidado para escapar o normalizar cualquier valor ingresado por el usuario.
Dados los permisos de archivos débiles pero el acceso al servidor fuertemente bloqueado, tuve la tentación de sospechar una vulnerabilidad en uno de los muchos scripts PHP que permitían la ejecución de código aleatorio.
Desde entonces he bloqueado completamente los permisos de archivo. nginx / php se ejecutan como www-data: www-data con todos los archivos dados solo ejecutan y leen los permisos ( chmod -R 550 /var/www ).
Sin embargo, hoy, después de todo esto, mi servidor se vio comprometido nuevamente.
El problema es que los archivos que fueron reemplazados aún tienen 550 de permisos, los registros de SSH indican que no hay inicio de sesión y estoy completamente perdido en cuanto a qué hacer o intentar a continuación.
Intenté recrear el ataque en las rutas que fueron reemplazadas por un script PHP muy básico:
$file = fopen('/var/www/mysite.com/path/to/file', 'w');
fwrite($file, 'test');
fclose($file)
Pero eso me dio los permisos apropiados, error denegado.
¿Puede alguien, por favor, indicarme dónde buscar la fuente de esta vulnerabilidad? ¿Me estoy perdiendo algo con mis permisos de archivo?
Sé que ese servidor, una vez comprometido, está prácticamente "desaparecido" para siempre. Pero esa no es realmente una opción aquí. Recursivamente grepped toda mi carpeta / var / log para los nombres de archivos afectados con la esperanza de encontrar algo, pero no surgió nada.
También busqué cualquier script en la carpeta cron o en otro lugar que pudiera haber sido colocado en el momento del primer ataque para atacar nuevamente en una fecha posterior, pero (a) no encontró nada y (b) no debería encontrar cualquier cosa como los archivos en / etc / no son modificables por www-data (asumiendo un punto de infiltración nginx / PHP).
Debo agregar que las dos veces que he greped los registros de acceso nginx (estilo combinado) para los nombres de los archivos infectados, pero no he encontrado nada. Sin embargo, entiendo / me doy cuenta de que existen muchas formas de ocultar los nombres de los archivos de mis greps.