Mostrando las entradas con la etiqueta Configuraciones. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Configuraciones. Mostrar todas las entradas

5 de enero de 2024

Configuración de Syslog en FMC (video)

Esta es una demostración realizada sobre una maqueta que implementa Cisco Secure Firewall versión 7.2.0, que implementa FMC y FTD.

Durante la demo revisaremos como asociar un servidor Splunk utilizando protocolo Syslog al FMC y a continuación al FTD. 

Este Laboratorio no es parte de ningún curso, pero supone conocimientos que podés obtener en el curso "Cisco Secure Firewall versión 7.2" de Educática.

Como siempre, cualquier sugerencia que puedas hacer, será muy bien venida.



Los manuales que publico los podés adquirir en el sitio web de EduBookshttps://www.edubooks.com.ar/

Los cursos on line que desarrollo se pueden adquirir a través del sitio web de Educáticahttps://www.educatica.com.ar/

Estás invitado a seguirme en Instagram:
https://www.instagram.com/libros.networking/

También podés participar de nuestro grupo en Facebook
https://www.facebook.com/groups/librosnetworking/

O si preferís redes sociales con mayor respeto de tu privacidad,
podés participar de nuestro grupo en VKontakte
https://vk.com/libros.networking

O también puedes seguir las principales novedades en el grupo de Telegram:
https://t.me/LibrosNetworking



Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


18 de septiembre de 2023

Pasos para la configuración inicial de un switch


La configuración de un switch corporativo supone un nivel de conocimientos y habilidades superior al que se requiere para poner en funcionamiento una red hogareña o un switch diseñado para soluciones pequeñas o medianas.
Sin embargo, con los conocimientos adecuados un profesional de redes nivel junior puede encarar una configuración inicial. Esta tarea se puede organizar en una serie de pasos:

1. Verifique el hardware sobre el que va a trabajar
Es sumamente importante conocer el hardware y software con los que hemos de operar, antes de comenzar cualquier configuración.
Comience por asegurarse la disposición física del dispositivo y el cableado que va a utilizarse. Verifique 
  • La instalación del dispositivo en el rack correspondiente
  • El cableado de alimentación eléctrica y de la fuente de alimentación ininterrumpida (UPS)
  • El cableado de datos que ha de utilizarse (hoy debiéramos procurar que al menos sea cableado categoría 6a, certificado)
Conecte en primer lugar el cableado de datos (Ethernet), y luego la alimentación eléctrica para encender el dispositivo.
Verifique atentamente la secuencia de encendido y el color de los LEDs indicadores del panel frontal del switch.
Si todo muestra funcionar correctamente, conecte un cable consola al puerto consola del switch. Para acceder por consola deberá utilizar alguna aplicación de acceso por línea de comando (CLI) al dispositivo como puede ser Putty, TeraTerm o Cisco CLI Analyzer.
Una vez en el prompt del sistema operativo del switch puede utilizar los siguientes comandos para verificar el hardware y software del switch:

Switch> enable
Switch#show running-config

De esta forma podrá verificar el hardware y software del dispositivo (memoria, puertos, versión de SO, etc.).
También podrá verificar si el dispositivo cuenta con alguna configuración previa o mantiene la configuración de fábrica.

Antes de continuar asegure algunos elementos mínimos del acceso a la gestión por consola del dispositivo:
Switch#configure terminal
Switch(config)#username xxxxxx password xxxxxxxxxx
Switch(config)#service password-encryption
Switch(config)#line console 0
Switch(config-line)#logging synchronous
Switch(config-line)# login local

Una mejor opción para segurar las claves de usuario con un algoritmo más robusto, en lugar de utilizar el servicio de cifrado de claves, es el siguiente:
Switch#configure terminal
Switch(config)#username xxxxxx secret xxxxxxxxxx

2. Configure el acceso a la gestión del dispositivo
Un elemento fundamental es configurar los elementos necesarios para luego poder acceder remotamente a la gestión del dispositivo (la conexión por consola requiere presencia local junto al dispositivo).
Para esto, suponiendo que intentaremos acceder utilizando alguna aplicación que implemente SSH para el acceso remoto a la CLI del switch, es necesario completar varios pasos.
En primer lugar configurar una dirección IP de gestión o management:

Switch#configure terminal
Switch(config)#interfaz vlan 1
Switch(config-inf)#description Gestion del Switch
Switch(config-int)#ip address xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy

A continuación, hay que generar las llaves de cifrado que utilizará SSH. Para esto es requisito definir un hostname, un nombre de dominio y un par usuario/clave. El usuario y su clave los hemos definido en el paso anterior por lo que resta asignar un nombre y dominio:

Switch(config)#hostname XXXXXXXXX
Switch(config)#ip domain-name XXXXXXXX.XXX

Para crear el par de llaves de cifrado:

Switch(config)#crypto key generate rsa
The name for the keys will be:  XXXXXXXX.XXXXXXXX.XXX
How many bits in the modulus [512]: 1024
 % Generating 1024 bit RSA keys, keys will be non-exportable...[OK]

Finalmente, es necesario implementar SSH para el acceso virtual a través de las terminales virtuales, utilizando las credenciales de usuario que generamos antes:

Switch(config)#line vty 0 15
Switch(config-line)#transport input ssh
Switch(config-line)#login local

3. Configure los puertos de acceso
En una definición inicial de puerto de acceso, no compleja, podríamos decir que se trata de los puertos a los que conectamos dispositivos terminales.
Esto significa asignarlos a una VLAN como puertos de acceso.
Todos los puertos de los switches Catalyst están asignados como puertos de acceso de la VLAN 1. Pero ya estamos utilizando la VLAN 1 como VLAN de gestión del dispositivo. Es por esto que se sugiere que, como buena práctica, se coloquen los puertos del switch como puertos de acceso en otra VLAN diferente.
Para esto debemos crear una nueva VLAN y asignar los puerto a esa VLAN como puertos de acceso.

Switch(config)#vlan X
Switch(config-vlan)#description XXXXXXXXXXX
Switch(config-vlan)#exit
Switch(config)#interface GigabitEthernet1/0/1
Switch(config-if)#description XXXXXXXXXXX
Switch(config-if)#switchport mode access
Switch(config-if)#switchport access vlan X
Swtich(config-if)#spanning-tree portfast
Swtich(config-if)#spanning-tree bpduguard enable

4. Configure los puertos troncales
Si a través del switch se ha de acceder a otros switches , firewall o router se suele utilizar para esto un puerto troncal que es el que permite llegar con varias VLANs simultáneamente a ese otro dispositivo.
La configuración básica de un puerto troncal es relativamente sencilla, y comunica con otro puerto troncal configurado en el otro dispositivo:

Switch(config)#interface GigabitEthernet1/0/20
Switch(config-if)#description XXXXXXXXXXX
Switch(config-if)#switchport trunk encapsulation dot1q
Switch(config-if)#switchport mode trunk

Hasta aquí he descripto un proceso de configuración básica. No exime de mínimas definiciones de diseño previas para acordar métodos de acceso a la configuración, VLANs a utilizar, segmentos IP a tener disponibles, puertos a definir como troncales, etc.
Y por supuesto, esto es solo el comienzo.
La configuración del switch puede tener muchos elementos más que nos permitan acceder a diferentes prestaciones en muchas modalidades diferentes. 
Pero eso, ya es otro tema.


Este post está lejos de desarrollar el tema en profundidad y pretender agotar las posibilidades de configuración y monitoreo de los switches.
Como dice en la introducción, es solamente una referencia para quienes tienen conocimientos iniciales en el área.
Si lo que buscás es profundizar cualquiera de estos aspectos, sugiero buscar el desarrollo del tema en el blog o recurrir a cualquier manual de preparación para la certificación CCNA.

Referencias:


Los manuales que publico los podés adquirir en el sitio web de EduBookshttps://www.edubooks.com.ar/

Los cursos on line que desarrollo se pueden adquirir a través del sitio web de Educáticahttps://www.educatica.com.ar/

Estás invitado a seguirme en Instagram:
https://www.instagram.com/libros.networking/

También podés participar de nuestro grupo en Facebook
https://www.facebook.com/groups/librosnetworking/

O si preferís redes sociales con mayor respeto de tu privacidad,
podés participar de nuestro grupo en VKontakte
https://vk.com/libros.networking

O también puedes seguir las principales novedades en el grupo de Telegram:
https://t.me/LibrosNetworking



Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.




12 de noviembre de 2020

Puertos e interfaces en un switch multilayer

Cuando abordamos el estudio de los switches, y particularmente los llamados switches multilayer, es conveniente organizar claramente los conceptos para tener una comprensión adecuada de las diferentes operaciones que se realizan en el dispositivo.
Es por esto que consideré conveniente dedicar atención a las diferentes interfaces y puertos que presentan estos dispositivos.

En primer lugar debemos tener presente que cada puerto tiene su correspondiente interfaz. Estas interfaces pueden ser interfaces capa 2 o interfaces capa 3 según participen de procesos de reenvíos de tramas (capa 2) o de paquetes (capa 3).

Interfaces capa 2
Se trata de interfaces que participan del reenvío de tramas a partir de la dirección MAC de destino de cada trama y tomando en consideración la tabla de direcciones MAC del switch.
Estas interfaces, por ser capa 2, no admiten la configuración de direccionamiento capa 3.
Hay diferentes interfaces capa 2:
  • Puertos de acceso.
    Se trata de puertos asociados a una VLAN que está definida como VLAN del puerto.
    Los puertos de acceso pueden participar de una única VLAN y ocasionalmente (cuando el diseño lo requiere) de una VLAN auxiliar o VLAN de voz.
    Su encapsulación es Ethernet.
    Un ejemplo de configuración:

    Switch(config)#interface GigabitEthernet 1/0/1
    Switch(config-if)#switchport mode access
    Switch(config-if)#switchport nonegotiate
    Switch(config-if)#swtichport access vlan 10

  • Puertos troncales.
    Son puertos en capacidad de transportar tráfico de múltiples VLANs manteniendo su pertenencia a cada VLAN.
    Para mantener identificada esa pertenencia a cada VLAN de cada trama se utiliza un protocolo de etiquetado de tramas: IEEE 802.1Q.
    Todo puerto troncal que implementa 802.1Q incluye una VLAN que no es etiquetada y que recibe el nombre de VLAN nativa. En el caso de los switches Catalyst la VLAN nativa por defecto es la VLAN 1; esto puede cambiarse por configuración.

    Estos puertos, por defecto, transportan todas las VLANs definidas en el switch y es posible por configuración limitar cuáles son las VLANs transportadas.
    Un ejemplo de configuración:

    Switch(config)#interface GigabitEthernet 1/0/10
    Switch(config-if)#switchport mode trunk
    Switch(config-if)#switchport trunk encapsulation dot.1q
    Switch(config-if)#switchport trunk allowed vlan 10, 20
    Switch(config-if)#swtichport trunk native vlan 999
Una VLAN no es una interfaz.
Una VLAN es una red lógica o virtual cuyo tráfico circula de modo independiente (a nivel de capa 2) del de otras VLANs que operan sobre la misma red física.
Las VLANs no tienen necesariamente asociada una interfaz VLAN.

Interfaces capa 3
Son interfaces que participan del reenvío de paquetes IP a partir de la dirección IP de destino de cada paquete y tomando en cuenta las rutas que se encuentran definidas en la tabla de enrutamiento IP.
Estas interfaces por ser capa 3 requieren la configuración de direccionamiento IP, sea IPv4 y/o IPv6.
No admiten la configuración de VLANs de acceso o troncales ya que se trata de interfaces de capa 3, y estos features son features de capa 2.
En los switches multilayer a 2 tipos de interfaces capa 3:
  • Interfaces VLAN.
    Se trata de interfaces lógicas que operan como gateway del segmento IP que se identifica que con una VLAN determinada.
    El ID de la interfaz VLAN corresponde al mismo ID de la VLAN.
    Requieren la configuración de una dirección IP que operará como default gateway de las terminales conectadas a los puertos de la misma VLAN.
    Estas interfaces, por ser interfaces lógicas, no requieren que se las habilite administrativamente ya que se encuentran habilitadas por defecto.
    Un ejemplo de configuración:

    Switch(config)#ip routing
    Switch(config)#interface vlan 10
    Switch(config-if)#ip address 10.10.10.1 255.255.255.0


  • Interfaces o puertos ruteados.
    Se trata de puertos cuya interfaz se habilita para operar como interfaz de capa 3. Los puertos de los switches Catalyst (independientemente de que sean switches multilayer) tienen asociadas interfaces de capa 2 por defecto, por est
    Estos puertos no pueden ser parte de troncales, participar de VLANs o integrar un link aggregation de capa 2.
    No admiten la configuración de subinterfaces.
    Un ejemplo de configuración:

    Switch(config)#ip routing
    Switch(config)#interface GigabitEthernet 1/0/20
    Switch(config-if)#no switchport
    Switch(config-if)#ip address 10.10.10.1 255.255.255.0


Estás invitado a participar de nuestro grupo en Facebook:

https://www.facebook.com/groups/librosnetworking/

O si preferís redes sociales con mayor control de tu privacidad,
podés participar de nuestro grupo en VKontakte
https://vk.com/libros.networking

o seguir las principales novedades en el grupo de Telegram:
https://t.me/LibrosNetworking


Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.

 

 

 

3 de noviembre de 2020

Gestión de la configuración

Contenido incluido
en el temario de
CCNA 200-301

Se da esta denominación a la práctica de definir el rendimiento, los atributos funcionales y físicos de un producto y luego garantizar la coherencia de la "configuración" del sistema a lo largo de su trayectoria. 
Con este propósito se pueden implementar herramientas de gestión de la configuración (CMT). Estas herramientas se han utilizado tradicionalmente en el ámbito de los sistemas para la implementación de servidores y aplicaciones; ahora se utilizan también como herramientas de automatización de la gestión de la configuración de los dispositivos para mejorar las operaciones de red. Estas herramientas no son nuevas. Lo novedoso es cómo su uso en redes está cambiando la forma en que se gestionan las infraestructuras.
Las herramientas de gestión de la configuración ofrecen algunos beneficios:
  • Se automatiza el aprovisionamiento y la implementación de aplicaciones e infraestructura.
  • No requieren conocimientos de programación: hay herramientas que implementan un modelo declarativo (intención). No requieren conocimientos de scripting.
  • Aprovechan las prácticas comunes en el desarrollo de software para realizar implementaciones, incluyendo las prácticas de control y las pruebas de versiones
  • Las herramientas más comunes son: Puppet, Ansible y Chef.
Desde la perspectiva de la gestión de la red es habitual implementar cambios manualmente. Estos cambios tienen diferente gravedad e impacto, puede ser tanto la creación de una nueva VLAN en un centro de datos o campus, como la implementación de cambios diarios en las políticas de firewall para cada una de las nuevas aplicaciones que se implementan. Cuando en la organización se ha definido un flujo de trabajo manual para realizar un conjunto de tareas, se deben usar las herramientas adecuadas para automatizar ese flujo de tareas. No tiene sentido pasar una hora realizando un cambio que puede ejecutarse en solo unos minutos y con menor probabilidad de errores si se utiliza una herramienta diseñada correctamente. Este proceso o flujo de tareas es donde las herramientas de código abierto como Puppet, Chef y Ansible pueden reducir drásticamente la cantidad de interacciones manuales con la red.
  • Puppet: https://puppet.com/
  • Chef: https://www.chef.io/products/chef-infra
  • Ansible: https://www.ansible.com/

Con herramientas para la gestión de la configuración se pueden definir y aplicar configuraciones relacionadas con operaciones a nivel del sistema (por ejemplo, autenticación, registro, imagen), configuración a nivel de interfaz (por ejemplo, VLANs, QoS, seguridad), configuraciones de enrutamiento (por ejemplo, especificaciones OSPF o BGP) y más.
Estas herramientas a menudo se denominan herramientas DevOps. Son más específicamente herramientas de automatización y administración de la configuración y son utilizadas por aquellas organizaciones que han implementado alguna forma de prácticas de DevOps como el control y las pruebas de versiones. Permiten automatizar aplicaciones, infraestructura y redes en alto grado sin la necesidad de realizar programación manual utilizando un lenguaje de programación como Python. No solo reducen el tiempo necesario para realizar determinadas tareas, también ofrecen una mayor previsibilidad.
Una arquitectura habitual de los sistemas CMT consiste en un servidor central, donde se define un estado requerido o previsto del sistema, al que se asocia  una serie de dispositivos de red sobre los que se aplica ese estado y debe hacerse cumplir.

Implementaciones con o sin agente
Para la gestión automatizada de la configuración de los dispositivos hay dos modelos posibles.

1- Modelo basado en la intención

En un servidor central se define el estado requerido o deseado de los sistemas y los agentes implementados en cada sistema o dispositivo se ocupan de plasmar ese estado deseado.
Su despliegue requiere la implementación de un agente en cada dispositivo de la red.
Es el modelo implementado por Puppet y Chef.
La arquitectura es uniforme para todos los dispositivos de destino que admitan el agente:
  • Un software de control (Puppet Master o Chef Server) define el objetivo a conseguir en los dispositivos destino.
  • En cada dispositivo un agente de software monitorea el estado de la configuración real del dispositivo.
    El agente interactúa con el servidor para informar el estado real y recibir el estado deseado. Si hay diferencia entre ambos estados el agente ejecuta lo necesario para hacer cumplir el objetivo.

2-
Modelo basado en CLI y SSH.

Se basa en las técnicas tradicionales a partir de plantillas y grupos de comandos reutilizables para lograr escalabilidad.
No requiere de la instalación de ningún agente o cliente en cada dispositivo de la red.
La operación se realiza a través de un shell remoto al que accede un servidor de gestión o máster que utiliza un modelo push para entregar a través de la red la información a implementar en forma de script.
Es el modelo implementado por Ansible.
En este caso el estado de configuración objetivo se define en los playbooks de Ansible.
Los playbooks son archivos de configuración basados en texto que definen cómo se deben usar los módulos de Ansible. Ansible interpreta el contenido de los playbooks y utiliza los módulos para aprovisionar los dispositivos de destino. Para los dispositivos de Cisco estos comandos se ejecutan a través de CLI.
Su ventaja principal es que no requiere la instalación de un agente; pero es crítica la configuración de seguridad del dispositivo ya que puede limitar la posibilidad de acceder al mismo.

Ambas implementaciones coinciden en la capacidad de utilizar un único conjunto de herramientas para configurar todos los dispositivos de la infraestructura. Esto implica que todo el ciclo de vida de la implementación de una aplicación se puede definir y gestionar desde un solo punto, con una misma herramienta.
Unificar la configuración de todos los elementos de la infraestructura en un único conjunto de herramientas aumenta la eficiencia y la agilidad, al tiempo que reduce los costos.



Estás invitado a participar de nuestro grupo en Facebook:
https://www.facebook.com/groups/librosnetworking/

O si preferís redes sociales con mayor control de tu privacidad,
podés participar de nuestro grupo en VKontakte
https://vk.com/libros.networking

o seguir las principales novedades en el grupo de Telegram:
https://t.me/LibrosNetworking


Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.

3 de octubre de 2020

Los estratos en NTP

Network Time Protocol es un protocolo creado para sincronizar el reloj de los diferentes sistemas que se integran en una redes de datos de latencia variable. Desarrollado inicialmente antes de 1985 es uno de los protocolos de Internet más antiguos que se utilizan actualmente. Fue diseñado por David L. Mills de la Universidad de Delaware .

Está diseñado para sincronizar todos los sistemas dentro de unos pocos milisegundos con la hora universal coordinada (UTC -  Coordinated Universal Time). 

Utiliza una versión modificada del algoritmo de Marzullo  para seleccionar servidores de tiempo precisos y está diseñado para mitigar los efectos de la latencia de red variable . Generalmente puede mantener el tiempo dentro de decenas de milisegundos en Internet y puede lograr una precisión superior a un milisegundo en redes LAN en condiciones ideales. La presencia de rutas asimétricas y la posible congestión de la red pueden provocar errores del orden de los 100 ms o más.

El protocolo se describe en términos del modelo cliente-servidor pero puede usarse fácilmente implementando relaciones entre pares donde ambos miembros del par consideran al otro como una fuente de tiempo potencial. Utiliza UDP como protocolo de transporte en el puerto número 123. 

No incluye en su contenido información sobre las zonas horarias locales o el horario de verano . 

El protocolo actualmente en uso es la versión 4 (NTPv4) propuesto en el RFC  5905  y es compatible con la versión 3, especificada en el RFC 1305.

El sistema de estratos

NTP utiliza un sistema jerárquico de fuentes de tiempo semi-estratificado. Cada nivel de esta jerarquía recibe la denominación de estrato y se le asigna un identificador de nivel que utiliza el cero para identificar el reloj de referencia que da la información de hora de referencia. 

El concepto de estrato describe a cuántos saltos se encuentra un sistema de un fuente autoritativa de registro de tiempo o dispositivo de estato 0. El nivel del estrato define la distancia, en saltos, que hay entre un sistema y el reloj de referencia o estrato 0.

Un servidor sincronizado con un servidor de estrato n pertenece al estrato n + 1. Por ejemplo, un servidor sincronizado con un servidor de estrato 2 (n) pertenece al estrato 3 (n + 1).

El número representa la distancia con el reloj de referencia (estrato 0) y se utiliza para evitar dependencias cíclicas en la jerarquía. El estrato no es una indicación de calidad o confiabilidad; es común encontrar servidores del estrato 3 que son de mayor calidad que otros servidores del estrato 2.

  • Estrato 0
    Se trata de dispositivos de cronometraje de alta precisión como pueden ser relojes atómicos , clientes GPS u otros relojes de precisión y que por lo tanto se asume que pueden proporcionar una hora precisa. Generan una señal de pulso muy precisa por segundo que activa una interrupción y marca de tiempo en una computadora conectada.
    Los dispositivos de estrato 0 también se conocen como relojes de referencia. Un dispositivo de estrato 0 no puede ser utilizado directamente en la red sino que debe conectarse directamente a un dispositivo que se asume como un servidor de estrato 1.
    Los servidores NTP no pueden anunciarse a sí mismos como estrato 0.
    Un campo de estrato establecido en 0 en el paquete NTP indica un estrato no especificado.

  • Estrato 1
    Sistemas cuyo reloj se encuentra sincronizado a unos pocos microsegundos de un dispositivo de estrato 0 al que se encuentra directamente conectado.
    Los servidores de un estrato puede también intercambiar información NTP con otros servidores del mismo estrato o nivel que reciben entonces la denominación de “peer”. Esto permite lograr una referencia de tiempo más estable y robusta para los sistemas de ese mismo nivel.
    Los servidores de estrato 1 pueden emparejarse con otros servidores de estrato 1 (peers) para comprobar el estado.
    También se les conoce como servidores de tiempo primarios.

  • Estrato 2
     sincronizados a través de una red de datos con servidores de estrato 1 utilizando paquetes NTP.
    A menudo, un sistema de estrato 2 consulta varios servidores del estrato 1. Los sistemas de estrato 2 también pueden emparejarse con otros sistemas del mismo estrato 2 (peers) para proporcionar un tiempo más estable y robusto para todo el sistema.

  • Estrato 3
    Son sistemas que están sincronizados con servidores de estrato 2. Emplean los mismos algoritmos para el emparejamiento y el muestreo de datos que los sistemas de estrato 2 y pueden actuar ellos mismos como servidores para los sistemas de estrato 4, y así sucesivamente.

El protocolo prevé un límite de 15 estratos; el estrato 16 se utiliza para indicar que un dispositivo no está sincronizado.



Estás invitado a participar de nuestro grupo en Facebook:
https://www.facebook.com/groups/librosnetworking/

O si preferís redes sociales con mayor control de tu privacidad,
podés participar de nuestro grupo en VKontakte
https://vk.com/libros.networking

o seguir las principales novedades en el grupo de Telegram:
https://t.me/LibrosNetworking


Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.

 

26 de septiembre de 2020

Proceso de selección de herramientas en Firepower

Los procesos de actualización tecnológica hacen que en nuestro medio progresivamente se realicen cada vez más implementaciones de firewalls de última generación (NGFW).

Muchas de estas implementaciones son sencillamente el reemplazo de los firewalls statefull ya presentes, que al momento de ser actualizados se reemplazan por NGFW. Esta actualización genera un punto que requiere una consideración especial.
Los NGFW son herramientas mucho más potentes que sus predecesores. No solo hablamos de potencia de hardware sino de capacidades y granularidad. Ahora podemos inspeccionar aplicaciones, inspeccionar tráfico, incorporar información de security intelligence, etc. Todas capacidades que no estaban presentes en los firewalls statefull y que por lo tanto no podían ser consideradas al momento de implementar aquellos dispositivos.

Esto hace que una simple migración de configuraciones sea una estrategia pobre.
Ahora contamos con nuevas herramientas, podemos hacer evaluaciones que antes no eran posibles, y por lo tanto tenemos que evaluar cuál es la mejor forma de lograr los objetivos que se plantean con las nuevas herramientas con que contamos.

Pero también es cierto que estos NGFW son herramientas complejas, con múltiples opciones diferentes para lograr un mismo objetivo y una gran granularidad.
Esto ha hecho que muchas veces me encuentre con el requerimiento de un procedimiento de toma de decisiones que nos pemita seleccionar la mejor herramienta para cada objetivo propuesto.
A este requerimiento pretendo dar respuesta en este post, tomando como base las herramientas y características de los sistemas Firepower de Cisco System.

Al momento de seleccionar la mejor manera de responder a un requerimiento de seguridad específico con las herramientas que nos proporcionan los sistemas Firepower, el proceso de toma de decisiones a considerar puede ser el siguiente:
  1. Si el requerimiento es el filtrado de tráfico tomando como base direccionamiento IP de origen y/o destino, y/o puertos de capa de transporte de origen y/o destino la herramienta a considerar es la implementación de una regla de prefiltrado en una política de prefiltrado.
    Esta herramienta nos permite implementar acciones de alguna forma semejantes a las de las ACLs tradicionales pero con ventajas significativas: se ejecutan en la interfaz de ingreso del tráfico antes de que los paquetes accedan al motor de inspección Snort y por lo tanto con menor requerimiento de recursos de procesamiento con la consecuente reducción del delay.
  2. Si en cambio el requerimiento es más específico y requiere del filtrado de tráfico en función de protocolos de capa  de aplicación, y/o de aplicaciones y/o de usuarios, entonces la herramienta a considerar es la implementación de una regla de control de acceso en una política de control de acceso.
    Esta herramienta requiere más procesamiento que la anterior pero a la vez permite un control más granular del tráfico que atraviesa el firewall en función de la potencia del motor de inspección Snort.

  3. Si el requerimiento especifica la necesidad de realizar filtrado de archivos transportados por diferentes protocolos de aplicación según el tipo de archivo (documentos Word, archivos pdf o ejecutables, etc.) o la presencia de malware o código malicioso, en este caso la herramienta a implementar es una política de filtrado de archivos y malware asociada a una regla de control de acceso que especifique el tráfico que debe ser sometido a esta inspección.
  4. Finalmente, si se requiere de la implementación de inspección avanzada de tráfico para controlar los posibles intentos de explotar vulnerabilidades de alguno de los sistemas alojados en la red corporativa, la herramienta a aplicar es una política de prevención de intrusiones (IPS) ajustada a los requerimientos de seguridad y asociada a una regla de control de acceso que especifique el tráfico que se espera sea inspeccionado por esta política.
    Para que la política se pueda adaptar a los sistemas alojados en la red corporativa es necesario verificar además que la política de descubrimiento de la red aplicada al FTD incluya a aquellos dispositivos que se desea proteger con esta política de prevención de intrusiones.

Un NGFW es una herramienta aún más variada y con muchas otras opciones disponibles. En este proceso he intentado incluir solamente las principales consideraciones y posibilidades a implementar.

Espero que resulte de utilidad.



Estás invitado a participar de nuestro grupo en Facebook:
https://www.facebook.com/groups/librosnetworking/

O si preferís redes sociales con mayor control de tu privacidad,
podés participar de nuestro grupo en VKontakte
https://vk.com/libros.networking

o seguir las principales novedades en el grupo de Telegram:
https://t.me/LibrosNetworking


Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.

 

28 de mayo de 2020

Implementación y diagnóstico de sistemas Cisco Firepower v1.1


Las primeras décadas de este siglo han estado marcadas por una creciente evolución y desarrollo de diferentes amenazas y ataques que acechan las redes de datos y los activos corporativos.
Esta evolución ha requerido una evolución semejante en las herramientas que desplegamos para proteger esos activos, particularmente los tradicionales firewalls e IPs. Esto ha dado lugar a nuevos dispositivos, mucho más potentes con capacidades de inspección más allá de la capa de aplicación del modelo OSI (a nivel de aplicaciones) que incorporan capacidades de analítica de última generación, los llamados NGFW (firewalls de última generación).

Firepower es el potente NGFW desarrollado por Cisco. Una herramienta de última generación, extremadamente potente y compleja.
Para contar con los concimientos y habilidades necesarios para implementar esta herramienta desarrollé en primer lugar una serie de entrenamiento teórico-prácticos a los que ahora complementa este manual que pongo a disposición de todos los técnicos de habla hispana que necesitan actualizar sus conocimientos y profundizar en estos dispositivos.

Este manual busca dar una presentación sintética y sencilla de los sistemas Cisco Firepower administrados utilizando Firepower Management Center versión 6.4. 
De ninguna manera reemplaza el manual de configuración oficial. Sólo intenta ser un insumo simple y eficaz para quienes deben implementar, monitorear o diagnósticar estos sistemas de modo eficiente y rápido.

Fecha de publicación: 28 de mayo de 2020.

Autor: Oscar A. Gerometta
CCSI / CCNA / CCDA / CCNA wir / CCNA sec / CCCA / CCNP sec / CCBF.
Creador de diversos cursos y talleres orientados a la implementación de sistemas Cisco Firepower.

Texto: Manual.


Examen de referencia: No mapea a ningún examen de certificación


Una versión demo (parcial) de este manual puede accederse
en la biblioteca virtual de EduBooks.
Ingrese aquí
Contenidos:
  • 1. IntroducciónPlataformas
    Opciones de gestión
    Licenciamiento
  • 2. Registro de dispositivos en FMC
    Configuración inicial del sensor
    Configuración inicial del FMC
  • 3. Configuración inicial
    Definición de propiedades generales del sensor
    Implementación de cambios en la configuración
  • 4. Modelos de redundancia
    Modelos de redundancia disponibles
    Implementación del par de alta disponibilidad
    Implementación del clúster
    Modelo de tráfico a través del clúster
  • 5. EnrutamientoEnrutamiento estático
    Enrutamiento dinámico
    Redistribución y filtrado de rutas
  • 6. NATFormas de NAT soportadas
    NAT manual y Auto NAT
    Configuración de políticas NAT
  • 7. Políticas de control de acceso
    Objetos
    Zonas de seguridad
    Políticas de control de acceso
    Configuración de políticas de control de acceso
  • 8. Políticas avanzadasPolíticas de intrusión de tráfico
    Políticas de filtrado de archivos y malware
    Security Intelligence
    Filtrado de URLs
    Orden de ejecución de procesos y políticas
    Políticas de prefiltrado
  • 9. Monitoreo y diagnóstico de problemas
    Registro de eventos del sistema
    Reportería
    Packet Tracer
    Packet Capture
    Visualización de eventos
    Herramientas de diagnóstico de FTD
  • 10. Administración del sistema
    Generación de copias de respaldo
    Restauración de copias de respaldo
    Actualización de software
En su versión actual el manual no incluye la implementación de VPNs IPsec o SSL. En próximas versiones iré incorporando esos y otros temas.

Información para la compra:
  • Implementación y diagnóstico de sistemas Cisco Firepower versión 1.1 puede adquirirse en línea a través del sitio web de Ediciones EduBooks.
  • Para la compra del ebook ingresar aquí.
  • Para la compra de la versión impresa a través de Amazon, ingresar aquí.
  • Para revisar las características de los ebooks de EduBooks, ingresar aquí.
  • Para revisar la versión demo de este manual, ingrese aquí.
Como siempre, cualquier sugerencia que puedas hacer será muy bienvenida.



Para despejar dudas, compartir experiencia con otros, realizar consultas, las redes sociales nos dan una gran herramienta. Para eso están los diferentes grupos asociados a este blog.

Estás invitado a participar de nuestro grupo en Facebook:
https://www.facebook.com/groups/librosnetworking/

O si preferís redes sociales con mayor control de tu privacidad,
podés participar de nuestro grupo en VKontakte
https://vk.com/libros.networking

o seguir las principales novedades en el grupo de Telegram:
https://t.me/LibrosNetworking



Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


28 de marzo de 2020

Auto-MDIX

Automatic Medium-Dependent Interface crossover
En la implementación de interfaces Ethernet que utilizan cableado de par trenzado hay 2 definiciones básicas:

  • MDI (Medium Dependent Interface)
    Describe física y eléctricamente la interfaz de una placa de red o de un dispositivo terminal.
  • MDIX (Medium Dependent Interface crossover)
    Describe física y eléctricamente la interfaz de un puerto de switch o hub.
Estas definiciones son las que permiten que el par de transmisión de un dispositivo esté eléctricamente conectado con el par de recepción del dispositivo que recibirá su transmisión.
En este caso los switches (utilizando interfaces MDIX) son los que "cruzan" la conexión eléctrica posibilitando el establecimiento de esos circuitos.

Auto-MDIX es un mecanismo introducido para eliminar la necesidad de utilizar cables específicos para cada conexión ("cable derecho" o "cable cruzado") detectando automáticamente la señal eléctrica que se recibe para adecuar el puerto del dispositivo a esa señal.
Cuando Auto-MDIX está habilitado en una interfaz detecta automáticamente el tipo de conexión requerido y configura el puerto del modo conveniente.
  • Ha sido incluido en el estándar de Gigabit Ethernet (1000 Base-T IEEE 802.3ab).
  • La resolución de la negociación dura menos de 500 mseg.
  • Requiere que las interfaces estén configuradas para autonegociar velocidad y dúplex.



Los switches Catalyst implementan Auto-MDIX por defecto en todos sus puertos.
Más allá de eso puede desactivarse o activarse por configuración:

Switch# configure terminal
Switch(config)# interface gigabitethernet1/0/1
Switch(config-if)# mdix auto
Switch(config-if)# end



Para despejar dudas, compartir experiencia con otros, realizar consultas, las redes sociales nos dan una gran herramienta. Para eso están los diferentes grupos asociados a este blog.

Estás invitado a participar de nuestro grupo en Facebook:

https://www.facebook.com/groups/librosnetworking/

O si preferís redes sociales con mayor control de tu privacidad,

podés participar de nuestro grupo en VKontakte
https://vk.com/libros.networking

o seguir las principales novedades en el grupo de Telegram:

https://t.me/LibrosNetworking



Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.



1 de junio de 2019

Port Aggregation - Guía de configuración

La configuración de un port aggregation sea de modo estático o con auto-negociación no es un proceso complicado pero sí requiere atención a los detalles ya que una pequeña imprecisión puede hacer que el port-channel no opere o que algún puerto físico no se integre en él.

Un procedimiento sugerido para la configuración es el siguiente:
  • En primer lugar identifique los puertos que se utilizarán en cada switch.
  • Configure el canal en cada interfaz.o  Asigne el número de channel group.o  Especifique el modo de operación (estático, PAgP o LACP).
  • Configure la interfaz port-channel.
  • Verifique la conectividad.
Consideraciones a tener presentes:
  • No es necesario que las interfaces que integran el canal sean físicamente contiguas o pertenezcan al mismo módulo. Sí al mismo switch.
  • Configure todas las interfaces para operar a la misma velocidad y en el mismo modo de dúplex antes de iniciar.
    No las deje en modo de auto-negociación.
  • Todas las interfaces del canal deben estar asignadas a la misma VLAN o configuradas como troncales.
  • Si las interfaces que forman el canal son troncales antes de integrarlas al port-channel, deben tener permitidas las mismas VLANs.
  • El costo STP no impacta en la la formación del canal. Las interfaces pueden tener configurado diferentes costos.
Configuración de port aggregation capa 2

Switch(config)# interface range GigabitEthernet0/1 – 2
Switch(config-if)# no shutdown
Switch(config-if)# channel-group 1 mode on

%LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel1, changed state to up

Switch(config-if)# exit
Switch(config)# interface port-channel 1
Switch(config-if)# switchport mode trunk encapsulation dot1q
Switch(config-if)# switchport mode trunk
Switch(config-if)# exit
Switch(config)# port-channel load-balance dst-ip

Configuración de port aggregation capa 3

Switch(config)# interface range GigabitEthernet0/1 – 2
Switch(config-if)# no shutdown
Switch(config-if)# no ip address
Switch(config-if)# channel-group 1 mode on

%LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel1, changed state to up

Switch(config-if)# exit
Switch(config)# interface port-channel 1
Switch(config-if)# no switchport
Switch(config-if)# ip address 172.16.250.2 255.255.255.252

Switch(config-if)# exit

Verificación de port aggregation

Switch# show etherchannel summary
Flags: D – down         P - bundled in port-channel
       I – stand-alone  s – suspended
       H – Hot-standby (LACP only)
       R – Layer3       S – Layer2
       U – in use       f – filed to allocate aggregator
       M – not in use, minimum links not met
       u – unsuitable for bundling
       w – waiting to be aggregated
       d – default port

Number of channel- groups in use: 1
Number of aggregators:            1

Group  Port-channel  Protocol    Ports
------+-------------+-----------+----------------------
1      Po1(SU)       LACP        Gi0/1(P)   Gi0/2(P)


Switch# show etherchannel load-balance

Switch# show interfaces port-channel 1

Switch# show interfaces FastEthernet 0/1 etherchannel



Para despejar dudas, buscar experiencia de otros, realizar consultas, las redes sociales nos dan una gran herramienta. Para eso están los diferentes grupos asociados a este blog.

Estás invitado a participar de nuestro grupo en Facebook:
https://www.facebook.com/groups/librosnetworking/

O si preferís redes sociales con mayor control de tu privacidad,
podés participar de nuestro grupo en VKontakte
https://vk.com/libros.networking

o seguir las principales novedades en el grupo de Telegram:
https://t.me/LibrosNetworking


Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.