Después de meses de abandono, llamas de correo electrónico y batallas administrativas, nuestro actual administrador de sistemas fue despedido y me entregó "las credenciales del servidor". Dichas credenciales consisten en una contraseña de root y nada más: sin procedimientos, sin documentación, sin consejos, nada.
Mi pregunta es: suponiendo que haya dejado trampas, ¿cómo puedo controlar los servidores con el menor tiempo de inactividad posible?
Aquí están los detalles:
- un servidor de producción ubicado en una granja de servidores en el sótano; ubuntu server 9.x probablemente, con parches grsec (rumores que escuché la última vez que le pregunté al administrador)
- un servidor interno que contiene toda la documentación interna, repositorio de archivos, wikis, etc. Nuevamente, servidor ubuntu, pocos años de antigüedad.
Supongamos que ambos servidores están parcheados y actualizados, por lo que prefiero no intentar hackear mi camino a menos que haya una buena razón (es decir, eso se puede explicar a la alta gerencia).
El servidor de producción tiene algunos sitios web alojados (apache-php-mysql estándar), un servidor LDAP, una suite / servidor de correo electrónico ZIMBRA y, por lo que puedo decir, algunas estaciones de trabajo vmware en ejecución. No tengo idea de lo que está pasando allí. Probablemente uno sea el maestro LDAP, pero es una suposición descabellada.
El servidor interno tiene un wiki / cms interno, un esclavo LDAP que replica las credenciales del servidor de producción, algunas estaciones de trabajo vmware más y copias de seguridad en ejecución.
Podría simplemente ir al administrador de la granja de servidores, señalar el servidor, decirles ' sudoapaguen ese servidor por favor', iniciar sesión en modo de usuario único y seguir mi camino. Lo mismo para el servidor interno. Aún así, eso significaría tiempo de inactividad, la alta gerencia molesta, el viejo administrador de sistemas disparándome de nuevo diciendo '¿ves? no puedes hacer mi trabajo y otras molestias, y lo más importante es que tendré que perder algunas semanas de tiempo no remunerado.
En el otro extremo del espectro, podría iniciar sesión como root y pulgadas a través del servidor para tratar de comprender lo que está sucediendo. Con todos los riesgos de desencadenar sorpresas dejadas atrás.
Estoy buscando una solución en el medio: trate de mantener todo funcionando como está, mientras entiendo lo que está sucediendo y cómo, y lo más importante, evite desencadenar trampas explosivas que quedan .
Cuales son tus sugerencias?
Hasta ahora, pensé en 'practicar' con el servidor interno, desconectar la red, reiniciar con un CD en vivo, descargar el sistema de archivos raíz en una unidad USB y cargarlo en una máquina virtual aislada y desconectada para comprender la antigua forma de administrador del sistema. pensando (a-la 'conoce a tu enemigo'). Podría hacer la misma hazaña con el servidor de producción, pero un volcado completo haría que alguien lo notara. Tal vez pueda iniciar sesión como root, verificar crontab, verificar el .profile para ver si hay comandos que se inician, volcar el último registro y lo que se me ocurra.
Y es por eso que estoy aquí. Cualquier sugerencia, por pequeña que sea, sería muy apreciada.
El tiempo también es un problema: podría haber desencadenantes en unas pocas horas o en unas pocas semanas. Se siente como una de esas malas películas de Hollywood, ¿no?
fuente
Respuestas:
Como otros han dicho, eso parece una situación floja.
(Comenzando al final)
Por supuesto, no puedes simplemente quitar los servidores y dejar que el instalador haga su magia.
Proceso general
rm -rf $service(suena harsch pero lo que quiero decir es desmantelar el servicio)Que ganaste
He estado allí hecho eso, no es nada divertido :(
¿Por qué necesita que la gerencia lo apruebe ?
Ah, y presénteles el plan general antes de comenzar , con algunas estimaciones sobre lo que sucederá en el peor y el mejor de los casos.
Se va a costar mucho tiempo, independientemente de la redistribución si no tiene documentación. No es necesario pensar en puertas traseras, en mi humilde opinión, si no tiene documentación, una migración continua es la única forma de llegar a un estado sensato que brinde valor a la empresa.
fuente
¿Tiene alguna razón para creer que el administrador anterior dejó algo malo, o simplemente mira muchas películas?
No estoy pidiendo ser gracioso, estoy tratando de tener una idea de qué tipo de amenaza crees que existe y qué tan probable es. Si cree que las posibilidades realmente son muy altas de que realmente exista algún tipo de problema gravemente disruptivo, le sugiero tratarlo como si fuera una intrusión exitosa en la red .
En cualquier caso, sus jefes no quieren la interrupción del tiempo de inactividad mientras se ocupa de esto: ¿cuál es su actitud hacia el tiempo de inactividad planificado para ordenar los sistemas frente al tiempo de inactividad no planificado si hay una falla en el sistema (ya sea una falla real o una administrador deshonesto) y si su actitud es realista frente a su evaluación de la probabilidad de que realmente tenga un problema aquí.
Hagas lo que hagas, considera lo siguiente:
Tome una imagen de los sistemas ahora mismo . Antes de hacer cualquier otra cosa. De hecho, tome dos y deje uno a un lado y no lo toque de nuevo hasta que sepa qué está sucediendo con su sistema, si es que hay algo, este es su registro de cómo estaba el sistema cuando lo asumió.
Restaure el "segundo" conjunto de imágenes en algunas máquinas virtuales y utilícelas para investigar qué está sucediendo. Si le preocupa que las cosas se activen después de una fecha determinada, configure la fecha hacia adelante un año más o menos en la máquina virtual.
fuente
En primer lugar, si va a invertir tiempo extra en esto, le aconsejaría que realmente le paguen por ello. Parece que has aceptado las horas extra no pagadas como un hecho, a juzgar por tus palabras: en mi opinión, no debería ser así, y especialmente no cuando estás en apuros debido a la culpa de otra persona (ya sea la administración, el viejo administrador de sistemas o probablemente una combinación de ambos).
Apague los servidores y arranque en modo de usuario único (init = / bin / sh o 1 en grub) para verificar los comandos que se ejecutan en el inicio de sesión de root. El tiempo de inactividad es necesario aquí, deje en claro a la gerencia que no hay más remedio que un poco de tiempo de inactividad si quieren asegurarse de que conservarán sus datos.
Luego revise todos los cronjobs, incluso si parecen legítimos. También realice copias de seguridad completas lo antes posible, incluso si esto significa tiempo de inactividad. Puede convertir sus copias de seguridad completas en máquinas virtuales en ejecución si lo desea.
Entonces, si puede obtener nuevos servidores o máquinas virtuales capaces, realmente migraría los servicios a entornos nuevos y limpios, uno por uno. Puede hacer esto en varias etapas para minimizar el tiempo de inactividad percibido. Obtendrá un conocimiento profundo muy necesario de los servicios mientras restaura su confianza en los sistemas base.
Mientras tanto, puede buscar rootkits utilizando herramientas como chkrootkit . Ejecute nessus en los servidores para buscar agujeros de seguridad que pueda usar el administrador anterior.
Editar: Supongo que no abordé la parte "graciosa" de su pregunta tan bien como pude. El primer paso (pasar al modo de usuario único para verificar las trampas de inicio de sesión) probablemente se puede omitir: el viejo administrador de sistemas que le proporciona la contraseña de root y la configuración del inicio de sesión para hacer una
rm -rf /sería casi lo mismo que eliminar todos los archivos él mismo, por lo que hay Probablemente no tenga sentido hacerlo. Según la parte de respaldo: intente usar unarsyncsolución basada para que pueda hacer la mayor parte del respaldo inicial en línea y minimizar el tiempo de inactividad.fuente
Invertiré tiempo en aprender qué aplicaciones se ejecutan en esos servidores. Después de saber qué es qué, en cualquier momento puede instalar un nuevo servidor. En caso de que sienta que puede ser una puerta trasera, será una buena idea simplemente iniciar en modo único o tener algún firewall entre los servidores y la red externa.
fuente
Te estás volviendo paranoico por la seguridad. No hay necesidad de ponerse paranoico. (b'cos hablas de trampas explosivas). Ir a través de la lista de software instalado. Vea qué está ejecutando el servicio (netstat, ps, etc.), vea trabajos cron. Deshabilite la cuenta de usuario administrador de sys anterior sin eliminar la cuenta (fácilmente haciendo señalar el shell a nologin). Ver a través de los archivos de registro. Creo que con estos pasos y según su conocimiento de las necesidades de la compañía desde las cuales puede adivinar el uso de los servidores, creo que debería poder mantenerlos sin mayores inconvenientes.
fuente