En si, lo que dicen hasta ahora es correcto, solo me gustaria añadir
algunos detalles
a) lo mas seguro es que se metieron por una app. eso se ve porque todo
corre con el usuario de apache, desde /tmp
b) revisa si no se han creado usuarios hace poco, que tu no creaste.
casi siempre alli encuentras la pista de que tan comprometido estás.
c) revisa por directorios comenzando con espacios en /tmp y /var/tmp que
son los directorios mas vulnerables.
Eso es para revisar el alcance.
Para evitar que te suceda, utiliza la filosofía de Unix/Linux que se nos
olvida tan seguido: Separación de usuarios y privilegios.
Esto es, combinandolo con algo de lo que te recomienda Rodolfo:
1) Pon tus datos y los directorios temporales en filesystems que montes
con el parametro NOEXEC en el fstab
2) si llegaras a necesitar CGI's, ponlos en un filesystem aparte que si
pueda ejecutar archivos, pero todo alli le debe pertenecer a un usuario
y grupo en los que apache no pueda escribir, solo leer y ejecutar (asi
no pueden poner nada alli desde apache)
3) es lo mismo que en el punto dos. los archivos y directorios le deben
pertenecer a un usuario:grupo diferentes de los de apache. digamos,
data:data. eso y permisos 755 y 644 en todos los directorios y archivos
hará que sea imposible reemplazarlos por el usuario apache.
Si haces eso, dificilmente te podrán afectar inyectando un archivo
mediante apache.
Saludos
Gabriel Orozco (Redimido)
On 30/08/2010 11:30 a.m., Helios Mier wrote:
A mi me parece que lo que dide Izto fue lo que te paso, alguno de los
usuarios tiene en su dominio un script vulnerable que permite la inyeccion
de archivos.
Con los rootkits que hay ahorita sueltos comprometiendo cajas linux tan
seguido, ni siquiera te darias cuenta que estas invadido puesto que las
modificaciones al kernel y los comandos de sistema no te dejarian ver nada.
Veo que lo más probables es que se limite la intrusión al apache, la base de
datos y los scripts de tus usuarios. Yo no reinstalaria un servidor solo por
eso, pero sin embargo, no se puede estar certero hasta que no se vea en
profundidad el caso para determinar por donde se metio y que fue lo que ha
hecho el intruso.
Eso sera lo mas importante para ti puesto que si se metieron por uno de tus
dominios virtuales, al momento de reinstalar y restaurar el sistema, se te
van a volver a meter en cuestion de horas.
Tu orden de revision para ver por donde:
1- dominios que tienen scripts programados por ellos mismos.
2- Dominios con CMSs con versiones desactualizadas.
3- Dominios que tienen acceso ftp-telnet-ssh o con muchas cuentas de
usuarios.
asi que a leer logs.
2010/8/30 Miguel Cardenas<warlock...@yahoo.com>
Hola
Pues creo que si sera la mejor opcion restaurar puesto que no se que areas
del
sistema hayan modificado o si haya un backdoor abierto, tardare mas en
averiguar
que cosas estan alteradas y corregirlas, aparte de que correria el riesgo
de no
encontrar todo y dejarlo vulnerable... afortunadamente todos los portales y
servicios son mios, pero como sea el trabajo de regenerar bases de datos,
buzones, subdominios, instalar aplicaciones que meti a mano :(
En fin saludos y gracias por sus comentarios
