Reflexiones sobre túneles ssh

Al estar estos días jugando con túneles ssh y con la activación de varios servicios para cositas externas que voy hacer en el servidor que tengo siempre encendido, me hago una pregunta:

¿Es mejor publicar un servicio con NAT o hacerlo a través de un túnel SSH?

Partiendo de que quienes van a utilizar el servicio son de confianza. Queda claro que en la primera opción, el servicio es público a cualquiera que haga un rastreo, mientras que en la segunda queda ocultado a miradas indiscretas.

Tenerlo mediante un túnel añade una medida de seguridad adicional a la propia del servicio, es decir, añade la seguridad del SSH. Como inconvenientes están una penalización en el tiempo de respuesta, dar acceso por SSH a los usuarios de confianza y aumento de la complejidad del uso para los no iniciados.

Creo que me decantaré por la opción normal, publicar con NAT, sin obligar a usar un túnel. Es lo más lógico. El uso de túneles SSH lo dejo para tareas de administración remota. El sentido común debe prevalecer.

Comandos útiles

Por un pequeño programa en C que he hecho en el curro para monitorizar el funcionamiento de unos demonios he aprendido a utilizar algunas cosas útiles.

• Depurar llamadas al sistema de un programa en ejecución: strace
• Listado de ficheros abiertos: lsof
• Limites del sistema: ulimit

Son cosas que conocia pero que nunca las habia usado.

Bola Extra de aprendizaje: Recuerda cerrar todo aquellos ficheros (recursos) que abras...

El character encoding

En el servidor de la intranet del instituto llevaban unos meses con un problema que parecia irresoluble. Cuando alguien instalaba alguna aplicación web, lo hacia utilizando su propia configuración del juego de carácteres, sin preocuparse de los demas y toqueteando en la configuración del servidor apache o en la del php, haciendo que las aplicaciones tuviesen problemas con los caracteres especiales.

El juego de caracteres que menos problema presenta y que adopta una conjunto de caracteres más amplio es utf-8, pero no es buena idea definir ese juego de caracteres en la configuracion de apache (directivas AddDefaultCharset) o en la de php (directiva default_charset), puesto que al hacerlo asi, obligan a todas las aplicaciones a utilizar ese juego de caracteres y que ellas no puedan cambiarlo utilizando los meta-head charset o en el htaccess. Peor incluso es hacer esto utilizando otro conjunto de carácteres más restrictivos, como iso-8859-1 u otros.

Aunque si se hace esto, configurarlo en el servidor web (apache o php), la mejor solución sería ponerlo con utf-8, que es un conjunto de carácteres más amplio que las otras soluciones.

De todas formas, una vez teniendo diferentes aplicaciones que utilizan sus propias codificaciones de caracteres en el mismo servidor, lo mejor es no establecer una configuración por defecto en el apache (o en el php), sino dejar que se la propia aplicación la que decida la que se debe utilizar.

Y como siempre, Joel es dios, aqui lo deja bien clarito.

Más avances

Esto se mueve muy rápido, pero hemos avanzado un montón en la configuración del samba+ldap+pam para montar un dominio en 3'4 segundos. Incluso activar un servidor de impresión que use autenticación contra el dominio con samba y ldap ha sido muy rápida.

Mañana empezaré con el script make-dom-samba que automatice el proceso inicial, con instalación de los paquetes, configuración de ficheros y arranque de servicios.

Nos quedan los flecos de los drivers cups para todo el parque de impresoras que tenemos, cosa que nadie calculó allá por le mes de abril cuando se pensó en todo esto, además de la gestión de permisos para usuarios e impresoras, pero puede que sea incluso más rápido de lo que intuyo, si la suerte nos acompaña.

Funcionamiento del Nagios

Como me han llegado varias visitas con la consulta en google 'Como funciona el nagios por dentro' voy a intentar explicarlo de forma somera.

Nagios¹, para el que no lo sepa, es un sistema que sirve para monitorizar el estado de equipos y servicios remotos. Es decir, sirve para ver si un servidor esta funcionando o si el servicio web de apache esta corriendo adecuadamente en una máquina. En el caso de que detecte que un equipo/servicio falla, lo notifica mediante un aviso, que puede ser por email, SMS u otro sistema, dependiendo de la configuración.

Internamente, se compone de un demonio, llamado Nagios que es el que hace las peticiones a los equipos remotos para comprobar si esta activo o no. Este demonio, cada cierto tiempo lanza estas peticiones. También hace uso de un servidor web, que sirve para mostrar las páginas del estado de las máquinas remotas, refrescando el contenido cada X minutos.

Cada tipo de servicio monitorizado, se hace mediante un plugin. Un plugin no es mas que un programa que se ejecuta en el servidor donde esta instalado el nagios y sirve para hacer la consulta remota. Por ejemplo, el plugin del servicio SSH en una máquina llamada 'pek-machine', abre una conexión SSH² con la máquina remota, en el puerto 22 usado por el SSH.

Opcionalmente, existen algunos plugins que para su funcionamiento necesitan que en los equipos remotos se instale el servicio NRPE³. Estos plugin son muy especiales (pe: saber espacio de disco libre o carga del sistema) y a diferencia de los plugins normales, son ejecutados en el equipo remoto, con lo que hay que andarse con un poco de ojo por cuestiones de seguridad.

Deduciendo a partir de lo dicho anteriormente, la instalación de nagios necesita de servidor web (apache), fuentes del propio nagios y de los plugins (prefiero esta forma de instalación, con compilación incluida), y opcionalmente los fuentes del nrpe.

La web principal del nagios es http://nagios.org, desde donde te puedes bajar los fuentes y mucha documentación.

¹Para el significado de N.A.G.I.O.S. mejor visitar la http://es.wikipedia.org/wiki/Nagios
²Secure Shell
³Nagios Remote Plugin Execution

Seguridad versus rendimiento

Cada día que pasa compruebo que la seguridad y el rendmiento estan enfrentados y son dificiles de conjugar. Utilizando un símil sencillo es como ir en coche, cuanto más rápido vayas (más rendimiento), menos seguro vas. Y si quieres mejor el rendimiesin perder una piezca de seguridad, tienes que invertir (comprándote un helicoptero/avión).

Esto lo digo por una cosa que tenemos en el curro, queremos montar varias bases de datos en una misma maquina con hearbeat (un sistema de alta disponibilidad) pero para cada base de datos la vamos a tener corriendo con una instancia diferente de postgresql. Al hacerlo asi, no podremos darle los mejores parámetros de consumo de memoria al postgresql, porque dispondremos de menos memoria, desperdiciandose los buffers de ordenacion de consultas y las caches de consultas, al tenerlo separados para cada instancia de pgsql, obteniendo un rendimiento peor.

Como contraprestación que ofrece, si se cae una base de datos, es este caso viene dado por una instancia de pgsql, las otras no lo notan, ya que corren independientemente en las otras instancias de pgsql.

Personalmente, estoy más con la primera opción, que aparte de las ventajas anteriores (mejor aprovechamiento de los recursos) es más fácil de optimizar y las labores de recuperación en caso de catástrofe son más sencillas.

El porqué del nagios, mrtg y snmp

Se pueden encontrar muchos sitios donde explican como hacer una instalación simple de los servicios mrtg, snmp y nagios. Pero la mayoria se limitan a un recetario, sin entrar en explicaciones sobre los conceptos que esos servicios utilizan ni el porque de las cosas.

Por ejemplo, las variables que utilizan el mrtg para monitorizar el tráfico son una ristra de números cuyo nombre es algo parecido a '1.2.3.2.4.3.16.2' y esa variable sirve para ver el tráfico de salida de la interfaz de red eth1. Toma que toma. ¿como se sabe que esa variable es la adecuada y no otra?. Pues para eso se utiliza el programa snmpwalk, que te ayuda para determinar las descripciones de las variables y su correspondencia numérica. Existen navegadores gráficos para ir mirando por todo el árbol de variables proporcionados por el servicio snmp.

Lo mismo ocurre con nagios. En una primera visual se pueden ver conceptos como máquinas, servicios y usuarios, pero por detras de ellos, existen otros conceptos como los comandos (commands) que son los que hacen la tarea importante de monitorización de un recurso de red. Y me dejo atras el servicio nrpe, para la ejecución remota de algunos de esos 'comandos' cuando se trata de cosas muy particulares.

Lo importante de todo esto, es que no hay que quedarse con el procedimiento básico, el recetario, que te resuelve el problema de manera puntual, pero que no te sirve de mucho cuando se presenten cosas serias o te pidan algo que sale de lo típico. Hay que ir al fondo de la cuestión, para entender las cosas y su funcionamiento, de esa forma se aprende y se es capaz de solventar cualquier imprevisto.