Instalando el servidor de Base de Datos

Para ir completando el lab, voy a instalar un servidor de Base de Datos MySQL. En concreto, voy a instalar la versión 5.7 de la Community Edition. La máquina virtual sobre la que voy a instalarlo va a ser la más potente del entorno: 2 procesadores virtuales, 4 GB de RAM, en cuanto al disco, voy a configurar dos discos, uno de 25 GB para sistema operativo y swap y otro de 200 GB de datos. El sistema va a estar conectado a la red de backend.

La primera tarea que hay que hacer es configurar el disco duro adicional que he instalado en la máquina virtual:

mysql1

Voy a crear la partición para datos en el dispositivo /dev/sdb:

mysql2

El siguiente paso consiste en crear el sistema de ficheros en la unidad. Voy a formatear la nueva unidad con un sistema ext3.

mysql3

A continuación, voy a crear el punto de montaje (/var/local/data) para el nuevo disco y a configurar el arranque para que este montaje. Para esto último edito el fichero /etc/fstab

mysql4

Rearranco el servidor y compruebo que los discos están configurados:

mysql5

Una vez instalado y configurado el agente NRPE de Nagios voy a comenzar con la instalación del gestor de bases de datos. La versión que voy a instalar es la 5.7.

mysql6

El proceso de instalación es bastante rápido. En él se solicita la contraseña del administrador de la base de datos. Voy a probar que soy capaz de entrar:

mysql7

Me conecto al servidor y puedo entrar. La siguiente tarea es configurar el servidor MySQL. En primer lugar, ejecuto el script de securización del servidor de base de datos. Se trata de un script interactivo que va haciendo una serie de preguntas.

mysql8

A continuación voy a definir el directorio de datos para que sea el directorio en el que he montado el segundo disco duro (/var/local/data). Desafortunadamente, la instalación de mysql ya ha definido un directorio de datos en /var/lib/mysql y ahora, me temo, que me va a tocar soportar dificultades. Estaba dispuesto a intentar seguir el manual online de MySQL en lo relativo a la definición del directorio de datos pero he encontrado un sitio que tiene un hack, aparentemente, más fácil. Como todavía no tengo datos no pierdo nada con intentarlo.

En primer lugar voy a modificar el propietario y el permiso del nuevo directorio de datos para dejarlo como el actual:

mysql9

Ahora detengo el servicio mysqld y copio los contenidos del directorio de datos actual al nuevo directorio:

mysql10

Cambio el fichero de configuración de MySQL para apuntar al nuevo directorio de datos. Me cuesta un poco encontrar el fichero de configuración pero descubro que, aparentemente, el que me interesa es: /etc/mysql/mysql.conf.d/mysqld.cnf:

mysql11

Finalmente, rearranco el servicio y compruebo si puedo acceder: no puedo. He ido teniendo distintos problemas de permisos y al final, lo que he decidido es cortar por lo sano: he renombrado el directorio de datos existente y he cambiado el punto de montaje del disco duro de datos al directorio de datos de la instalación de MySQL. Con esto he conseguido, finalmente, echarlo a andar.

El siguiente paso es instalar phpMyAdmin para la administración, a través de un interfaz más amigable, del sistema.  Voy a instalarlo, como no podía ser de otra forma, en el servidor de administración y necesito crear un usuario, con privilegios de administrador, que pueda acceder desde este servidor.

mysql12

En el proceso de configuración del acceso he descubierto algunas cosas que no sabía. Por ejemplo, que MySQL sólo es capaz de escuchar en una dirección IP por lo que el acceso de phpMyAdmin no puede hacerse a través de la interfaz de gestión. Afortunadamente, el servidor de administración está conectado a la DMZ con lo que este inconveniente se soslaya (creando, por supuesto, un usuario distinto). Finalmente he conseguido que phpMyAdmin sea accesible.

mysql13

mysql14

En principio, con esto, la instalación del servidor MySQL queda completada. Me quedaría instalar un plugin para realizar la monitorización del servidor desde Nagios pero esto lo voy a poner en mi lista de ToDo’s.

Despliegue del servidor de logs de Nagios

En mi entorno virtual ya había desplegado un servidor de logs, sin embargo, el servidor rsyslog no tiene capacidades analíticas, simplemente recolecta los logs y punto. Navegando por la web de Nagios veo el producto que tienen para gestionar logs y me decido a probarlo. Hay una versión free para volúmenes pequeños de datos y procedo, a descargarla.

La primera alegría que me llevo es que existe una distribución, en forma de plantilla OVF, que permite desplegar la máquina virtual, de forma inmediata, en mi entorno lab. Profundizando un poco, veo que se trata de un CentOS versión 6 con el producto pre-configurado.

Una vez descargada la plantilla de máquina virtual me pongo a importarla en el entorno:

nagiosls1

nagiosls2

Antes de arrancarla voy a configurar dos interfaces de red en el servidor:

  • Una interfaz conectada a la DMZ para tener acceso a la interfaz web desde el PC de casa.
  • La otra interfaz de red voy a conectarla a la red de gestión.

Por último, voy a utilizar mi servidor de logs actual para concentrar todos los logs y como fuente de logs para Nagios Log Server.

nagiosls8

nagiosls9

Una vez ajustada la configuración, arranco la máquina virtual:

nagiosls3

Me conecto a la máquina para realizar las configuraciones finales:

  • En primer lugar, cambio la password por defecto que aparece en el banner de la consola.
  • Me doy cuenta que el teclado está en inglés, así que voy a cambiar la configuración editando el fichero: /etc/sysconfig/keyboard. Para que la configuración tenga efecto es necesario reiniciar la máquina.
  • El siguiente paso es cambiar el nombre del host. Para ello se edita el fichero /etc/sysconfig/network. El nuevo nombre de host es cenagls.
  • Es necesario configurar los parámetros de red. Para ello, empezamos con el fichero /etc/resolv.conf configurando el servidor de DNS del entorno y el dominio.
  • Configuro, a continuación, las interfaces de red:

nagiosls10

La interfaz eth0 es la que está conectada a la red de gestión y la interfaz eth1 es la que está conectada a la DMZ. Edito los ficheros de configuración correspondientes que se encuentran en /etc/sysconfig/network-scripts/

nagiosls11

nagiosls12

  • Reiniciamos el servicio de red y comprobamos que todo funciona mediante unos cuantos ping:

nagiosls13

  • Finalmente, creamos las entradas necesarias en la base de datos del servidor DNS para el nuevo servidor.

Con esto finalizamos la primera parte del proceso de configuración el servidor de log de Nagios. Para continuar la configuración, nos conectamos, desde el navegador del PC a la URL del servidor de logs de Nagios:

nagiosls14

Completo el formulario y pulso el botón de finalizar instalación:

nagiosls15

Entro en el menú de Administración y escojo la opción de actualizar licencia:

nagiosls16

Escojo la opción de licencia limitada y gratuita que, de acuerdo a la información de la web de Nagios, me permite almacenar hasta 500MB diarios de logs:

nagiosls17

Lo que queda por hacer es configurar las fuentes de logs y comprobar que éstos se reciben y procesan en la herramienta.

nagiosls18

En la infraestructura desplegada tengo un pequeño problema y es que el router VyOS no es capaz de enviar logs al puerto que, por defecto, utiliza Nagios log server (5544). Por lo tanto, tengo que configurar Nagios log server para que escuche en el puerto estándar de syslog (el 514) esto requiere un poco de trabajo.

En primer lugar, lo que necesito es cambiar el usuario bajo el que el servicio Nagios LS se ejecuta ya que para poder abrir los puertos privilegiados (por debajo de 1024) es necesario tener permisos de root. Para esto, edito el fichero /etc/sysconfig/logstash para cambiar el usuario a root:

nagiosls19

Ahora, a través de la interfaz web, configuramos la escucha en el puerto 514. Copiamos la entrada de configuración de Syslog y cambiamos el puerto de escucha al 514:

nagiosls20

Salvamos y aplicamos la nueva configuración y comprobamos que funciona:

nagiosls21

Voy a lanzar un par de logins fallidos en el router VyOS para ver que los mensajes se recogen en el log:

nagiosls22

Montando un repositorio para control de versiones

El entorno lab empieza a complicarse, para poder tener control sobre los distintos ficheros de configuración de los servidores así como para los desarrollos software, he decidido montar un servidor para subversion.

Voy a crear un servidor Ubuntu con 1GB de RAM y 25GB de disco. El servidor va a estar montado en la DMZ para que, de esta forma, sea accesible a toda la red doméstica.

El primer paso para la instalación de un servidor SVN es instalar un servidor Apache que va a posibilitar el acceso a los repositorios a través de WebDAV instalamos, además, la biblioteca de SVN para apache.

svn_1

A continuación, instalo subversion:

svn_2

Creo una clave privada y una CSR para un certificado SSL de servidor. Esta CSR la firmo con la entidad certificadora que tengo en el entorno lab.

svn_3

svn_4

Voy a hacer que la autenticación de los usuarios a los distintos repositorios utilice el directorio LDAP que he montado. Para conseguir esto, voy a instalar el módulo authnz_ldap de Apache.

svn_5

He creado un usuario en LDAP (testuser) y voy a probar que mi servidor LDAP funciona:

svn_6

svn_7

Es posible utilizar el LDAP para autenticación así que voy a configurar Apache para que autentique contra el LDAP. Para esto, es necesario editar el fichero de configuración default-ssl.conf (tengo un redirect permanent al sitio https) y voy a añadir la siguiente sección Location:

svn_8

Voy a probar el acceso desde un cliente Windows 7:

svn_9

svn_10

En principio, Apache está configurado, ahora tengo que seguir con la instalación y configuración de Subversion. Para empezar, voy a crear un directorio para los repositorios y un repositorio de prueba:

svn_11

svn_12

Voy a crear un archivo de prueba y a subirlo al repositorio:

svn_13

svn_14

Tengo un pequeño problema con los permisos del repositorio pero ya lo arreglaré más adelante. Voy a intentar acceder a través de la web:

svn_15

svn_16

En principio todo está funcionando. Los aspectos que tengo que corregir son:

  • Permisos de acceso a los repositorios.
  • Autenticación de usuarios que accedan a través de protocolo SVN a través de LDAP.

Securizando el acceso al servidor de administración

En  un post anterior hemos visto la configuración y despliegue de un servidor OpenLDAP en un servidor virtual dedicado y la instalación del paquete phpLDAPadmin desplegado en el servidor de administración del entorno lab. En este artículo me voy a centrar en cómo hacer seguro el acceso a ese servidor.

El acceso http al paquete phpLDAPadmin está habilitado pero voy a hacer que todos los accesos a las interfaces HTTP se realicen a través de https. Ahora que ya tengo mi propia autoridad certificadora, la parte de emisión de certificados está resuelta.

ldap2_1

El primer paso va a consistir en instalar el módulo ssl de apache y crear los directorios para claves y certificados.

ldap2_2

Vamos a crear una clave privada para el servidor y una solicitud de firma de certificado (CSR). Para evitar tener que introducir la contraseña de la clave cada vez que arranque apache, no voy a cifrar la clave privada.

ldap2_3

Una vez creada la CSR, la firmamos con la clave de la CA intermedia.

ldap2_4

ldap2_5

ldap2_6

Copiamos la cadena de certificados de la autoridad certificadora al directorio donde está el certificado y la clave privada:

ldap2_7

A continuación habilitamos la configuración por defecto del virtual host SSL, editando el fichero default-ssl.conf y ajustando los valores de los objetos de cifrado (clave, certificado y cadena de certificados) a los particulares del entorno.

ldap2_9

Rearrancamos el servicio apache y comprobamos que funciona HTTPS. Tras aceptar la excepción de seguridad (ya que se trata de un certificado autofirmado) podemos ver desde un cliente las características del certificado:

ldap2_10

Ahora me queda por hacer que los accesos a las interfaces de nagios y phpLDAPadmin sean a través de https. Voy a comenzar con phpLDAPadmin, en primer lugar, edito el fichero de configuración de phpLDAPadmin (/etc/phpladapadmin/apache.conf) para Apache y establezco el alias para el acceso al sitio web:

ldap2_11

Ahora voy a evitar que se pueda acceder a través de una conexión http forzando una redirección, para ello edito el fichero de configuración de apache (/etc/apache2/sites-enabled/000-default.conf) y añado la redirección permanente:

ldap2_12

Una vez que re-arranco el servidor Apache, cualquier solicitud se redirige a HTTPS.

ldap2_13

Creando una CA (autoridad certificadora)

La configuración del entorno lab va avanzando poco a poco y es el momento de empezar a pensar en la seguridad. El despliegue de servidores web va a requerir de certificados X.509 y, por supuesto, no voy a comprar ninguno. Así que, para atender el suministro de los distintos certificados, me voy a montar una CA, basada en OpenSSL, en el entorno lab. En concreto, en el servidor de administración que tengo desplegado.

