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 [EMAIL PROTECTED] ---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 > > > > [EMAIL PROTECTED]
