Ok
Solo que no has resuelto el problema, sino solamente aumentado la seguridad.
En ese tenor, creo que ya instalado todo, quizas te convenga seguir
estas reglas:
1. Separación de usuarios y privilegios. recuerda que el usuario con
el que corre apache solo debe poder ver y servir tus datos, pero
no debe ser el dueño, o poder modificarlos.
2. asegurarte que /tmp y /var/tmp se monten en filesystems aparte y
con los parametros NOEXEC,NOSUID,NODEV como comenta Thomas.
3. Instala y corre Tripwire. Con ese te aseguras de tener el CRC
correcto de todos tus archivos, y de que te puede avisar CUALES
archivos fueron cambiados. (http://www.tripwire.org/)
4. Instala y corre mensualmente programas de revisión de seguridad de
tus archivos. Uno muy bueno es el chkrootkit
(http://www.chkrootkit.org/) y otro el rootkit hunter
(http://www.rootkit.nl/)
5. hazte una nota en el calendario para lo de la revisión de
seguridad, y en esa ronda también revisa que actualizaciones de
seguridad hay y aplicalas.
Que mas? no dejar usuarios con password fáciles. no permitir acceso a
root via ssh sino usando sudo, y siempre usar llaves para tu ssh. creo
que con eso estás mucho más seguro.
Alguna recomendación más? algo que quitar?
Sirve que utilizamos esta como la lista de recomendaciones básicas del
GLO para asegurar nuestro sitio web jejeje
Saludos
Gabriel Orozco (Redimido)
On 01/09/2010 12:04 p.m., Miguel Cardenas wrote:
Holas
Pues ya no hay chance de hacerlo, ya he reinstalado y mate absolutamente todo y
cerre todos los accesos... Como sea lo tendre en cuenta para estar monitoreando
constantemente el server, ya que este monigote no entro a desgraciarme los
servicios sino a instalar el suyo propio, digamos que fue onda parasito y no
virus :-)
Saludos y gracias de nuevo por sus comentarios!
________________________________
From: Gabriel Orozco<redim...@glo.org.mx>
To: glo@glo.org.mx
Sent: Mon, August 30, 2010 4:27:35 PM
Subject: Re: [GLO] SERVIDOR HACKEADO
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
