¿Cómo puede saber qué hace realmente un servidor? [cerrado]

42

Me han entregado 3 cajas de Linux, 1 de frente con apache y otras 2 que, por lo que puedo decir, no hacen mucho. Todos corriendo en Redhat.

La pregunta es simple: ¿cómo puedo saber qué está haciendo realmente el servidor? La documentación cero está disponible del creador.

— Bizmark
fuente

77

La lista de procesos, los oyentes de la red (tal vez comparar con debería haberse ejecutado en base a scripts de inicio) ...

— HBruijn

55

¡Maldita sea! seguramente alguien sabe para qué son? ¿Entonces quieren que los apoyen pero no saben lo que hacen?

— Digital Lightcraft

11

Apágalos. Alguien le hará saber, casi de inmediato , lo que no funciona.

— jscott

58

NO LO APAGUES. Desenchufe el cable Ethernet, si desea realizar una prueba de gritos. Si nunca ha tenido una caja con un tiempo de funcionamiento de dos años que no se reinicia, lo hará en algún momento. Este no es el momento de agregar esa frustración a la mezcla.

— Aaron Copley

77

Lo que todos los demás dijeron, pero también: ejecuta nmap contra ellos.

— Katherine Villyard

42

Desenchufe el cable de Ethernet y vea quién se enoja.

Sin embargo, en serio, las máquinas misteriosas como esta crean una gran sobrecarga mental para un equipo y, a menudo, no proporcionan absolutamente ningún valor comercial. Hable con su jefe, si nadie sabe lo que hace, tal vez a nadie le importe lo que hace.

— Josh Rumbut
fuente

43

NO LO APAGUES. Desenchufe el cable Ethernet, si desea realizar una prueba de gritos. Si nunca ha tenido una caja con un tiempo de funcionamiento de dos años que no se reinicia, lo hará en algún momento. Este no es el momento de agregar esa frustración a la mezcla. (Copiando esto aquí porque necesita ser leído.)

— Aaron Copley

3

Tienes 100% de razón, he editado la publicación para reflejar eso. Estaba siendo un poco gracioso, pero aún puedo ser gracioso sin promover el desastre.

— Josh Rumbut

8

Antes de desconectar la red, es una buena idea guardar una lista de procesos en ejecución y abrir sockets en cada servidor, en caso de que algo dependa de una conexión TCP entre los servidores que haya permanecido ESTABLECIDA durante muchos meses sin que nadie piense Automatizar los pasos necesarios para abrirlo en el primer caso. (Por ejemplo, si alguien necesita un reenvío de puerto ssh temporalmente y luego se olvidó de ello)

— Kasperd

44

No hagas esto. Qué consejo ridículo. Estúpida gente de TI irreflexiva haciendo esto me costó mucho tiempo y trabajo. PREGUNTA PRIMERO. Si no sabe a quién preguntar, PREGUNTE A TODOS .

— Lightness compite con Monica el

44

Asegúrese de dejar suficiente tiempo para que alguien grite, la única vez que hice esto con una máquina de escritorio o polvorienta sentada en un estante de la sala de servidores, nadie sabía lo que hacía, a alguien le tomó un mes completo darse cuenta cuando lo desconectamos. . Resulta que era parte del sistema de nómina, sin ese servidor, la contabilidad no podría generar la nómina mensual. Había estado funcionando sin supervisión durante al menos 3 años sin que nadie le prestara atención, por lo que la "prueba de gritos" fue un éxito, si no lo hubiéramos hecho, el servidor finalmente habría muerto por sí solo. Terminamos p2v'ing en nuestro clúster vmware.

— Johnny

30

Esta es una pregunta bastante amplia para el formato Serverfault, pero aquí es un buen comienzo:

Verifique los procesos en ejecución y aquellos programados para ejecutarse al inicio del sistema.
- Revise la configuración en ejecución de cada uno.
- Busque en cualquier directorio de datos definido. (Quizás alguien instaló MySQL y lo activó, pero no hay bases de datos).
Verifique las tareas programadas.
Verifique los registros para ver;
- quién ha iniciado sesión recientemente (y pregúnteles)
- y para tener una idea de lo que ha estado funcionando.

No mencionaste la versión, así que omití los detalles.

— Aaron Copley
fuente

8

Hay algo más importante que qué servicios están configurados para iniciarse cuando se inicia el sistema. ¿Qué servicios se están ejecutando en este momento? Iniciar un servicio y olvidarse de configurarlo para que comience en el arranque no es un error difícil de cometer. En una nota relacionada, es una buena idea mirar otros estados del sistema como: puntos de montaje, tabla de enrutamiento, reglas de iptables. Todas esas cosas se pueden cambiar fácilmente mientras el sistema se está ejecutando sin recordar actualizar los archivos de configuración utilizados durante el arranque.

— Kasperd

Además, usaría un escáner de puertos para ver qué puertos están abiertos, luego trataría de conectarme a él utilizando las herramientas habituales. Por ejemplo (simple) si el puerto 443 está abierto, puede intentar usar un navegador web para conectarse. He tenido que explorar estos servidores aparentemente abandonados con frecuencia y una de mis herramientas favoritas para navegar rápidamente a través de los archivos de configuración en / etc y otros lugares es usar "lince" o "enlaces" si lo prefiere. Estos son navegadores web basados en caracteres que también hacen un buen trabajo como navegador de archivos, con una conveniente navegación con la tecla del cursor.

— aseq

1

@kasperd Juego limpio en la ejecución vs. servicios persistentes. Pero pensé en las reglas de firewall, los puntos de montaje, etc. Me parecieron componentes auxiliares que ya estarán vinculados a uno de los puntos de viñeta existentes. YMMV.

— Aaron Copley

Agregue: verifique las conexiones de red activas y escriba los nombres de los servicios y los números de puerto. El mejor método para hacerlo varía según el sistema operativo. Por ejemplo, estadísticas netas. Además, coloque algún tipo de rastro en la computadora para que pueda ver lo que hace durante el día. También es posible que desee agregar consideración para los escenarios cuando las cosas que se ejecutan en los servidores PODRÍAN ser maliciosas.

— IceMage

19

Hay algunas cosas que puede hacer para tratar de determinar qué se está ejecutando en su sistema.

Puede verificar en qué puertos está escuchando su servidor para tener una idea de lo que hay allí. Un buen comando para usar sería:

 [root@server ~]# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             Stat    e       PID/Program name
tcp        0      0 0.0.0.0:139                 0.0.0.0:*                   LIST    EN      1880/smbd
tcp        0      0 0.0.0.0:5666                0.0.0.0:*                   LIST    EN      1911/nrpe
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LIST    EN      1759/sshd

Como puede ver en la salida de ejemplo anterior, le presenta la versión del protocolo (tcp o udp), la dirección que se está escuchando, el puerto que está abierto y el programa que está escuchando.

En el ejemplo truncado anterior (una máquina servidor) puede ver que los puertos tcp 139, 5666 y 22 están escuchando. Estos resuelven a samba, nrpe (agente de Nagios) y ssh respectivamente, y se confirma cuando verifica el programa que está escuchando en ese puerto.

Además, puede consultar la lista de demonios que están configurados para comenzar en el arranque, para hacerlo, ejecute: chkconfig --list | grep "3:on"

Ejemplo:

[root@server ~]# chkconfig --list | grep "3:on"
NetworkManager  0:off   1:off   2:on    3:on    4:on    5:on    6:off
acpid           0:off   1:off   2:on    3:on    4:on    5:on    6:off
sshd            0:off   1:off   2:on    3:on    4:on    5:on    6:off
sysstat         0:off   1:on    2:on    3:on    4:on    5:on    6:off
udev-post       0:off   1:on    2:on    3:on    4:on    5:on    6:off
vncserver       0:off   1:off   2:on    3:on    4:on    5:on    6:off
webmin          0:off   1:off   2:on    3:on    4:off   5:on    6:off
x2gocleansessions       0:off   1:off   2:on    3:on    4:on    5:on    6:off
.
.
.

o:

service --status-all

— Itai Ganot
fuente

55

Me resulta netstat -pluntmás fácil de recordar.

— Abligh

2

Además, tcpdumppuede ser útil para determinar quién está utilizando cada servicio.

— Abligh

18

Otro método consiste en verificar el /etcdirectorio y mirar las fechas de modificación. Después de una nueva instalación, todos los archivos en este directorio deben tener aproximadamente la misma fecha / hora. Y dado que una instalación generalmente instala muchas cosas que la gente generalmente no usa, solo los archivos que tienen una fecha de modificación posterior reflejan el propósito real del servidor . Si esto es ext4, también debería poder extraer la fecha de nacimiento de los directorios, por lo que la tarea podría ser bastante fácil.

Otro método más implicaría verificar los .bash_historyarchivos para ver qué estaban haciendo los administradores. Este archivo puede proporcionar una gran cantidad de conocimiento.

— Konrad Gajewski
fuente

7

Verifique las reglas del firewall. Con un poco de suerte, está configurado para negar por defecto. Eso significa que hay una regla explícita para cada servicio permitido.

Esto es mejor netstatporque también puede mostrar puertos abiertos, por ejemplo, para copias de seguridad nocturnas.

— MSalters
fuente

6

Una respuesta que aún no he visto: verifique los archivos modificados más recientemente. Los registros, los archivos de la base de datos, otros archivos de salida, etc., pueden escribirse todavía para proporcionar pistas:

find . -mtime -3

Eso encontraría archivos modificados en el directorio actual y más profundos, cambiados en los últimos 3 días. Aumente el número 3 a una suposición educada hasta que obtenga algún resultado que pueda investigar.

No es infalible, ya que las cajas pueden procesar algunas llamadas de servicio web, devolviendo algunos datos sin tener que escribir nada. Pero agregado a la gran mezcla mencionada anteriormente, puede dar algunas pistas.

— JayMcTee
fuente