Doraemon

Para empezar, me gustaría hablar de aquellos servicios que tienen como objetivo monitorizar la red. El objetivo de hacer un monitoreo de red es asegurar que todos los servicios se encuentran disponibles y controlar cómo se está comportando la misma. Para estas tareas se han usado Nagios y Ntop con nProbe, respectivamente.

Nagios es un servicio que se despliega en la red interna de la organización y que tiene como objetivo verificar que todos los servicios están levantados y disponibles. Para ello, se configura qué servicios existen y en qué direcciones se encuentran. De esta manera, Nagios puede comprobar su estado e incluso enviar alertas ante posibles caídas. Este tipo de servicios es de vital importancia en una organización, pero más aún en una de este estilo que va a tener servicios públicos. Configurado adecuadamente te permite llevar un control exhaustivo de cómo se encuentran los servicios de forma centralizada.

Panel de control de Nagios

Ntop es una herramienta que permite analizar el tráfico entrante por las interfaces de un dispositivo. Esta es perfecta para hacer un análisis del uso de la red y detectar saturaciones, usos inadecuados o incluso comportamientos sospechosos que indiquen un posible ataque. No obstante, Ntop solo analiza las trazas que atraviesan el dispositivo donde está instalado. Por lo tanto, para analizar toda la red, habría que instalar Ntop en un router o incluso hacer que todo el tráfico fluyera a través de Ntop. Aunque se podrían llevar a cabo estas opciones, preferí un enfoque más distribuido con nProbe.

nProbe es otra herramienta creada por la misma empresa de Ntop que se tiene la labor de recopilar datos de la red y enviarlos a un servidor de Ntop. De esta manera, podemos monitorizar toda la red instalando esto dentro del router. Esta opción me pareció la más acertada porque permite gestionar toda la red sin instalar un servicio pesado en el Ntop completo. Además, tiene la ventaja de que si tenemos más de una sede, podemos centralizar el panel de Ntop y hacer que los datos de todas las sedes confluyan hacia un mismo servidor de Ntop.

Panel de control de Ntop

Ahora voy a pasar a explicar una parte esencial de la red: DHCP y DNS. Ambos son servicios imprescindibles para una red, pero el más interesante y complejo de los dos es el DNS.

La idea de tener un servidor DNS es permitir que los usuarios de los servicios puedan utilizar nombres de dominio y no tener que recordar las IPs de los dispositivos. Además, como la empresa provee servicios públicos es interesante tener un servidor DNS público para estos servicios. Ambos servicios han sido gestionados con PowerDNS, con la diferencia de que el DNS público se encuentra manejado por Cyberpanel. Lo que sí es importante destacar es que ambos hacen uso de una base de datos para almacenar los registros DNS.

Como única cuestión interesante a destacar, quiero analizar la necesidad de tener un DNS público self-hosted. En esta caso, se llevo a cabo el despliegue de un DNS público con Cyberpanel ya que el proyecto así lo exigía. Esto tiene la ventaja de aportarte control total sobre el servidor DNS y su monitoreo. No obstante, en la gran mayoría de ocasiones, conviene hacer uso de servicios como Cloudflare. Estos no solo te ofrecen la gestión de un servidor DNS con casi el 100% de uptime, sino que además poseen protecciones contra ataques DDoS y otras cuestiones de seguridad sin tener que complicar la infraestructura. Por eso mismo, muchas veces convendrá más contratar este tipo de servicios para el DNS público y desplegar uno más sencillo para el privado.

Primeramente, me gustaría comentar el valor que aporta un directorio LDAP en una empresa. Un directorio LDAP permite a la empresa centralizar la información de todos los empleados y gestionar la autorización de los mismos. Esto es lo que permite que un cliente de correo autocomplete los datos de una dirección solo aportando el nombre; también permite que se compruebe si ciertos empleados tienen o no acceso a ciertos datos o servicios; entre otros. Por eso mismo, decidí desplegar este servicio con OpenLDAP ya que será de gran utilidad.

