Ejecuto un VPS Ubuntu 12.04 x64 con Vesta y un sitio en PHP. Ha sido pirateado varias veces con código inyectado que se parece a este:
<?php $KoDgalxVvsZfidVcEOTJDeMX='ba'.'se6'.'4_deco'.'de';eval($KoDgalxVvsZfidVcEOTJDeMX("cHJlZ19yZXBsYWNlKCIvN0xna0xnND1IR2JEOGs2WDht....
Para solucionarlo, decidí cambiar los permisos y el propietario de todos los archivos a 555 y root, para que ningún usuario pueda cambiar los archivos. Eliminé el acceso FTP y aseguré SSH para que solo las claves que tengo en el VPS puedan conectarse.
A pesar de todos estos cambios, otro usuario siempre puede cambiar archivos, cambiar el nombre de las carpetas y cargar otro archivo pirateado.
¿Qué crees que me falta? ¿Cualquier sugerencia? ¡Gracias! Si necesita más información sobre este tema, estaré encantado de compartirla para ayudar a otros que sufren el mismo mal.
Respuesta1
Un atacante consiguió root en su sistema. No puedes confiar en NADA en el sistema, en absoluto. El alcance de lo que puede hacer un rootkit es enorme.
Si tiene copias de seguridad de su contenido en algún lugar, úselas. De lo contrario, puedes esperar que el atacante no haya estropeado tus datos. Deseche sus tablas SQL y cópielas junto con sus otras cosas (jpg, pdf, html, pero NO ningún script/php/cualquier otra cosa que se ejecute). Cópialo a otro sistema o descárgalo a la computadora de tu casa si es lo suficientemente pequeño como para poder cargarlo nuevamente.
Haga todo lo que pueda para verificar que lo que copió todavía esté bien. (como comprobar que los archivos jpg sigan siendo válidos, por si acaso. ¿Quizás ejecutar un escáner de virus en ellos?)
Elimina la instalación comprometida. Si su servidor está alojado en un servicio de alojamiento típico, es de esperar que tengan las cosas configuradas para que tenga un panel de control que no pueda estropearse ni siquiera por el root del host. Por lo tanto, puede esperar que el atacante no haya logrado tocar nada fuera de la máquina que comprometió. (Sin embargo, si tenía acceso sin contraseña a cualquier otra cosa configurada en esa máquina, verifíquela).
Haga lo que tenga que hacer para realizar una instalación nueva. También podría pasar a Ubuntu 14.04 LTS, ya que hay que reinstalar de todos modos.
NO copie ningún código del sistema comprometido al nuevo sistema. Todos los datos que provienen del sistema comprometido deben tratarse como posibles portadores de una plaga.
La semántica del sistema de archivos Unix requiere permiso de escritura en el directorio para eliminar archivos. (los nombres de archivos son enlaces de un nombre a un inodo. La llamada al sistema para crear enlaces físicos (otros nombres para un archivo) eslink(2), y la llamada para eliminar un archivo esunlink(2).)
Si el bit adhesivo está configurado en un directorio ( chmod +t), unlink(2)y rename(2)también requiere que la persona que llama sea propietaria del archivo que se va a desvincular o cambiar de nombre. (independientemente del permiso de escritura en el archivo). Es estándar para /tmpy /var/tmppara ser 1777(escribible en todo el mundo con un conjunto de bits adhesivos).
rm, el comando de shell, es requerido porPOSIXpara preguntar antes de desvincular archivos de solo lectura, pero debe verificar ese caso. En realidad, no tiene que hacer nada más que unlink(2)lo que haría con cualquier otro archivo. Así que no se deje engañar pensando que esto tiene algún efecto sobre un adversario.
Nada de esto es muy relevante para defenderse contra ataques, porque el caso más probable es obtener el control del proceso de su servidor web, o algo más que se esté ejecutando con una identificación de usuario que tenga acceso de escritura a muchas cosas.
Cuanto más pueda limitar lo que pueden escribir los procesos que tienen que tratar con datos de Internet, menos posibilidades habrá de que un atacante pase de obtener el control de su httpd a modificar sus datos o hacerse con el control de toda su máquina.
Es por eso que no deberías ejecutar Apache como root.
Respuesta2
Si puede evitarlo, no debería ejecutar los procesos del servidor web como usuario root, ya que eso significa que cualquier vulnerabilidad en el servicio web comprometerá completamente el servidor.
En su situación actual, recomendaría comenzar desde cero en un nuevo servidor: el atacante podría haberse otorgado acceso raíz persistente a través de varios métodos. Veraquípara más información.
Respuesta3
A pesar de todos estos cambios, otro usuario siempre puede cambiar archivos, cambiar el nombre de las carpetas y cargar otro archivo pirateado.
Si el directorio principal de su raíz web es propiedad del mismo usuario que ejecuta el servidor web, entonces esos permisos del directorio principal anularán cualquier permiso establecido para archivos y directorios secundarios.
Por ejemplo, abra un proceso de "Terminal" en cualquier directorio de su propiedad. Ahora crea un archivo llamado zzz_test.txtasí:
touch zzz_foo.txt
Ahora revisa el archivo así:
ls -la zzz_foo.txt
Los permisos, en mi caso, tienen este aspecto:
-rw-r--r-- 1 jake staff 0 Feb 23 19:11 zzz_foo.txt
Luego corro chmodasí:
chmod 555 zzz_foo.txt
Ahora ejecute ls -lanuevamente y el resultado se verá así:
-r-xr-xr-x 1 jake staff 0 Feb 23 19:11 zzz_foo.txt
Bien, se cambian los permisos. Así que hagamos algo “loco” como intentar eliminarlo:
rm zzz_foo.txt
La respuesta sería:
override r-xr-xr-x jack/staff for zzz_foo.txt?
¡Y luego simplemente golpea yy presiona returny viola! El archivo desapareció.
Esta es la razón por la que simplemente cambiar los permisos de los archivos nunca será una forma eficaz de proteger un servidor web. La naturaleza simple de la forma en que funcionan los servidores web, especialmente si están basados en PHP, significa que el usuario del servidor web siempre tendrá acceso de lectura y escritura a los archivos a los que necesita acceder. Por lo tanto, el simple hecho de ir chmod 555 [some files]es una forma ineficaz de “defenderse” contra el malware y los intentos de piratería.
¿En cuanto a qué puedes hacer ahora? Bueno, simplemente cambiar los permisos y la propiedad no significa nada. El problema más importante es que su código base PHP es vulnerable a ataques. Entonces, la única forma efectiva de limpiar este tipo de cosas es limpiar tu código PHP. Si este sitio se basa en un marco predefinido como Joomla!, WordPress o CakePHP, entonces el mejor curso de acción es actualizar el marco principal de Joomla!, WordPress o CakePHP para mejorar la seguridad. De manera similar, si hay un complemento de Joomla!, WordPress o CakePHP que es vulnerable a ataques, ese complemento debe actualizarse o parchearse para tapar el agujero.
Y más allá de todo eso, el software central de su sistema, suponiendo que sea una pila LAMP (Linux Apache MySQL PHP), también debe mantenerse actualizado y parcheado.
Al fin y al cabo, la seguridad de un sitio web no es algo que ocurre sólo una vez. Es una mentalidad general y un proceso de mantenimiento que se debe cumplir. De lo contrario, cuando su sitio sea pirateado, se ejecutará sin cabeza después de intentar limpiar el desorden, lo que en realidad puede causar más daño que la incursión inicial de malware en sí.
Respuesta4
Estoy de acuerdo con empezar de nuevo con la opción del servidor, pero si quieres más seguridad y control, un servidor dedicado es una mejor idea.
En cuanto a su situación, lo primero que sugiero es deshabilitar todos los servicios en ejecución excepto el acceso al shell. Esto significa detener el servicio FTP, el servidor web (HTTP), el correo electrónico, etc. Luego, vaya al shell y navegue hasta las carpetas que contienen los elementos que afirma que están siendo pirateados. luego escribe:
ls -al
Deberías ver algo similar a lo siguiente en los resultados:
drwxrwxrwx 2 root root 4096 2014-10-10 00:31 ./
Si el cuarto elemento (o especialmente el tercer elemento) es en realidad "raíz", entonces estás en un gran problema y necesitas rehacer la configuración de tu servidor web para que ejecute cosas como diferentes usuarios dependiendo de la carpeta. Debería buscar en mod_rewrite (o similar) para Apache y luego ajustar su archivo de configuración de Apache (httpd.conf) en consecuencia para que el sistema cambie el nombre de usuario cuando se realice cada solicitud a la carpeta. Luego cambie el nombre de usuario y el nombre del grupo de la carpeta en consecuencia.
Una vez que se solucione, navegue hasta la carpeta raíz del documento (probablemente public_html), use un editor (pico funciona) y escriba lo siguiente:
<?php
echo shell_exec("whoami");
?>
luego guárdelo como who.php. Luego encienda el servidor web y en cualquier navegador, vaya a la página de inicio de su sitio web, pero agregue who.php al final y debería ver solo una palabra en la pantalla. Si esa palabra es raíz, entonces estás en un gran problema y debes seguir los pasos anteriores nuevamente. Si la palabra es nadie, entonces estás en problemas porque los hackers conocen muy bien ese nombre de usuario.