El primer paso es crear el certificado raíz de la CA. Este certificado no lo voy a usar para firmar certificados sino para emitir certificados intermedios que sí emplearé para firmar.

1. Creación de la Estructura de Directorios

Para empezar voy a crear un árbol de directorios para manejar los ficheros de la CA. Este árbol de directorios va a estar basado en /root/ca:

ca1

2. Fichero de configuración de OpenSSL (openssl.conf)

A continuación voy a preparar el fichero de configuración para OpenSSL (/root/ca/openssl.conf). Las secciones y parámetros del fichero están descritos en la página de manual del comando ca (man ca). A continuación voy a ir haciendo una disección de las distintas partes del fichero:

  • La primera sección (ca) es obligatoria y, en este caso, la configuración instruye a OpenSSL a que tome los parámetros de configuración de la sección CA_default.

ca2

  • La siguiente sección (CA_default) define parámetros por defecto para la CA (directorios, nombres de ficheros, etc.). El directorio raíz para la CA es el que creamos al principio del proceso.

ca3

  • La siguiente sección (policy_strict) contiene las reglas que vamos a aplicar a la CA raíz. El certificado de la CA raíz sólo se va a usar para firmar certificados de CA’s intermedias.

ca4

  • Vamos a aplicar la política policy_loose para firmar certificados de cliente y servidor que pueden tener distintas procedencias:

ca5

  • La siguiente sección (req) contiene parámetros que se aplican en la creación de certificados o solicitudes de firma de certificados (CSRs).

ca6

  • La sección req_distinguished_name declara la información necesaria que deben incluir las solicitudes de firma de certificados. En esta sección se declaran, también, valores por defecto para esos parámetros.

ca7

  • La siguiente sección v3_ca contiene las extensiones que se van a aplicar en la generación del certificado de la CA raíz.

ca8

  • La sección v3_ca_intermediate contiene las extensiones a aplicar en la creación de los certificados de CA intermedias.

ca9

  • Las siguientes secciones, user_certs y server_certs, definen, respectivamente, las extensiones para la creación de certificados de autenticación de usuarios y servidores:

ca10

  • La extensión crl_ext se aplica en la creación de listas de revocación de certificados:

ca11

  • Finalmente, la extensión ocsp se emplea en la firma del certificado para el protocolo online de estado de certificados (OCSP):

ca12

3. Creación de la clave raíz (ca.key.pem)

El siguiente paso es crear la clave raíz y mantenerla bajo la más estricta seguridad. Voy a usar una clave de 4096 bits para el certificado raíz y los certificados de CA intermedia.

ca13

4. Creación del certificado raíz (ca.cert.pem)

Voy a usar la clave raíz generada en el paso anterior para crear el certificado raíz.

ca14

Verificamos el certificado generado:

ca15

ca16

5. Creación del par intermedio

Voy a crear, a continuación, un par intermedio (clave privada, certificado) para una CA intermedia. De este modo se protege la CA raíz ya que no se usa su clave para firmar certificados sino la clave de la CA intermedia. En caso de que la CA intermedia fuese comprometida, se revocarían todos los certificados firmados y se procedería a generar una nueva CA intermedia. El proceso es muy similar al realizado para la generación del par raíz (creación de estructura de directorios, creación de clave y creación de certificados) así que no voy a entrar en detalles excesivos.

ca17

Copiamos el fichero de configuración openssl.cnf del directorio padre al directorio actual y lo editamos modificando los cinco parámetros que aparecen marcados a continuación:

ca18

A continuación creamos la clave y el CSR para la CA intermedia:

ca19

y firmamos el CSR con la clave raíz de la CA …

ca20

Verificamos la cadena de confianza del certificado de la CA intermedia y creamos la cadena de certificados que permita validar los certificados emitidos por la CA intermedia:

ca21

En este punto, ya estamos listos para firmar certificados de servidor y de clientes.

Instalando un servidor LDAP

Al igual que en el caso del servidor DNS, voy a crear un servidor Ubuntu con 1GB de RAM y 25GB de disco para el servidor LDAP. La instalación y pre-configuración del servidor es calcada a la que hice para el servidor de nombres así que voy a obviar los detalles. La única diferencia es que mi servidor LDAP va a estar conectado a la red de Backend en lugar de a la DMZ como en el caso del servidor de nombres.

ldap1

La idea es instalar un servidor OpenLDAP para la autenticación y autorización de usuarios del entorno lab. Para empezar, me descargo los correspondientes paquetes y, durante la instalación, se me solicita la contraseña para el directorio.

ldap2

ldap3

A continuación, lanzo la reconfiguración del paquete instalado y voy contestado a las distintas cuestiones relativas a la configuración:

ldap4

ldap5

ldap6

ldap7

A continuación instalo la interfaz web de administración del directorio (phpLDAPAdmin) en el servidor de administración:

ldap8

Realizo la configuración editando el fichero /etc/phpldapadmin/config.php.

ldap10

ldap11

Una vez establecida la configuración, ya se puede acceder al servidor LDAP mediante phpLDAPadmin:

ldap2_1

Ahora un servidor de nombres

1. Introducción

Una vez completada la configuración de la red de gestión, voy a empezar a configurar distintos servidores en el entorno. Para empezar, voy a desplegar un servidor de nombres, basado en bind para mi entorno.

El servidor DNS, como no podía ser de otra forma, lo voy a instalar en la DMZ. La red virtual del lab, va tomando forma de este modo:

dns3

2. Creación y preconfiguración de la máquina virtual

Creo una máquina virtual con la configuración estándar (1GB de RAM y 10 GB de disco):

dns1

Instalo el sistema operativo, Ubuntu para no variar. Antes de ponerme con el despliegue de bind, tengo una serie de tareas que completar:

a) En primer lugar me toca configurar la segunda tarjeta de red para que se conecte a la red de gestión. Esto es, a priori, sencillo, no hay más que configurar la interfaz de gestión en /etc/network/interfaces

dns7

dns8

b) El segundo aspecto a configurar es enviar los logs al servidor de logs. Editamos el fichero /etc/rsyslog.conf y añadimos al final la línea correspondiente:

dns9

c) Por último, necesitamos instalar NRPE y configurarlo para poder monitorizar el servidor DNS desde Nagios. Los pasos a seguir están descritos aquí. Asimismo, tengo que crear los objetos necesarios en el servidor de Nagios para que la monitorización sea efectiva. Finalmente, ya tengo controlado el nuevo servidor en Nagios:

dns10

3. Instalando bind

Instalo el paquete bind9, las utilidades asociadas y la documentación:

dns11

Compruebo que el servicio named esté a la escucha en el puerto 53:

dns12

Todo correcto pero voy a hacer que sólo resuelva para IPv4. Para ello edito el fichero /etc/default/bind9 y añado –4 al parámetro OPTIONS.

dns13

Rearranco el servicio y verifico que no esté escuchando en el puerto 53 en IPv6:

dns14

4. Configurando bind

Ahora voy a configurar bind para que sea el servidor de nombres de mi dominio lab (tcantos.local).

Editamos el fichero de opciones de configuración de bind (/etc/bind/named.conf.options), añadiendo un acl para las redes de mi lab y configurando las opciones de acuerdo a mi entorno. El fichero queda de la siguiente forma:

dns15

A continuación vamos a definir las zonas. Para ello editamos el fichero /etc/bind/named.conf.local. Definimos una zona de resolución directa para las distintas redes del entorno lab y cuatro zonas de resolución inversa para las distintas redes:

dns16

dns17

Ahora definimos los ficheros de datos de bind para la resolución directa e inversa:

  • tcantos.local.db

dns18

  • 2.1.10.db (servidores de backend)

dns20

  • 3.1.10.db (Red de estaciones de trabajo)

dns21

  • 2.168.192.db (DMZ)

dns19

  • 199.168.192.db (Red de Gestión)

dns22

Una vez creados los ficheros necesarios, los llevamos al servidor y verificamos la configuración, las zonas y rearrancamos el servidor bind.

dns23

Finalmente, configuramos los clientes. En los servidores ubuntu editamos el fichero /etc/resolvconf/resolv.conf.d/head para añadir las líneas necesarias y ejecutamos resolvconf:

dns24

Verificamos el funcionamiento del servidor dns con dig y nslookup:

dns25

dns26

dns27

Parece que todo funciona, sólo queda configurar el resto de los equipos.