Poder permitir el acceso remoto de trabajadores que no pueden acudir a la oficina es primordial en muchas empresas. Para ello, es necesario un canal de comuniación que permita acceder remotamente a un dispositivo de forma segura. Ahí es donde entra en juego OpenVPN. Esta es una herramienta que permite crear un túnel para conectar dos dispositivos de forma segura. Para ello, solo es necesario una clave de confianza y conocida por el servidor de OpenVPN. Se elegió esta herramienta y no otras muy populares como Wireguard ya que OpenVPN permite simular que el dispositivo remoto se encuentra físicamente en la misma red. Una desventaja que posee OpenVPN es que, con un certificado válido, cualquier persona podría conectarse a la VPN. Aquí entra el directorio LDAP.

La idea es sencilla: solo los usuario autorizados pueden conectarse a la VPN. De esta manera, OpenVPN cuando recibe una solicitud de conexión con certificado válido, comprobará que este usuario tenga la autorización adecuada preguntando al directorio LDAP. Así, solo los usuarios con permiso verán la petición de acceso a la VPN aceptada.

Esta sección es sencilla y es que para el despliegue de los servicios públicos se ha utilizado la herramienta llamada Cyberpanel. Esta herramienta permite la gestión y el despliegue de servidores web, SMTP, IMAP, POP3, FTP y muchos otros de forma sencilla y centralizada. Es cierto que todos estos servicios podría montarse con sus herramientas correspondientes de forma separada (Apache, Dovecot, Postfix, FTPd...), pero Cyberpanel aporta una gestión sencilla y centralizada de los mismos con poco esfuerzo.

Una cosa que sí merece especial mención es el desacople de la base de datos. Cyberpanel hace uso de una base de datos para almacenar toda la información y esta se instala en el mismo dispositivo. Esto implica que habría una base de datos en una DMZ y eso considero que es un posible vector de ataque. Por eso mismo, decidí desacoplar la base de datos e indicarle a Cyberpanel que debía usar otra base de datos en otra ubicación y que usaría la de MariaDB en la red privada.

Panel de control de Cyberpanel

Otro aspecto muy importante a la hora de crear y administrar un sistema es la seguridad. Es necesario implementar mecanismos defensivos para proteger la infraestructura y los servicios de posibles atacantes; pero también es imprescindible diseñar un plan de auditoría de seguridad para verificar las posibles fallas.

En cuanto a lo primero, los principales métodos defensivos fueron una buena configuración de Firewall y el despliegue de Snort para la detección de intrusos. Una adecuada configuración de Firewall es vital para la seguridad de un sistema y aquí realicé un análisis profundo de cada dispositivo para determinar qué reglas son las mínimas necesarias para su funcionamiento. Además, hice distinción entre reglas stateless y stateful para un protección más eficaz. El despliegue de Snort en el router me pareció una robusta medida de alerta ya que dispone de grandes reglas creadas por la comunidad que recogen patrones de ataque e intrusión muy conocidos.

Por otro lado, en la faceta ofensiva, realicé una auditoria de seguridad mediante nmap y, sobre todo, Greenbone/OpenVAS. Esta última herramienta es muy utilizada ya que permite hacer análisis tanto perimetrales como autorizados de diferentes dispositivos, generar alertas, generar informes, programar análisis y muchas cosas más. En este proyecto solo se llevó a cabo un análisis perimetral y autorizado de los servidores debido a la falta de tiempo y experiencia. No obstante, esta herramienta habría permitido un crear un plan de auditoría mucho más robusto.

Finalmente, también se desplegó un clúster de Kubernetes. Este despliegue era parte del proyecto por lo que el caso de uso no es lo más relevante. La práctica solo requería una simulación de un clúster usando minikube, pero yo decidí utilizar una instalación completa con kubeadm para ser más realista. De esta manera, podría aportar el valor real de un clúster de K8s. Además, también incluí el despliegue del dashboard de K8s para gestionar más cómodamente todo el clúster.

Durante el desarrollo del proyecto escribí una guía completa para poder desplegar diferentes tipos de clústeres de Kubernetes. Ver guía en Notion ↗

Como aspecto a destacar, quiero mencionar que como el servicio desplegado en K8s fue un servidor Nginx privado para la empresa había una necesidad de compartir almacenamiento entre replicas. De lo contrario, según qué pod respondiera se serviría una página distinta y el despliegue de nuevas versiones de la web sería más complicado. Por eso mismo, se creo PV y un PVC que permitía la conexión a un NFS que contendría el contenido del servidor web. Asimismo, para asegurar una configuración uniforme de todas las réplicas se recurrió a un ConfigMap para la configuración de Nginx.

Panel de control de K8s