DevOps, Virtualizacion, Linux, Seguridad y un poco mas..
Hace casi dos años que no se actualizaba la sección del LAB en este blog. Muchos cambios se han realizado hasta ahora, aquí tratare de describir los equipos que forman el homelab/homenetwork.
Para leer más sobre los cambios en el Home LAB, puedes visitar la página dedicada a este!
Desde el punto de vista de los equipos de red físico estamos corriendo un PROBE y enviando esa información al COLLECTOR. Ahora le toca al ambiente virtual!
vSphere vDS (Distributed Switch) soporta la funcionalidad de NetFlow. Habilitando esta opción en nuestros vDS podremos ver información de red que posiblemente no paso por el PROBE que corre en el inter-vlan router o el router de borde. Por ejemplo, tráfico de una VM en 10.0.0.0/24 a otra VM en el mismo rango de red no llegara a los routers y por esto no lo veremos en en flowAnalyzer.
Así habilitamos Netflow en el vDS:
Inicialmente configure el probe para NetFlow 9, en la versión 5.1 en adelante soporta IPFIX. asi que cambie el puerto y pude ver el trafico llegando al colector.
Lamentablemente, el PROBE en vDS envía datos que el template en el colector no los tiene y esto hace que el proceso muera y reinicie, esto quiere decir que la información no llega al index de Kibana.
Investigare como puedo agregar los valores para inciar el proceso nuevamente. stay tunned!
Además de usar LibreNMS en aaNetworks, desde hace tiempo tenía la idea de usar NetFlow [https://en.wikipedia.org/wiki/NetFlow], esta configuración está al borde de OverKill en un home network, pero qué más da!
Flow Exporter: por el momento cuento con cinco equipos que cumplen con esta tarea, lo exportadores o probe como son mejor conocidos son los encargados de agregar los paquetes en flows y exportarlos al equipo central el cual se usara para hacer visualización de la información exportada.
Equipos cumpliendo esta tarea son:
zapp – Mikrotik RB493AH: RouterOS tiene la funcionalidad de capturar paquetes y enviarlos como flow ya sean v5, v9 o IPFIX, en mi caso está configurado para v9.
elzar – Ubuntu 17.04.
vul – Debian Jessie.
leela – Debian Stretch.
fry – Debian Stretch.
En el caso de Debian, existen varias opciones para tener la funcionalidad de PROBE, algunas son directamente en el kernel otras son aplicaciones que usan libcap, en mi caso me decidí por una aplicación llamada pmacct (ni idea como se pronuncia) la cual cuenta con un PROBE y muchas otras funcionalidades que en una entrada futura hablare de ellas.
Flow Collector: esta es la plataforma/aplicación responsable de recibir los flows que fueron generados en los PROBE, esta es la parte difícil, muchas de estas plataformas/aplicaciones son de pago. La razón, sencilla, los PROBE ya vienen en los routers asi que solo faltaría el Collector y dependiendo de la calidad del software que se use para colectar se verán los beneficios de tener NetFlow.
En mi caso he implementado una aplicación no tan conocida, tope con ella en un sub-reddit. flowAnalyzer es una combinación de varias aplicaciones las cuales forman el Colector y la aplicación de Análisis. Esta plataforma está basada en ELK, esta es la ventaja, luego que tenemos información generada en los probe importadas en un index de Kibana, podemos generar cualquier tipo de gráficos con información importada en el index.
En el caso de flowAnalyzer, los colectores son el producto del creador de la plataforma, estos colectores fueron desarrollados específicamente para esta tarea usando Python como lenguaje.
En esta tabla se pueden apreciar las versiones de flow soportadas y sus respectivos puertos.
Discover: esta es una sección típica de Kibana, aquí podemos ver casi en real-time todo lo que fue indexado y procesado por ElasticSearch y Kibana. Partiendo de este punto crearemos visualizaciones para luego crear dashboards.
La siguiente captura muestra todo el tráfico relacionado a la categoría Web que ha pasado por Vul.
Siguiendo con la agenda de usar IPv6 en un entorno NSX, intente desplegar un controlador solo asignando dirección IPv6 al pool designado para este, lamentablemente el despliegue fallo y mis sospechas apuntan a que el Controller no pudo alcanzar el Manager en la dirección IPv6 asignada.
Al intentar desplegar nuevamente el Controller, esta vez usando una dirección IPv4 todo término como de esperarse.
Tendré que investigar más sobre el tema para determinar si es una limitante o fue un error en mi configuración.
De camino a que todo este Dual-Stack (DS) en la red local y asignado una dirección IPv6 a vCenter (Appliance), todo tal como se esperaba excepto por la parte de configuración para el servidor DNS. Explícitamente no indica si es IPv4 o IPv6 pero por lo que pude ver solo acepta direcciones v4, el error es bastante genérico.
Aquí se puede ver una captura de toda la configuración:
