Opción 43 de DHCP para la configuración automática de ACS
Hoy vamos a analizar la famosa opción 43 de DHCP, que se utiliza principalmente en la autoconfiguración de dispositivos como puntos de acceso, conmutadores, teléfonos IP, CPE, dispositivos IoT y otros a través del protocolo TR-069. Asimismo, le mostraremos un ejemplo de configuración utilizando el servidor DHCP de un router Mikrotik, que proporciona parámetros a través de la opción 43 de DHCP y permite la autoconfiguración de servicios durante el proceso de asignación de la dirección IP al dispositivo. Esto nos permite, por ejemplo, detectar automáticamente un controlador externo al dispositivo, incluso si el equipo ha sido restablecido a los valores de fábrica. El documento RFC 2132 «DHCP Options and BOOTP Vendor Extensions» [1] aborda diversos tipos de información que pueden enviarse a través del protocolo DHCP, como, por ejemplo, el DNS, la máscara de subred, la dirección de la puerta de enlace (enrutador), los atributos específicos del proveedor y muchos otros. La Opción 43 se define en este RFC como «Vendor Specific Information» y se utiliza para que los clientes y los servidores DHCP intercambien información específica entre sí. El RFC no especifica qué valores se pueden enviar, ni de qué tipo de información se trata, y mucho menos el tipo de datos. Se limita a describir la estructura, que debe ser la siguiente: Código Len Información específica del proveedor 43 n i1 i2 … Código 1 Len 1 Fecha 1 Código 2 Len 2 Fecha 2 Código n Len n Fecha n T1 n1 d1 T2 n2 T2 … … … Con esta estructura, cada fabricante u organización puede estructurar los datos de la forma que le resulte más conveniente para su uso. Por ejemplo, para que los puntos de acceso puedan configurarse con las direcciones IP de los controladores Wi-Fi, lo que permite su «incorporación» al controlador centralizado; para que los teléfonos IP dispongan de la dirección IP o la URL del servidor de telefonía; y para que los routers compatibles con TR-069 puedan configurarse con la URL del ACS. ¡Y todo ello de forma automática! El objetivo de este artículo es mostrar el uso de la opción 43 junto con TR-069, enviando la URL del servidor ACS al CPE a través del servidor DHCP. Esto nos permite que el router, incluso si se ha reiniciado y carece de una «plantilla» de configuración, obtenga a través de DHCP la URL del servidor ACS, junto con el nombre de usuario y la contraseña, datos necesarios para integrarse en el ACS y permitir que el TR-069 aplique automáticamente las configuraciones en el CPE. Pero antes de continuar, voy a dejar algunos enlaces a otros ejemplos de casos de uso de la opción 43. Configure la opción 43 de DHCP para los puntos de acceso ligeros: https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/97066-dhcp-option-43-00.html Detección de ID de VLAN a través de DHCP: https://wiki.unify.com/wiki/VLAN_ID_Discovery_over_DHCP Utilice la opción 43 de DHCP para la configuración de los puntos de acceso Unifi:https://niksec.com/use-dhcp-option-43-for-unifi-accesspoint-provisioning/ ¿Cómo llegó el DHCP al TR-069? Si no sabe qué es el ACS, consulte nuestro otro artículo. El DHCP se ha incorporado como una de las formas de incorporación del ACS. La incorporación es el proceso mediante el cual se configura el CPE o el router con un servidor ACS.Existen tres formas de llevar a cabo el proceso de incorporación de los CPE a un servidor ACS, según la especificación TR-069 del Broadband Forum [2]: El objetivo final de cualquiera de los tres es el mismo: tener la URL del servidor ACS configurada en el CPE, para que este pueda gestionarse a través del protocolo TR-069. Proceso de solicitud de la opción 43 de DHCP El BroadBand Forum establece una serie de pasos para que el CPE pueda obtener la URL del ACS a través de DHCP. La siguiente imagen muestra los pasos, y a continuación vamos a comentar cada uno de ellos. Pasos a seguir en la comunicación: En la especificación del TR-069 también se definen otros campos o protocolos que pueden utilizarse con el mismo fin: la opción 125 de DHCPv4 y la opción 17 de DHCPv6. Asimismo, se mencionan diversas reglas de detección tras un reinicio y cómo abordar los problemas de conectividad con el ACS. Sin embargo, quedan fuera del alcance de este artículo. Ejemplo de una transacción DHCP con la opción 43: capturas de paquetes Ejemplo de configuración en Mikrotik En este artículo, veremos cómo configurar un router Mikrotik para que, a través del servidor DHCP, proporcione parámetros de autoconfiguración a los «clientes» mediante la opción 43. La configuración se basará en la topología que se muestra a continuación, similar a la utilizada en nuestras pruebas con un CPE de Nokia. En primer lugar, es necesario configurar el servidor DHCP y, a continuación, vincular los ajustes de la opción DHCP 43. Utilizamos la red 192.168.2.0/24 y la VLAN 881, tal y como se muestra en nuestro ejemplo: Seguramente se estará preguntando: ¿de dónde ha salido ese valor de la opción 43? Efectivamente, existe una regla que hay que crear, y en el siguiente artículo podrá consultar cómo generarla para su servidor ACS. Conclusión En este artículo, explicamos cómo utilizar el atributo «Option43» de DHCP para la autoconfiguración de un servidor ACS en CPE y diversos dispositivos. Analizamos su funcionamiento y cómo puede utilizarse para automatizar el envío de configuraciones específicas a los dispositivos mediante un protocolo tan habitual como el DHCP. Conocer las capacidades, características y opciones que admiten el fabricante y el modelo del equipo nos ayuda a automatizar diversas configuraciones, entre las que se incluye, entre otras, la gestión de un CPE de Nokia a través del protocolo TR-069. Referencias:[1] RFC 2132, Opciones DHCP y extensiones de fabricante de BOOTP, https://www.ietf.org/rfc/rfc2132.txt [2] TR-069, Protocolo de gestión de CPE en WAN, https://www.broadband-forum.org/pdfs/tr-069-1-6-1.pdf
VMware vs Proxmox – ¿Cuál elegir?
Introducción Hoy en día, cuando hablamos de servidores, los asociamos automáticamente a la virtualización. Atrás quedaron los días en que utilizábamos servidores bare-metal para ejecutar una sola aplicación. Con la facilidad de la virtualización y el mejor aprovechamiento de los recursos del servidor, se ha hecho casi obligatorio utilizar su servidor con algún software de virtualización. En la actualidad, dos grandes nombres lideran la virtualización: VMware y Proxmox. Más aún tras la noticia de la venta de VMware a Broadcom, este tema se ha vuelto aún más candente. Y la pregunta que se hace la mayoría es: ¿VMware o Proxmox? ¿Qué virtualizador elegir? ¿Cuál es el «mejor»? A lo largo de este post, haremos algunas comparaciones entre los dos virtualizadores para que puedas decidir cuál se adapta mejor a tus necesidades y, por supuesto, ¡conocer las principales características de cada uno! Resumen del servicio Proxmox es un virtualizador de código abierto actualizado y mantenido por Proxmox. Está basado en Debian y utiliza KVM/QEMU como virtualizador y LXC para contenedores. Destaca por ser gratuita y tener una gran variedad de funcionalidades, por lo que el límite de lo que puedes crecer y evolucionar está directamente ligado a tu conocimiento de la herramienta. Proxmox también destaca en lo que respecta a la compatibilidad con hardware antiguo, ya que está directamente vinculado al núcleo Linux utilizado. VMware es un virtualizador de código cerrado cuya actualización y mantenimiento corren a cargo, desde hace poco, de Broadcom. En la actualidad, ha dejado de ser gratuito y ahora su uso está sujeto exclusivamente a un sistema de licencias. Como virtualizador, utiliza tecnologías propias para la virtualización de servidores, y su alto rendimiento y estabilidad son innegables. Destaca por su interfaz sencilla y por unas funcionalidades que aportan un gran valor añadido en entornos de gran envergadura. La compatibilidad de VMware depende de la versión de la que se trate; cuanto más reciente es la versión, menor es la compatibilidad con equipos considerados antiguos. Facilidad de uso Proxmox, a primera vista, puede parecer confuso y difícil, sobre todo porque algunas configuraciones requieren la integración con la CLI. Sin embargo, una vez que te acostumbras a su interfaz y a las funciones que necesitas, todo resulta más fácil. También cuenta con una excelente documentación que cubre todas las funciones disponibles. También tiene soporte de pago, que los usuarios pueden elegir comprar o no, y cuenta con una buena comunidad activa. VMware tiene una interfaz más objetiva y fácil de usar. Con unos pocos clics, puedes poner en marcha una máquina virtual. En cambio, si desea acceder a otras funciones, deberá adquirir una nueva licencia y/o configurar otro software (por ejemplo, VEEAM, vCenter). Dispone de una excelente documentación y varias KB (Knowledge Base) que explican diversos problemas que pueden surgir. Rendimiento Ambos servicios funcionan bien. VMware destaca por ejecutar su sistema operativo en memoria RAM, lo que permite navegar mejor por su interfaz. Aparte de eso, ambos están muy cerca en términos de rendimiento en escenarios mixtos, utilizando máquinas virtuales Linux y Windows y diferentes tipos de almacenamiento y almacenamiento. Escalabilidad Ambos virtualizadores permiten aumentar los recursos (CPU/MEM/DISCO) de sus máquinas virtuales sin problemas y, si es necesario, ampliar incluso los recursos internos, como añadir más espacio en algún almacén de datos o disco de sus máquinas virtuales. Ahora, si adquiere otro servidor y desea aumentar su infraestructura de servidores, Proxmox maneja mejor la adición de un nuevo servidor a su sistema. Mientras que en VMware este servidor estaría aislado y habría que configurar un nuevo servicio (vCenter) para unir los servidores bajo su gestión, en Proxmox basta con crear un Cluster y dar de alta el nuevo servidor en el cluster (literalmente sólo estas dos configuraciones). Características y funcionalidades Ambos servicios tienen características y funcionalidades similares. En el caso de VMware, el acceso a ellos dependerá de la licencia que tengas, mientras que en Proxmox dependerá de si la versión en la que te encuentras tiene soporte para ello o no. Ejemplos de algunas de las funcionalidades que tienen en ambos: Costes Hicimos una simulación para un servidor con 1 CPU (Socket) y estos fueron los costes No necesitas una licencia para utilizar Proxmox, sólo el apoyo directo del fabricante si lo deseas. Estudios de casos y ejemplos prácticos Supongamos algunos escenarios y comprendamos dónde es interesante implantar VMware o Proxmox. P. D.: ¡ Voy a defender los entornos locales de los proveedores de Internet! Escenario 1: Tengo un servidor usado de antes de 2015 y me gustaría añadirlo a producción para virtualizar 5 VMs no críticas. Escenario VMware: Escenario Proxmox Es decir, en ambos casos podrá implementar su solución. Por supuesto, en el caso de VMware, además del precio de la licencia, deberá tener en cuenta el modelo de su servidor y, sobre todo, su año de fabricación. Los servidores muy antiguos no son compatibles con las versiones más recientes de VMware, y tendrá que realizar inversiones adicionales para dar soporte al escenario de copia de seguridad en caso de que cuente con más de 10 máquinas virtuales en su entorno. Escenario de actualización 1: Vi que la virtualización funcionaba muy bien, y ahora quiero añadir más VMs, pero ahora habrá VMs críticas, y para ejecutar estas VMs actualicé y compré un nuevo servidor. Escenario VMware: Escenario Proxmox Conclusión En cualquier caso, hemos visto que Proxmox y VMware son muy similares y pueden ofrecer el mismo resultado, ¡siempre que se cumplan algunos requisitos! Todo depende del tamaño de su infraestructura y de su criticidad. Lo primero que debemos tener en cuenta es la inversión que voy a realizar en licencias. En caso de que opte por utilizar VMware, considere si esa inversión no podría ser más útil en algún otro ámbito (por ejemplo, actualizar algún componente de mi servidor interno). Mi recomendación es la siguiente: si tu infraestructura está al 100%, con servidores nuevos que no necesitan actualización, y puedes permitirte las licencias, apuesta por VMware, porque te dará lo mejor en el mundo de la
Actualizaciones – Made4Flow, Made4Graph y Made4OLT – Febrero de 2024
Made4Flow – Versión 2.6.2 Modificaciones: Correcciones: Made4Graph – Versión 2.4.3 Añadidos: Correcciones: Made4OLT – Versión 1.3.0 [Beta] Añadidos: 1 – Se ha añadido la posibilidad de reiniciar una ONU configurada. 2 – Se ha añadido el número máximo de OLT por licencia. 3 – Se ha añadido la opción de guardado manual y guardado automático de los OLT. 4 – Se ha añadido la implementación de los comandos Telnet 5 – Se ha añadido un terminal a través de Telnet en el OLT Modificaciones: 1 – Las plantillas pueden recibir «Board», «slot» y «port» como parámetros. 2 – Perfil de DBA seleccionable del 1 al 5. 3 – Se ha corregido un error: las VLAN solo se pueden crear dentro del rango del 1 al 4094. Correcciones: 1 – Se ha corregido un error al enviar una nueva licencia.2 – Se ha corregido un error; ahora el campo «VLAN» solo admite números.
Cómo configurar FlowSpec en los routers Juniper
Visión general: El BGP FlowSpec (Border Gateway Protocol Flow Specification) es una extensión del protocolo BGP que se utiliza para definir reglas de filtrado del tráfico en los routers o, dicho de forma más sencilla, para generar reglas de cortafuegos en los routers a partir de un anuncio BGP. A diferencia del BGP convencional, que realiza el enrutamiento basándose en información de IPv4/IPv6 y prefijos, el BGP FlowSpec permite a los administradores de red especificar criterios más detallados para el enrutamiento de paquetes, incluyendo información de la capa 4 (puertos TCP/UDP) e incluso patrones de paquetes. Para obtener más información sobre BGP Flowspec, consulte nuestro artículo sobre qué es BGP Flowspec a través de este enlace. Operación: BGP FlowSpec funciona añadiendo nuevos tipos de atributos a BGP, lo que permite a los administradores de red especificar reglas de filtrado detalladas. Estas normas pueden incluir criterios como: Se pueden realizar las siguientes acciones con BGP FlowSpec: Cuando estas reglas se propagan a través de la red BGP, los routers pueden utilizar esta información para filtrar o manipular el tráfico de acuerdo con las políticas definidas. Funcionamiento – Más detalles: En el contexto de BGP FlowSpec, las acciones se especifican como parte de las reglas de filtrado. Cada regla de filtrado contiene tres partes principales: Las acciones en BGP FlowSpec se codifican utilizando comunidades BGP. Cada acción se asigna a una comunidad BGP específica: Cuando se crea una regla BGP FlowSpec, se especifican los campos coincidentes, la acción deseada y, opcionalmente, los campos de protocolo. A continuación, esta regla se codifica como una comunidad BGP y se incluye en un mensaje de actualización BGP que se envía a los routers vecinos. Los routers que reciben esta regla aplican las acciones especificadas a los paquetes que cumplen los criterios de coincidencia. Tenga en cuenta que las comunidades BGP específicas para cada acción pueden variar en función de la implementación de BGP FlowSpec en su equipo de red. Le recomiendo que consulte la documentación de su equipo para obtener información detallada sobre las comunidades BGP asociadas a cada acción en BGP FlowSpec. Casos prácticos: 1. **Mitigación de ataques DDoS: BGP FlowSpec puede utilizarse para bloquear o redirigir tráfico malicioso durante ataques de denegación de servicio distribuidos (DDoS). Se pueden aplicar reglas precisas para filtrar el tráfico no deseado y mantener los servicios en línea. 2. **Políticas de calidad de servicio (QoS): Los administradores de red pueden utilizar BGP FlowSpec para garantizar la calidad del servicio priorizando determinados tipos de tráfico en función de puertos o protocolos específicos. 3. **Aplicación de políticas de seguridad**: BGP FlowSpec puede utilizarse para aplicar políticas de seguridad granulares, bloqueando el tráfico asociado a malware o actividades sospechosas. Ejemplos de configuración: La configuración de BGP FlowSpec puede variar en función del equipo de red utilizado. Este ejemplo explora cómo diseñar una solución de mitigación DDoS en la que un proveedor de servicios permite a sus clientes anunciar rutas BGP FlowSpec para él. También analiza algunas de las mejores prácticas que deben tenerse en cuenta antes de implementar este tipo de solución y, por último, algunos de los comandos de Junos disponibles para ayudarle a comprobar que su solución Flow-spec funciona correctamente. Escenario topológico del ejemplo: Empecemos por ver cómo se configurará nuestra solución: Como podemos observar en la topología anterior, existe «BORDA», un equipo de Juniper que actúa como enrutador BGP de la red, y «Made4Flow», el software que analizará los flujos, generará reglas de BGP FlowSpec de forma dinámica y las anunciará a través de BGP al enrutador BGP denominado «BORDA». En este escenario, el ejemplo de ataque es un ataque de amplificación DNS. Esto significa que la red está recibiendo un gran volumen de paquetes UDP puerto 53 que en realidad no necesita para que el ISP funcione con normalidad. El ataque llena el circuito entre el ISP y los operadores y deja la red inoperativa. Cuando el atacante decide lanzar el ataque, el ISP puede utilizar Made4Flow para generar una ruta BGP FlowSpec exclusiva para paquetes UDP del puerto 53 y anunciarla al enrutador BGP de borde, el cual puede convertir dicha ruta en un filtro de cortafuegos en sus interfaces de comunicación con los operadores. Y entonces esto bloquea los paquetes de amplificación DNS en el borde de la red del ISP y también en el operador (si el operador soporta sesiones FlowSpec), pero permite que el tráfico legítimo siga llegando. En primer lugar, vamos a analizar la configuración de la sesión BGP FlowSpec en el router BGP BORDA con Made4Flow, suponiendo que el router ya está configurado para el enrutamiento unicast BGP normal (sesión BGP normal para anunciar rutas Blackhole o Mitigation/Scrubbing Center). Para configurar una sesión BGP FlowSpec en dispositivos Juniper, utilizamos los siguientes comandos: Buenas prácticas: Existen buenas prácticas para proteger esta solución. Tanto las rutas BGP FlowSpec como los filtros de cortafuegos resultantes que crean son recursos finitos en el router. Por lo tanto, el enrutador BGP BORDA puede filtrar las rutas entrantes para garantizar que no reciba un número excesivo de rutas ni rutas erróneas. Límite del prefijo: Así que lo primero que hay que hacer es establecer un límite de prefijos para las rutas BGP FlowSpec. Podría simplemente establecer un único límite de prefijo para las rutas inet unicast e inet flow; sin embargo, en este ejemplo se definirá un límite independiente para las rutas inet flow. Para que Made4Flow solo pueda enviar diez rutas BGP Flowspec cada vez, vamos a establecer el límite de prefijos en 10 (esta configuración debe ajustarse en función de cada caso concreto): Política de rutas : Lo siguiente que hay que hacer es aplicar una política de rutas entrantes. Esta política limitará el router a recibir prefijos que provengan del propio ISP con prefijos /24 a /32, que son los anunciados por Made4Flow. Añadamos también una Comunidad 64496:86 para que pueda identificar las rutas como rutas BGP FlowSpec. Para el resto de rutas, basta con filtrarlas en función de la asignación de rutas
¿Cómo migrar de Vmware a Proxmox?
Recientemente, el nuevo propietario de VMware hizo una declaración que resonó en toda la comunidad: ya no habrá licencias gratuitas de VMware, y el coste de las nuevas licencias ha aumentado un 40%. Este cambio drástico en las políticas de concesión de licencias ha llevado a muchos profesionales de TI y empresas a reevaluar sus estrategias de virtualización. Como resultado, están surgiendo soluciones alternativas, entre las que destaca Proxmox, el virtualizador de código abierto más utilizado en el mundo. Proxmox ofrece una gama completa de características comparables a las que ofrece VMware, incluidas funcionalidades como la agrupación en clústeres, la replicación, la alta disponibilidad (H.A.) y la garantía de alta disponibilidad, todo ello sin los elevados costes de licencia asociados a la plataforma VMware. Con la capacidad de llevar a cabo todas estas operaciones esenciales de virtualización sin comprometer la calidad ni la fiabilidad. Si ya utiliza VMware y está pensando en migrar a Proxmox, hemos elaborado un artículo detallado que muestra el proceso de migración de máquinas virtuales directamente de Vmware para Proxmox. Esta guía práctica ofrece instrucciones paso a paso para garantizar una transición fluida y eficaz, permitiéndole aprovechar al máximo las funciones y ventajas de Proxmox en su entorno de virtualización. Proceso de migración a ProxMox Exportar El primer paso es instalar ovftools usando este enlace, después de lo cual puede enviarlo vía SCP a su servidor ProxMox usando el comando: A continuación, en su servidor Proxmox, conceda permisos de ejecución al archivo enviado y, acto seguido, ejecútelo: Eso es todo, ¡OVFtools está instalado! Con este binario realizaremos dos pasos: la exportación y la conversión. OVFTOOLS se conectará de forma remota a su servidor VMware ESXi, y, a través de la línea de comandos, deberá indicar qué máquina virtual desea exportar; a continuación, OVFTOOLS descargará dicha máquina virtual y, acto seguido, la convertirá al estándar de Proxmox. Para llevar a cabo este paso en el servidor donde está instalado OVFTOOLS, ejecute el comando: Después de finalizar la Exportación, importaremos esta VM utilizando el comando: Y una vez finalizada la IMPORTACIÓN, la VM ya estará configurada en su ProxMox Con sólo unos pocos comandos, ya hemos migrado nuestra primera máquina virtual de VMware a Proxmox. Todo lo que tienes que hacer es repetir este procedimiento para las otras máquinas virtuales de tu entorno. Pero eso no es todo. ProxMox tiene otras funciones interesantes que puedes utilizar desde el principio de tu implementación, ¡así que permanece atento a futuros posts! Aprenderás a: Migrar de VMware a Proxmox puede ser una elección estratégica para optimizar sus recursos y reducir costes sin comprometer la calidad. Si busca una alternativa sólida y rentable a sus necesidades de virtualización, estamos aquí para ayudarle. Póngase en contacto con nosotros para explorar las posibilidades e iniciar el proceso de migración a Proxmox.
Cómo configurar FlowSpec en routers Huawei
Visión general: BGP FlowSpec (Border Gateway Protocol Flow Specification) es una extensión del protocolo BGP que se utiliza para definir reglas de filtrado de tráfico en los routers. A diferencia del BGP convencional, que enruta basándose en IPv4/IPv6 e información de prefijos, BGP FlowSpec permite a los administradores de red especificar criterios más granulares para el reenvío de paquetes, incluida información de capa 4 (puertos TCP/UDP) e incluso patrones de paquetes. En términos sencillos, Flowspec permite a los administradores de red crear reglas de cortafuegos de forma dinámica a través de anuncios BGP, pudiendo utilizar criterios de capa 4, como el protocolo y los puertos de aplicación, y aplicar acciones que pueden consistir en descartar el tráfico o simplemente aplicar un control de ancho de banda. Si quiere saber más sobre cómo funciona FlowSpec, consulte este artículo en el que se explica qué es FlowSpec. Operación: BGP FlowSpec funciona añadiendo nuevos tipos de atributos al BGP, lo que permite a los administradores de red especificar reglas de filtrado (o de cortafuegos dinámico) detalladas. Estas reglas pueden incluir criterios como: Se pueden realizar las siguientes acciones con BGP FlowSpec: Cuando estas reglas se propagan a través de la red BGP, los routers pueden utilizar esta información para filtrar o gestionar el tráfico de acuerdo con las políticas definidas. Funcionamiento – Más detalles: En el contexto de BGP FlowSpec, las acciones se especifican como parte de las reglas de filtrado. Cada regla de filtrado contiene tres partes principales: Las acciones en BGP FlowSpec se codifican utilizando comunidades BGP. Cada acción se asigna a una comunidad BGP específica: Cuando se crea una regla BGP FlowSpec, se especifican los campos coincidentes, la acción deseada y, opcionalmente, los campos de protocolo. A continuación, esta regla se codifica como una comunidad BGP y se incluye en un mensaje de actualización BGP que se envía a los routers vecinos. Los routers que reciben esta regla aplican las acciones especificadas a los paquetes que cumplen los criterios de coincidencia. Tenga en cuenta que las comunidades BGP específicas para cada acción pueden variar dependiendo de la implementación de BGP FlowSpec en su router. Le recomiendo que consulte la documentación de su equipo para obtener información detallada sobre las comunidades BGP asociadas a cada acción en BGP FlowSpec. Casos prácticos: BGP FlowSpec puede utilizarse para bloquear o redirigir tráfico malicioso durante ataques de denegación de servicio distribuidos (DDoS). Se pueden aplicar reglas precisas para filtrar el tráfico no deseado y mantener los servicios en línea. Los administradores de red pueden utilizar BGP FlowSpec para garantizar la calidad del servicio priorizando determinados tipos de tráfico en función de puertos o protocolos específicos. BGP FlowSpec puede utilizarse para aplicar políticas de seguridad granulares, bloqueando el tráfico asociado a malware o actividades sospechosas. Ejemplos de configuración: Ahora que ya sabes lo que es FlowSpec y lo que puede hacer, vamos a mostrarte cómo configurar FlowSpec en los routers de Huawei. Esta configuración se aplica a Huawei NE20, Huawei NE40, Huawei NE8000-M4, Huawei NE8000-M8, Huawei NE8000-M12, Huawei NE8000-F1A o cualquier Huawei que utilice el sistema operativo VRP de Huawei. Ejemplo de configuración de la especificación dinámica de flujo BGP: Si se desconocen las características del tráfico de ataques DoS o DDoS, un servidor de análisis de tráfico, como Made4Flow con Anti-DDoS, puede ayudar a implementar la especificación de flujo BGP para garantizar la seguridad de la red. #Requisitos de red: Como se muestra en la Topología de abajo, el Dispositivo A pertenece al AS 100, mientras que el Dispositivo B, el Dispositivo C y el Servidor pertenecen al AS 200. El dispositivo B es una entrada del AS 200. El AS 200 se comunica con el AS 100 a través del dispositivo B. El origen del ataque en el AS 100 puede fluir hacia el AS 200 a través del Dispositivo B, lo que supone una amenaza para el AS 200. En esta situación, configure la especificación dinámica de flujo BGP para garantizar la seguridad de la red. El proceso operativo es el siguiente: Nota: Las interfaces 1 a 3 en este ejemplo representan GE 1/0/0, GE 2/0/0 y GE 3/0/0 respectivamente. El script de configuración es el siguiente: Preparación de datos: Para completar la configuración, necesita los siguientes datos: Procedimiento: Vamos a mostrar los comandos que se utilizan; en nuestro laboratorio estamos utilizando un simulador como PNETLAB/EVE-NG. #Configurael dispositivo B: #Compruebael estado de la conexión peer de la sesión FlowSpec en el dispositivo B, si la sesión tiene el estado «Establecida» la sesión es correcta y funcional. #Compruebalas rutas recibidas vía BGP Flowspec por el dispositivo B: #Compruebe la política de tráfico (regla dinámica del cortafuegos) en cada ruta de BGP Flowspec basándose en el ReIndex que se muestra en la salida anterior: Archivos de configuración de escenarios completos: Archivo de configuración del dispositivo A: Archivo de configuración del dispositivo B: A continuación se muestra otro ejemplo básico de una regla BGP FlowSpec para bloquear el tráfico de un puerto en particular: Validar las rutas BGP Flowspec recibidas: Validar los detalles de la ruta recibida: Para comprobar que las rutas BGP Flowspec son efectivas, puede utilizar los siguientes comandos: Validar estadísticas de ruta: Más comandos para las validaciones: Ejemplo de ruta Flowspec con límite de velocidad: RFC: Para obtener información detallada sobre BGP FlowSpec, consulte las siguientes RFC: Asegúrese de consultar estas RFC para obtener información detallada sobre BGP FlowSpec y sus extensiones. ¿Sabía que ahora Made4Flow cuenta con BGP Flowspec automatizado en sus configuraciones y que puede proteger su red y a sus clientes utilizando esta tecnología? Puede automatizar los anuncios BGP FlowSpec de descarte, limitación de velocidad y con reglas flexibles.
Actualizaciones – Made4Flow, Made4Graph y Made4OLT – Enero de 2024
Made4Flow – Versión 2.6.1 Adiciones Modificaciones Correcciones Made4Graph – Versión 2.4.2 Adiciones Correcciones Made4OLT – Versión 1.2.2 [Beta] Adiciones Modificaciones Correcciones
¿Qué es FlowSpec? Cómo utilizar FlowSpec para mitigar los ataques DDoS?
Básicamente, Flowspec es una extensión del protocolo BGP que permite a los enrutadores aplicar reglas, como listas de control de acceso dinámicas o reglas de cortafuegos dinámicas, a tipos específicos de tráfico. Estas reglas pueden basarse en diversos criterios, entre los que se incluyen el origen, el destino, el protocolo, el puerto, etc.
Actualizaciones – Made4Flow, Made4Graph y Made4OLT – Enero de 2024
Made4Flow – Versión 2.6.0 Añadidos: -Se ha añadido la opción de anunciar FlowSpec manualmente. -Se ha añadido la acción de envío de anuncios BGP FlowSpec en Anti-DDoS. -Se ha añadido la ejecución reiterada o la prolongación del aviso en caso de ataques con anomalías ya existentes. -Se ha añadido la posibilidad de controlar la unidad de tiempo en las acciones del sistema Anti-DDoS. -Se ha añadido la posibilidad de visualizar el flowspec anunciado. -Se ha añadido una selección con las direcciones IP de las interfaces de la máquina virtual local. -Se ha añadido la visualización del tráfico de IPv6 en tiempo real en el panel de control principal. -Se ha añadido la posibilidad de configurar un tamaño de prefijo para las acciones de IPv6.-Se han añadido nuevas validaciones con dos colectores registrados en la herramienta.-Se ha añadido la opción de seleccionar la interfaz local para la vinculación de las direcciones IP de las sesiones BGP. Modificaciones: -Se ha modificado para que no sea posible añadir un nuevo router con los mismos datos históricos.-Se ha modificado la comprobación de la recopilación de datos Netflow del router, de modo que ahora se realiza desde el propio recopilador. Correcciones: -Se ha corregido la visualización del tráfico en tiempo real de los routers en colectores independientes de Made4Flow.-Se ha corregido el exceso de registros en los anuncios BGP en determinados casos. Made4Graph – Versión 2.4.1 Modificaciones: -Hemos introducido mejoras significativas en el rendimiento del worker encargado de las tareas del TR-069. Ahora, en caso de que se produzcan fallos en las tareas, hemos implementado un proceso optimizado para eliminarlas de la CPE correspondiente. Esta optimización tiene como objetivo evitar un aumento sustancial en la carga del servidor, lo que anteriormente podía provocar una ralentización del sistema. Correcciones: -Hemos identificado y corregido un problema que podía provocar un aumento del consumo de recursos del servidor, debido a las consultas realizadas en el TR-069. Esta corrección tiene como objetivo optimizar el rendimiento del servidor, garantizando un funcionamiento más estable y eficiente durante las consultas al TR-069. Made4OLT – Versión 1.1.4 [Beta] Añadidos: 1 – Homologado el ZTE-C600 (firmware 1.2.2) para visualización y aprovisionamiento.2 – Implementada la eliminación temporal en el ONU TYPE.3 – Se han implementado comandos SNMP para recopilar datos de las ONU.4 – Se han añadido colas separadas en Bull para capturar diferentes tipos de datos, respetando el tiempo de las solicitudes de cada OLT.5 – Se ha añadido una imagen en las ONU Modificaciones: 1 – Se ha modificado la pantalla de detalles de las ONUs 2 – Optimización de la base de datos mediante la creación de índices para las tablas.3 – Se ha modificado la regla de negocio de ONUS en caso de no recibir señal de la misma, igualándola a la de smartOLT4 – Posibilidad de cargar ranuras/pontes/puertos de forma individual a través de SNMP Correcciones: 1 – El objetivo de este sprint fue corregir los valores y el estado de las ONU en producción
Cómo configurar Netflow en los routers Nokia
Hola Hoy le mostraremos cómo configurar su router Nokia SR OS para exportar Netflow (IP Netstream). Esta es la topología de la red y la información del servidor Netflow Estos son los pasos necesarios para configurar el router Nokia SR OS con el fin de exportar Netflow v9/v10 a través de IP Netstream 1 – Configurar el servidor NTP2 – Configurar los parámetros de cflowd con el servidor NetFlow3 – Configurar la interfaz para habilitar NetFlow Pasemos a la configuración paso a paso: 1.Configuración del servidor NTP Es importante configurar un servidor NTP, ya que los datos de flujos utilizan marcas de tiempo basadas en la hora del router; si la hora del router difiere de la del servidor, los datos no se ajustarán a la hora correcta, lo que provocará una discrepancia en la información. Es importante que configures al menos 2 servidores NTP y también la zona horaria de tu router. 2 – Configurar los parámetros de cflowd con el servidor NetFlow 3- Configurar la interfaz para habilitar Netflow Por último, debemos activar las interfaces que van a exportar Netflow; para ello, en cada interfaz, utilice los siguientes comandos: A continuación se muestra la configuración completa del router: Y en todas las interfaces, active lo siguiente: Descripción detallada Algunos comandos adicionales para el análisis del flujo:
