Consejos para hacerse cargo con gracia de un servidor de producción (UNIX)

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?

Como otros han dicho, eso parece una situación floja.

(Comenzando al final)

• Despliegue completamente nuevo

Por supuesto, no puedes simplemente quitar los servidores y dejar que el instalador haga su magia.

Proceso general

• Obtenga un presupuesto para un servidor de respaldo (respaldo como en el almacenamiento de datos)
• crear instantáneas de los datos y colocarlos allí antes de hacer nada
• ¡Obtenga la aprobación de la gerencia!
• Reúna una lista de requisitos (es la wiki necesaria, quién está usando las instancias de VMWare, ...)
  • De la gerencia y
  • De los usuarios
• ¡Obtenga la aprobación de la gerencia!
• Cierre los servicios no listados durante una semana (un servicio a la vez; iptables puede ser su amigo si solo desea cerrar los servicios externos pero tiene la suspensión de que aún podría usarse desde una aplicación en el mismo host)
  • ¿Sin reacción? -> copia de seguridad final, eliminar del servidor
  • ¿Reacción? -> Hable con los usuarios del servicio
  • ¡Reúna nuevos requisitos y obtenga la aprobación de la gerencia!
• todos los servicios no listados cayeron durante un mes y no hubo reacción? -> rm -rf $service(suena harsch pero lo que quiero decir es desmantelar el servicio)
• obtener presupuesto para un servidor de repuesto
• migrar un servicio a la vez al repuesto
• ¡que la gerencia lo apruebe!
• apague el servidor migrado (apagado)
• descubre que más gente viene gritándote -> sí, acabas de encontrar las sobras
• reunir nuevos requisitos
• iniciar de nuevo y migrar servicios
• repita los últimos 4 pasos hasta que no haya personas viniendo después de usted durante un mes
• volver a implementar el servidor (y obtener la aprobación de la administración)
• enjuague y repita todo el proceso.
  • el servidor redistribuido es su nuevo repuesto

Que ganaste

• Inventario de todos los servicios (para usted y la gerencia)
• Documentación (después de todo, debe escribir algo para la administración, por qué no hacerlo correctamente y hacer algo para usted y la administración)

He estado allí hecho eso, no es nada divertido :(

¿Por qué necesita que la gerencia lo apruebe ?

• Hacer visibles los problemas
• Asegúrate de que no te despidan
• Oportunidad de explicar riesgos.
  • Está bien si no quieren que lo hagas, pero después de todo, es su decisión tomar después de recibir suficiente información para juzgar si la inversión vale la pena.

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.

¿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.

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 una rsyncsolución basada para que pueda hacer la mayor parte del respaldo inicial en línea y minimizar el tiempo de inactividad.

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.

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.