[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: bad user name www-data (Conclusion)



He podido acceder al servidor sólo con el Ultimo usuario que habíamos dado
de alta pero 'no se podía ver nada' debido a los pocos permisos con que
contaba. Luego de varios tumbos accedí con:

rescbf24 root=/dev/sda2 init=/bin/bash

Fui a ver el archivo /etc/shadow y en el encontré a todos los usuarios
perdidos. Pero, insertados entre los cuatro usuarios que nosotros dimos de
alta, se encontraban dos nuevos: nfk y nnffkk antes de nuestro último
usuario (unico que nos permitia acceder)
(Nota: recuerdo que en Novell el user nfk 'tenía que ver' con Apache)

A continuación fuí a ver el archivo  /etc/passwd y encontré sólo tres líneas
que transcribo:

admin:mNyoZE5MmiUXM:0:0::/:bin/bash
nnffkk:x:1008:1008:cd /var/spool/cron/.sh, ls -alF,
pwd,:/home/nnffkk:/bin/bash
usuario:x:1009:1009:usuario,,,:/home/usuario:/bin/bash

(donde usuario es el que nosotros dimos de alta)

Les recuerdo que soy nuevo en linux (demasiado) pero este archivo sólo tiene
registrados al usuario nnffkk y el último que dimos de alta. Lo mas extraño
es 'cd /var/spool/cron/.sh, ls -alF, pwd ' que figura para nnffkk.

Recuerdo que de los dos servidores uno tuvo un fallo de hard (Memoria). Al
Rebotearlo sucedió el problema. El otro no tuvo fallo alguno: hicimos el
shutdown y luego, al reiniciarlo 'fue' (como decimos en Buenos Aires).

Por todo lo que leí en sus mensajes estimo que se trató de un gusano SSL en
Apache con scripts que se ejecutaron al bootear y provocaron el daño (o algo
así)

//---- Decisión ----

Con nuestra primer cicatriz (generada por nuestra inoperancia e
inexperiencia) vamos por más y decidimos:

1) Dejar la 'práctica forense' de este caso. Decretamos 'Muerte por gusano
SSL/APACHE y listo :)
2) De ahora en más No trabajar más como root, al menos que la tarea así lo
requiera.
3) Endurecer las nuevas instalacioes ( Bastille y otros modulos que nos
sugirieron)
4) Encerrar aplicaciones en una carcel "chroot jail" (Mas que interesante!)
5) Montar /tmp en una partición independiente  y eliminar permisos de
ejecución en él para evitar la ejecución de scripts y ataques basados en
hard links contra nombre de archivos predecibles y también una buena parte
de los ataques al sistema de manuales ( man y sus comandos auxiliares ).
6) Leer sobre harden-doc que está orientado a administradores que no tienen
mucha experiencia en Linux ( Mi caso! )
7) apt-get update && apt-get upgrade con las lineas apropiadas que apunten a
security.debian.org
8) Toda otra sugerencia que recibamos (las anteriores fueron todas
sugeridas: nada propio).

La idea de este e-mail es cerrar nuestro tema en la lista y agradecer a
quienes nos ayudaron con sus respuestas.
En especial saludos a: Matías nnss , Alexander Wallace y Victor Calzado
Mayo. Por su tiempo y tolerancia a nuestra ignorancia.

Gracias.

Claudio Carramal

soporte@asd-web.com.ar


---Mensaje Original ---

> > > > Estimados colegas:
> > > >
> > > > La semana pasada Tuvimos un problema por fallo de un servidor y no
> > > > pudimos acceder mas al equipo.
> > > > Encendimos un servidor 'muleto' que tenemos armado, copiamos los
datos
> > > > y seguimos trabajando.
> > > > El día de hoy este equipo dejó de dar servicio (no hay falla de
hard) y
> > > > al encenderlo no nos deja ingresar.
> > > > Uno de los ultimos mensajes que se llega a ver es 'bad user name
> > > > www-data' Ahora les pregunto
> > > >
> > > > ¿Hay alguna forma de grabar en un log los mensajes que saca al
bootear?
> > > > (les recuerdo que no puedo acceder al disco. Debería poder grabarse
a
> > > > diskette o algo así)
> > > >
> > > > Digo esto porque al no poder ver los errores anteriores no tenemos
> > > > forma de empezar a trabajar. Gracias
> > > >
> > > > Claudio Carramal
> > > > soporte@asd-web.com.ar




Reply to: