Monitorización de Linux en modo Legacy

Hay una descripción exhaustiva de la instalación desde paquetes deb o rpm en el artículo Monitorización de Linux, por lo que aquí sólo explicaremos el procedimiento en un breve repaso.

En Checkmk Raw, puedes encontrar los paquetes Linux del agente a través de Setup > Agents > Linux. En las ediciones comerciales, primero llegas a Agent bakery en el menú Setup a través de Agents > Windows, Linux, Solaris, AIX, donde encontrarás los paquetes horneados. Desde ahí, el elemento de menú Related > Linux, Solaris, AIX files te llevará a la lista de archivos del agente.

Puedes descargar estos archivos a través del navegador o utilizar wget o curl para descargarlos directamente en el host en la monitorización:

En RHEL, SLES y distribuciones relacionadas, el paquete RPM se instala como root con el comando rpm -U:

Por cierto, la opción -U significa "actualizar", pero también puede realizar correctamente una instalación inicial.

La instalación del paquete DEB en Debian, Ubuntu o distribuciones afines se realiza como root con el comando dpkg -i:

Para una instalación cómoda e independiente de la distribución, necesitarás el agente de Linux en formato de archivo TGZ ("Tarball"), que puedes descargar de las ediciones comerciales en el Menú de configuración a través de Agents > Windows, Linux, Solaris, AIX. El archivo TGZ contiene la estructura completa de directorios del agente de Linux para desempaquetarlo en el directorio raíz del host monitorizado.

El parámetro -C ("cambiar directorio") es esencial al desempaquetar para garantizar que todas las rutas de los archivos son correctas. También utilizamos --no-overwrite-dir para que no se modifiquen los permisos de los directorios ya existentes:

Si lo has hecho todo correctamente, ahora el script del agente debería ser simplemente ejecutable como un comando y producir su salida típica. El | head trunca todo lo que sigue a la 11ª línea de salida:

Si aquí se imprime un número de versión inferior a 2.2.0, es probable que aún tengas instalada una versión antigua del script del agente como /usr/local/bin/check_mk_agent. Mueve este script antiguo o cámbiale el nombre, por ejemplo añadiendo .bak al nombre del archivo.

Rara vez es necesaria una instalación manual del script del agente, pero tampoco es muy difícil. En este tipo de instalación, al principio sólo se instala el script del agente, pero todavía no se realiza ninguna configuración del acceso. Para ello necesitas la caja Agents de la página de archivos del agente. Allí encontrarás el archivo check_mk_agent.linux:

Carga este archivo en el sistema de destino y cópialo en un directorio que sea ejecutable para root./usr/local/bin/ es una buena elección, ya que se encuentra en la ruta de búsqueda y está pensado para extensiones personalizadas. Alternativamente, puedes utilizar /usr/bin o un subdirectorio de /opt. Nosotros utilizamos /usr/bin para que todas las pruebas se correspondan con los otros métodos de instalación. También puedes realizar la instalación directamente con wget si está disponible:

No olvides los dos últimos comandos: eliminarán la extensión .linux y harán que el archivo sea ejecutable. Ahora el agente debería ser ejecutable como un comando y producir su salida típica. El | head trunca todo lo que sigue a la 10ª línea de salida:

Si quieres configurar o ampliar el agente, tendrás que crear tú mismo los directorios necesarios. La ubicación de los tres directorios obligatorios está codificada en el agente en variables que empiezan por MK_ y también se proporcionan a los Plugin a través del entorno del sistema:

Debes crear estos tres directorios (con los permisos predeterminados de 755 y root como propietario):

Si quieres utilizar rutas diferentes, simplemente edita /usr/bin/check_mk_agent.

Para configurar un xinetd existente que utiliza el directorio /etc/xinetd.d/ para la configuración, tanto el archivo TGZ como los paquetes DEB y RPM vienen con un script que automatiza los dos pasos necesarios: primero instala la configuración y luego hace que xinetd vuelva a leer la configuración modificada. Tienes que llamar al script con las rutas de archivo completas:

Si instalas el script del agente manualmente, crea el archivo de configuración /etc/xinetd.d/check-mk-agent con el editor. El contenido es suficiente:

Aquí hemos añadido una línea (comentada) que restringe el acceso a dos servidores Checkmk. Puedes ver más opciones de configuración consultando el archivo ~/share/check_mk/agents/scripts/super-server/1_xinetd/check-mk-agent de tu servidor Checkmk.

Si tu xinetd utiliza el antiguo esquema de configuración con un solo /etc/xinetd.conf grande, transfiere la configuración de ejemplo de /etc/check_mk/xinetd-service-template.cfg a /etc/xinetd.conf.

Cuando la configuración de xinetd esté completa, reinícialo:

Ya estás listo para la prueba de conexión.

En primer lugar, comprueba si tu /etc/services ya contiene una entrada para el puerto 6556:

Si no es así, debes registrar Checkmk como servicio. Para ello, añade la siguiente línea. La notación aquí es exactamente la misma que la almacenada en la tabla de la IANA con un solo guión:

El formato del archivo de configuración /etc/inetd.conf difiere entre las distintas variantes. Consulta los comentarios del archivo de configuración y la página del manual (man 5 inetd.conf) para saber cuál es el formato que coincide con tu inetd. A continuación, aparece la configuración que coincide con openbsd-inetd, con dos líneas para el soporte IPv4 e IPv6. De nuevo, es importante tener en cuenta la notación correcta:

Tras editar el archivo de configuración, reinicia inetd, por ejemplo con:

Dependiendo del sistema init utilizado y del súper servidor instalado, este comando puede variar.

Primero comprueba si se puede (re)iniciar xinetd o inetd:

Ahora puedes conectarte con telnet o nc (netcat) en el puerto TCP 6556 - primero desde el propio host, después desde el servidor Checkmk:

Si recibes una notificación de conexión denegada aunque (x)inetd esté activo, comprueba la configuración de tu cortafuegos.

SSH funciona con "autenticación de clave pública". Para ello, primero generas un par de claves coincidentes, donde una es pública y la otra privada. Al seleccionar el algoritmo puedes elegir entre rsa, ecdsa o ed25519. En el siguiente ejemplo, utilizas el comando ssh-keygen -t ed25519 como usuario del site:

Deja el nombre de archivo vacío para utilizar el nombre de archivo sugerido. Por supuesto, puedes especificar una ruta diferente, por ejemplo si quieres trabajar con claves separadas para host individuales.

Importante: No especifiques una frase de contraseña! Cifrar el archivo con la clave secreta no serviría de nada, después de todo, seguro que no quieres tener que introducir la frase de contraseña cada vez que inicies el servidor Checkmk...

El resultado son dos archivos en el directorio .ssh:

La clave privada se llama id_ed25519 y sólo puede leerla el usuario del site (-rw-------) - ¡y eso es bueno! La clave pública id_ed25519.pub tiene este aspecto:

El siguiente paso debe tener lugar en (cada uno de) los host(s) Linux monitorizados mediante SSH. Inicia sesión allí como root y crea el subdirectorio .ssh en su directorio de inicio (/root), si aún no existe. Con el siguiente comando, los privilegios de acceso se establecerán correctamente en 700 de inmediato:

Ahora abre el archivo authorized_keys con un editor de texto (basado en consola) de tu elección. Si este archivo no existe ya, el editor lo creará automáticamente:

Copia el contenido de las claves públicas en este archivo. Esto puede hacerse, por ejemplo, con el ratón y copiar y pegar. Sé preciso! Cada espacio cuenta. Asegúrate también de que nunca hay dos espacios en una línea. Y: Si el archivo ya existe, simplemente añade una nueva línea a continuación .

Lo que viene ahora es muy importante! La clave SSH debe utilizarse exclusivamente para ejecutar el agente. SSH ofrece algo así bajo el nombre de restricción de comandos. Para ello, pon el texto command="/usr/bin/check_mk_agent" al principio de la línea que acabas de crear -separado del resto por un solo espacio-. Tendrá un aspecto parecido a este

Guarda el archivo y comprueba los permisos: sólo el propietario puede tener permisos de escritura en este archivo.

A continuación, prueba el acceso al agente con el comando ssh:

La primera vez tendrás que confirmar la huella digital de la clave introduciendo yes. A partir de ese momento, todos los demás accesos podrán realizarse sin interacción del usuario, incluido el sondeo automático del script del agente por parte del servidor Checkmk cada minuto.

Si no funciona, por favor, check:

Con sistemas de destino muy antiguos, también es posible que las claves con las curvas elípticas (ed25519 y ecdsa) sean desconocidas. En este caso, genera una clave RSA adicional e introdúcela también en authorized_keys. SSH utilizará entonces automáticamente la clave más fuerte conocida para la conexión.

El sistema de destino ya está preparado. Ahora sólo falta la configuración del propio Checkmk. Esto se hace mediante el conjunto de reglas Setup > Agents > Other integrations> Custom integrations > Individual program call instead of agent access. Crea aquí una regla para los host afectados e introduce ssh -T root@$HOSTNAME$ o ssh -C -T root@$HOSTNAME$ (para una compresión adicional de los datos del agente) como comando:

Puedes ejecutar la prueba de conexión en la GUI en Setup > Hosts > Properties of host > Test connection to host con el botón Run tests. Si la prueba falla con timeout o acceso denegado, comprueba si has utilizado el nombre del host con la misma ortografía que al realizar la prueba en la línea de comandos - OpenSSH diferencia entre nombre corto del host, FQDN y dirección IP. También puedes acceder al host utilizando su dirección IP. En este caso tienes que utilizar la macro $HOSTADDRESS$ que se sustituye por la dirección IP cacheada (por Checkmk) del host.

Después de guardar y ejecutar Activar cambios, el host se añade a la monitorización. En la monitorización, el servicio Check-MK Agent se muestra ahora con la nota "Transporte a través de SSH". Para realizar más diagnósticos, se pueden utilizar los comandos cmk -D y cmk -d, que se explican en el artículo sobre la línea de comandos.

También puedes trabajar con más de una clave SSH. Coloca las claves en cualquier directorio. En la regla Individual program call instead of agent access debes especificar entonces la ruta a la respectiva clave privada con la opción -i. Lo mejor es utilizar aquí $OMD_ROOT en sustitución de la ruta al directorio del site (/omd/sites/mysite). El comando completo podría ser entonces ssh -i $OMD_ROOT/.ssh/my_key -T root@$HOSTADDRESS$, y así la configuración también sería ejecutable en un site con un nombre diferente:

Esto te permite utilizar distintas claves SSH para distintos grupos de host utilizando varias reglas diferentes.

Para evitar proporcionar a posibles atacantes datos en texto plano a pesar de los túneles SSH, debes desactivar cualquier acceso al puerto 6556 que aún pueda estar disponible en la monitorización del host. Si el comando ss -tulpn | grep 6556 anterior no ha encontrado ningún proceso escuchando en el puerto TCP 6556, ya has terminado de configurar el túnel SSH. Si sale una línea, el proceso que se ha encontrado debe ser desactivado permanentemente.

En cualquier caso, no olvides hacer una prueba final: Ahora ya no debería ser posible conectarse al puerto 6556:

La configuración de la encriptación con el Agent bakery es la siguiente: con el primer paso, la creación de la regla Symmetric encryption (Linux, Windows), casi has terminado. Ahora sólo tienes que crear y distribuir los nuevos agentes. El archivo /etc/check_mk/encryption.cfg se crea automáticamente y se incluye en los paquetes de los agentes. Sólo queda el tercer paso, es decir, la creación de la regla Enforce agent data encryption.

Aunque un atacante no pueda ejecutar ningún comando, los datos de monitorización del agente podrían serle útiles, porque contienen, entre otras cosas, una lista de todos los procesos que se ejecutan en el sistema. Por eso, es mejor que nadie pueda acceder fácilmente a esos datos.

Si compartes el Agente Checkmk a través de xinetd, es muy fácil y eficaz restringir el acceso a direcciones IP concretas -y a las del servidor de monitorización, por supuesto-. Esto puede conseguirse rápidamente mediante la directiva only_from de tu archivo de configuración xinetd. Introduce direcciones IP o rangos de direcciones (en la forma 12.34.56.78/29 o 1234::/46) separados por espacios. También se permiten nombres del host. En este caso, el sistema comprueba si el nombre del host determinado por la resolución inversa de la dirección IP del host solicitante coincide con el introducido:

En las ediciones comerciales, los usuarios de Agent bakery pueden configurar las direcciones IP permitidas mediante el conjunto de reglas Allowed agent access via IP address (Linux, Windows). Este conjunto de reglas se encuentra en Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Generic Options.

Por supuesto, un atacante puede falsificar muy fácilmente su dirección IP y conectarse así al agente. Pero entonces es muy probable que no reciba la respuesta, porque la respuesta irá al servidor de monitorización legítimo. O bien el atacante recibe realmente una respuesta, pero el servidor Checkmk no recibe ningún dato e informará rápidamente de un error.