Evolucionando nuestro VPMS II

Hace algo más de dos años que vimos como evolucionar nuestro VPMS inicial para el control de acceso a red, a un sistema basado en una asignación dinámica de VLANs en función del usuario. No obstante, no siempre es posible este tipo de autenticación ya que, por ejemplo, podemos encontrar dispositivos conectados a nuestra red como controles de acceso, teléfonos o impresoras que no dispongan de funcionalidad para su autenticación mediante 802.1x y, por lo tanto, debemos garantizar otro tipo de autenticación, siendo lo más habitual usar la autenticación MAB (MAC Authentication Bypass).

Al igual que vimos en la configuración inicial de nuestro VPMS, mediante la autenticación MAB nos volvemos a basar en la dirección MAC del cliente para proporcionar el acceso a la red (no en el usuario final) aunque, al estar integrado en un servidor Radius, nos da más potencia que la versión inicial de VPMS. No obstante, como todo, tiene sus ventajas e inconvenientes. [Read more…]

Defensas frente a ataques STP

Continuando con las medidas de seguridad en capa 2 que hemos visto en entradas anteriores, en este post nos centraremos en STP (Spanning Tree Protocol), protocolo usado en la red para evitar bucles a nivel 2 en nuestra topología.

Es habitual ver tráfico similar a este cuando capturas tu propia interfaz (no entro a valorar si dispones de permisos de administrador o si el equipo es un servidor o un equipo de usuario):

13:44:16.651348 STP 802.1d, Config, Flags [none], bridge-id 8001.00:24:f7:31:65:00.8016, length 43
	message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s
	root-id 8001.00:24:f7:31:65:00, root-pathcost 0
13:44:18.660589 STP 802.1d, Config, Flags [none], bridge-id 8001.00:24:f7:31:65:00.8016, length 43
	message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s
	root-id 8001.00:24:f7:31:65:00, root-pathcost 0
13:44:20.661034 STP 802.1d, Config, Flags [none], bridge-id 8001.00:24:f7:31:65:00.8016, length 43
	message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s
	root-id 8001.00:24:f7:31:65:00, root-pathcost 0
13:44:22.666010 STP 802.1d, Config, Flags [none], bridge-id 8001.00:24:f7:31:65:00.8016, length 43
	message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s
	root-id 8001.00:24:f7:31:65:00, root-pathcost 0
13:44:24.670848 STP 802.1d, Config, Flags [none], bridge-id 8001.00:24:f7:31:65:00.8016, length 43
	message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s
	root-id 8001.00:24:f7:31:65:00, root-pathcost 0

[Read more…]

Defensas frente a ataques ARP

Recientemente he estado revisando documentación de controles de red a nivel 2 y justo vino a mi memoria el post de Borja Merino de hace algún tiempo.... Leer Más

Evolucionando nuestro VPMS

En este mismo blog, hace ya casi dos años, vimos el uso de un servidor VPMS (VLAN Management Policy Server) como punto de partida para poder asignar de forma dinámica los equipos de nuestra red a las distintas vLANs corporativas. Esta asignación estaba basada en la dirección MAC de los clientes, algo que habitualmente es complicado de mantener.... Leer Más

Tipos de ACLs en dispositivos Cisco

Como ya hemos comentado en alguna ocasión en este blog, las listas de control acceso en dispositivos Cisco, en adelante ACLs, nos ayudan a identificar tráfico ‘interesante’ para que posteriormente sea procesado por el sistema. Las ACLs pueden usarse por varios motivos, siendo el más habitual la identificación de tráfico para su filtrado posterior sobre una de las interfaces del dispositivo (access-group). Otro uso habitual es la indentificación de tráfico interesante dentro de un cryptomap de una conexión VPN o cuando usamos NAT.... Leer Más

Evolucionando la red

Algo habitual a la hora de configurar una red donde podemos encontrar dispositivos de distintos fabricantes como switches o routers, es configurar los equipos de forma manual y por separado, lo cual, dependiendo de la complejidad de la red, puede llegar a hacer prácticamente imposible disponer de mejoras de forma rápida. Por ejemplo, para cubrir por ejemplo las necesidades de ancho de banda o conectividad de nuestros clientes.... Leer Más

Zero-trust security model

Habitualmente, cuando se planifica el diseño de una red y su segmentación posterior mediante por ejemplo, un firewall, es frecuente partir del concepto histórico donde las redes internas son confiables y las externas no. Esto era lo normal hace algunos años donde la mayor parte de los ataques podían iniciarse fuera de la organización. Con este modelo de funcionamiento, es normal que se dé el caso de que un usuario, solamente por estar conectado a una interfaz de red concreta (por ejemplo inside) tenga heredados unos privilegios de acceso. Un claro ejemplo de esto podría ser la definición de security-level de los firewalls Cisco.... Leer Más

Jugando con Cisco EEM (II)

Siguiendo con la entrada del otro día Jugando con Cisco EEM (I) otra opción que tenemos en EEM es generar acciones mediante scripts escritos en el lenguaje interpretado TCL (Tool Command Language 8.3.4) ), ya sea por que estén almacenados de forma local o en un servidor remoto. ... Leer Más

Jugando con Cisco EEM (I)

Habitualmente, solemos monitorizar sucesos en routers (en este caso C1800) mediante traps snmp o agentes que procesan el log y tras evaluarlo, generan acciones. Cisco IOS Embedded Event Manager (EEM) nos da la posibilidad de definir acciones a eventos concretos generados en el sistema. ... Leer Más

Firewalls transparentes

Como hemos visto infinidad de veces en libros o presentaciones de fabricantes, el firewall esta considerado como el elemento principal a la hora de llevar a cabo una correcta segmentación de redes y por lo tanto, habitualmente trabaja a nivel 3 proporcionando filtrado y enrutando entre ellas. Esta sería una arquitectura básica de red: el firewall segmentando una red corporativa en segmentos de DMZ, usuarios, servidores internos y WAN.

No obstante, y aunque nunca he tenido la necesidad de realizar una configuración así, muchos sistemas permiter trabajar a nivel 2 en modo transparente, manteniendo el direccionamiento de red dentro del segmento y siendo una configuración posible cuando se requiere un análisis o filtrado con el menor número de cambios posibles, por ejemplo, para no afectar a la red de servidores de producción. La arquitectura quedaría así:

[Read more…]