Supervisión de Linux en modo heredado

En el artículo «Monitoring Linux» hay una descripción detallada de la instalación a partir de paquetes de deb o rpm, así que aquí solo explicaremos el procedimiento de forma breve.

En Checkmk Community, puedes encontrar los paquetes Linux del agente a través de Setup > Agents > Linux. En las ediciones comerciales, primero debes acceder a Agent Bakery en el menú Setup a través de Agents > Windows, Linux, Solaris, AIX, donde encontrarás los paquetes ya preparados. Desde allí, la opción 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 usar wget o curl para descargarlos directamente en el host de la supervisió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 una instalación inicial correctamente.

La instalación del paquete DEB en Debian, Ubuntu o distribuciones relacionadas 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 desde las ediciones comerciales en el menú Configuración a través de Agents > Windows, Linux, Solaris, AIX. El archivo TGZ contiene la estructura de directorios completa del agente de Linux para descomprimir en el directorio raíz del host supervisado.

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

Si has hecho todo correctamente, el script del agente debería ejecutarse ahora como un comando y generar su salida habitual. El comando «| head» trunca todo lo que sigue a la undécima línea de salida:

Si aquí aparece un número de versión inferior a 2.2.0, es probable que todavía tengas instalada una versión anterior 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 solo se instala el script del agente, pero aún no se realiza ninguna configuración del acceso. Para ello, necesitas el cuadro 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 ejecutable para root. /usr/local/bin/es una buena opción, ya que está en la ruta de búsqueda y está pensado para extensiones personalizadas. Como alternativa, puedes usar /usr/bin o un subdirectorio de /opt. Nosotros usamos /usr/bin para que todas las pruebas coincidan con los otros métodos de instalación. También puedes realizar la instalación directamente con wget si está disponible:

No te olvides de los dos últimos comandos: estos 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 generar su salida habitual. El comando | head trunca todo lo que sigue a la décima 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 complementos a través del entorno del sistema:

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

Si quieres usar rutas diferentes, solo tienes que editar /usr/bin/check_mk_agent.

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

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 en tu servidor Checkmk.

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

Cuando hayas terminado de configurar xinetd, reinícialo:

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

Primero, comprueba si tu archivo «/etc/services» ya contiene una entrada para el puerto 6556:

Si no es así, Checkmk debe registrarse 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 de /etc/inetd.conf varía según las distintas variantes. Consulta los comentarios del archivo de configuración y la página del manual (man 5 inetd.conf) para encontrar el formato que se ajuste a tu inetd. A continuación, se incluye la configuración correspondiente a openbsd-inetd con dos líneas para la compatibilidad con IPv4 e IPv6. Una vez más, es importante tener en cuenta la notación correcta:

Después de editar el archivo de configuración, reinicia inetd, por ejemplo, con:

Dependiendo del sistema de inicio que uses y del super-servidor instalado, este comando puede variar.

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

Ahora puedes conectarte a 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 debes generar un par de claves a juego, una pública y otra privada. Al seleccionar el algoritmo, puedes elegir entre rsa, ecdsa o ed25519. En el ejemplo siguiente, utiliza el comando ssh-keygen -t ed25519 como usuario del sitio:

Deja el nombre del archivo en blanco para usar el nombre sugerido. Por supuesto, puedes especificar una ruta diferente, por ejemplo, si quieres trabajar con claves distintas para hosts individuales.

Importante: ¡No especifiques una frase de contraseña! Cifrar el archivo con la clave secreta no serviría de nada; al fin y al cabo, 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 solo puede leerla el usuario del sitio (-rw-------)— ¡y eso es bueno! La clave pública id_ed25519.pub tiene un aspecto similar a este:

El siguiente paso debe realizarse ahora en (cada uno de) los hosts Linux supervisados a través de 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 aún no existe, el editor lo creará automáticamente:

Copia el contenido de las claves públicas en este archivo. Puedes hacerlo, por ejemplo, con el ratón y copiar y pegar. ¡Sé preciso! Cada espacio cuenta. Asegúrate también de que nunca haya dos espacios en una línea. Y: ¡Todo debe estar en una sola línea! Si el archivo ya existe, simplemente añade una nueva línea debajo.

¡Lo que viene ahora es muy importante! La clave SSH debe usarse exclusivamente para ejecutar el agente. SSH ofrece algo parecido bajo el nombre de restricción de comandos. Para ello, escribe 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. Quedará algo así:

Guarda el archivo y comprueba los permisos. Solo el propietario puede tener permisos de escritura en este archivo.

A continuación, comprueba 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 ahí, todos los accesos posteriores se pueden realizar sin intervención del usuario, incluida la consulta automática del script del agente por parte del servidor Checkmk cada minuto.

Si no funciona, comprueba lo siguiente:

En 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 segura conocida para la conexión.

El sistema de destino ya está preparado. Ahora solo falta la configuración de Checkmk. Esto se hace a través del conjunto de reglas Setup > Agents > Other integrations> Custom integrations > Individual program call instead of agent access. Crea aquí una regla para los hosts 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 interfaz gráfica de usuario, en «Setup > Hosts > Properties of host > Test connection to host», con el botón «Run tests». Si la prueba falla por tiempo de espera agotado o acceso denegado, comprueba si has utilizado el nombre de host con la misma ortografía que al realizar la prueba en la línea de comandos: OpenSSH distingue entre el nombre de host corto, el FQDN y la dirección IP. Como alternativa, puedes acceder al host utilizando su dirección IP. En este caso, tienes que usar la macro $HOSTADDRESS$, que se sustituye por la dirección IP del host almacenada en caché (por Checkmk).

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 vía SSH». Para un diagnóstico más detallado, 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 la ruta a la clave privada correspondiente con la opción -i. Lo mejor es usar $OMD_ROOT aquí como sustituto de la ruta al directorio del sitio (/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 sitio con un nombre diferente:

Esto te permite utilizar diferentes claves SSH para diferentes grupos de hosts mediante el uso de 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 pueda seguir estando disponible en la supervisión del host. Si el comando ss -tulpn | grep 6556 anterior no ha encontrado ningún proceso a la escucha en el puerto TCP 6556, ya has terminado de configurar el túnel SSH. Si se muestra una línea, el proceso que se ha encontrado debe desactivarse de forma permanente.

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

La configuración del cifrado con Agent Bakery se realiza de la siguiente manera: Con el primer paso, la creación de la regla «Symmetric encryption (Linux, Windows)», ya casi has terminado. Ahora solo tienes que compilar y distribuir los nuevos agentes. El archivo «/etc/check_mk/encryption.cfg» se crea automáticamente y se incluirá en los paquetes de los agentes. Solo 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 seguir siendole útiles, ya que contienen, entre otras cosas, una lista de todos los procesos que se ejecutan en el sistema. Por lo tanto, es mejor que nadie pueda acceder fácilmente a los datos.

Si compartes el agente de Checkmk a través de xinetd, es muy fácil y eficaz restringir el acceso a direcciones IP específicas —y a las del servidor de monitorización, por supuesto. Esto se puede conseguir rápidamente mediante la directiva only_from en tu archivo de configuración xinetd. Introduce direcciones IP o rangos de direcciones (en el formato 12.34.56.78/29 o 1234::/46) separados por espacios. También se permiten nombres de host. En este caso, el sistema comprueba si el nombre de 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 a través del 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, así, conectarse al agente. Pero entonces es muy probable que no reciba la respuesta, ya que esta se enviará al servidor de monitorización legítimo. O bien el atacante sí recibe una respuesta, pero el servidor de Checkmk no recibe ningún dato y rápidamente informará de un error.