19 de diciembre de 2020

Mitos frecuentes en materia de seguridad

Contenido incluido
en el temario de
CCNA 200-301


En materia de la seguridad de las redes de datos, como en muchos otros ámbitos, hay una serie de afirmaciones o preconceptos que muchas veces llegan a la adopción de políticas erróneas o sub-óptimas.
En orden a tener una visión clara de la problemática, esta es una lista breve de las principales consideraciones que podemos encontrar en la actualidad:

Nadie está interesado en nuestra red
  • En algún momento en el pasado reciente esta afirmación pudo haber sido cierta en el caso de redes pequeñas, pero los atacantes actuales están interesados especialmente en objetivos pequeños pues son más fáciles de atacar.
    No hay red que no pueda ser considerada objetivo de una amenaza. Aún las redes hogareñas.
  • Un afirmación de este tipo genera una peligrosa sensación de confianza que puede resultar en que la red no sea tan segura como podría ser, lo que la hace muy atractiva para los atacantes, como pueden ser los administradores de botnets.
  • Incluso una red de dos computadoras que no contienen información relevante puede seguir siendo un objetivo por varias razones. No hay que descuidar que un atacante puede utilizar estas terminales para acceder a los sistemas remotos a los que acceden sus computadoras.
El router o gateway implementa NAT
  • NAT se ha creado para abordar el problema del agotamiento de direcciones IPv4 o con espacios de direccionamiento superpuestos, y permitir la traducción entre espacios de direcciones privados y públicos. 
  • NAT nunca ha sido un mecanismo de seguridad y, de hecho, existen muchas técnicas que permiten la comunicación bidireccional a través de NAT. 
  • Sin reglas, inspecciones u otros procedimientos de firewalls, los gateways NAT puros nunca deben considerarse parte de una arquitectura de seguridad de la red.
La empresa nunca ha sido pirateada
  • Salvo en el caso de administraciones en las que se supervise y analice regularmente la actividad en sus activos, es imposible asegurar que nunca ha sido pirateado, incluso que no está siendo atacado actualmente. 
  • Una supervisión y análisis efectivos requieren software para automatizar el análisis.
  • Sería más prudente afirmar que “no hemos podido detectar que la empresa haya sido pirateada”.
El personal de TI es el responsable de implementar la seguridad
  • Si bien el personal de TI puede tener un papel muy importante en la configuración, mantenimiento y monitoreo de los controles de seguridad, los usuarios finales son el actor principal en la implementación de la seguridad. 
  • En un entorno típico, los usuarios superan en gran medida al personal de TI. Los usuarios finales deben comprender la necesidad de las políticas de seguridad y su rol como usuarios en la aplicación de esas políticas.
La red cuenta con un firewall; es seguro
  • Durante un tiempo fue frecuente utilizar firewalls para asegurar el perímetro de la red y tener sistemas muy abiertos dentro del perímetro. Sin embargo, hoy comprendemos que los sistemas internos también deben estar asegurados.
  • Confiar en una sola tecnología de seguridad es riesgoso.
    Por ejemplo, los firewalls pueden estar mal configurados y los ataques del lado del cliente son muy difíciles de manejar para los firewalls. 
  • Centrarse en puntos de seguridad individuales y confiar en una sola tecnología de seguridad es insuficiente en los entornos de red actuales.

 


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.

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.

24 de octubre de 2020

Modelos de datos


Contenido incluido
en el temario de
CCNA 200-301

Los modelos de datos describen un conjunto limitado de datos en forma de un esquema de lenguaje.
  • Utilizan parámetros bien definidos para estandarizar la representación de datos de un dispositivo de red de modo tal que la salida de plataformas diferentes sea la misma.
  • No se utiliza para enviar información a los dispositivos y depende de protocolos como NETCONF y RESTCONF para enviar documentos codificados en JSON y XML que simplemente adhieren a un modelo determinado.
  • La configuración de los dispositivos se puede validar contra un modelo de datos para verificar si los cambios son válidos para el dispositivo antes de confirmar los cambios.
Los modelos de datos se utilizan para describir la sintaxis y la semántica utilizadas para trabajar con objetos de datos específicos. Pueden definir atributos y respuestas.
El modelo de gestión basado en CLI tradicional no tiene un marco de referencia o modelo; la gestión basada en programabilidad, en cambio, genera información modelizada. Un dispositivo que tiene una representación JSON o XML de su configuración completa puede gestionarse completamente desde un modelo de datos como YANG.
Los modelos de datos proporcionan una jerarquía bien definida de los datos operativos y de configuración de un dispositivo y las acciones que se pueden realizar mediante un protocolo como NETCONF.
Consideran diferentes categorías de datos:
  • Datos de configuración: 
    Conjunto de datos que pueden guardarse y que se requieren para transformar un sistema en su estado inicial (predeterminado) a su estado actual.
    Por ejemplo, configurar las entradas de las tablas de enrutamiento IP, configurar la MTU de una interfaz, configurar una velocidad determinada en una interfaz Ethernet, etc.
  • Datos de estado operativo: 
    Conjunto de datos que obtiene el sistema en ejecución y que influyen en el comportamiento del sistema de forma similar a los datos de configuración.
    A diferencia de los datos de configuración, los datos del estado operativo son transitorios, responden a un momento específico.
    Los datos se modifican a partir de interacciones con componentes internos o con otros sistemas que utilizan protocolos especializados.
    Por ejemplo, las entradas obtenidas por protocolos de enrutamiento como, atributos de las interfaces de red, etc.
  • Acciones: 
    Conjunto de acciones que admiten transacciones de configuración robustas en la red.
    Cuando se intenta un cambio que afecta a varios dispositivos las acciones simplifican la administración de escenarios de diagnóstico de fallos, lo que resulta en la capacidad de tener transacciones sobre un grupo de dispositivos de manera confiable.

Modelo YANG
YANG se ha convertido en un lenguaje de modelado de datos de hecho. Es un lenguaje basado en estándares que se utiliza para crear solicitudes de configuración de dispositivos o solicitudes de datos operativos (como pueden ser los comandos show). Tiene un formato estructurado similar a un programa de computadora que es legible por humanos. Hay varias aplicaciones disponibles que se pueden ejecutar en una plataforma de administración centralizada para crear estas solicitudes de configuración y datos operativos.
  • Lenguaje de modelado definido en el RFC 6020.
  • Desarrollado en 2010 inicialmente para NETCONF, ahora también se lo utiliza con RESTCONF y gRPC
  • Configuración de modelos y datos de estado operativo
  • Proporciona sintaxis y semántica.
    Proporciona una sintaxis y semántica rica que ofrece restricciones y estructuras reutilizables que pueden ser aplicadas dentro y entre modelos YANG.
  • Utiliza estructuras de datos reutilizables.
  • Existen modelos de datos YANG estándar que se aplican a todos los proveedores y otros que están asociados con las características propietarias de un fabricante específico.
NOTA.
YANG es la forma dominante de modelar la configuración y la información de estado de los dispositivos de la red pero, no es el único método. 
Algunas plataformas de Cisco (por ejemplo, la familia Nexus 9000, Cisco Unified Computing System) no utilizan YANG sino que están totalmente controladas por un modelo propietario



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.

18 de octubre de 2020

Modelo para programabilidad de la red

Contenido incluido
en el temario de
CCNA 200-301

Inicialmente la implementación y gestión de las redes de datos se realizó de modo completamente manual y principalmente utilizando la interfaz de línea de comandos (CLI). Se trataba de una red con una cantidad y variedad de dispositivos mucho menor y con servicios de mucho menos complejidad que las redes que operamos en la actualidad.

En la medida en que evolucionaban estas redes tanto la operación utilizando CLI como la apelación a SNMP fueron adecuadas y suficientes para los requerimientos de la gestión. De hecho, estos mecanismos siguen siendo al día de hoy en muchos casos los principales recursos.
Sin embargo, la sintaxis de la CLI y las opciones configurables de los diferentes protocolos que están asociadas a este mecanismo de gestión varían ampliamente entre diferentes fabricantes, plataformas e incluso versiones de un mismo software. Esta situación, combinada con las restricciones propias de la CLI se ha constituido en una limitación para el uso de la CLI en la gestión de redes a escala; la sola configuración y operación de una función o protocolo específicos puede requerir de muchas variantes de la CLI haciendo su uso complejo y pasible de errores. En estos casos la automatización con scripts es una opción, pero se torna cada vez más compleja.
Por su parte, SNMP ha sido desde hace tiempo la forma más utilizada para el monitoreo de las redes. Es una muy buena opción cuando las redes son medianas o pequeñas y el sondeo de cada dispositivo se realiza por intervalos de 15 a 30 minutos. Sin embargo, SNMP a menudo genera complicaciones operativas al sondear dispositivos con demasiada frecuencia debido al incremento en el uso de la capacidad de transporte de la red. Si bien SNMP ha servido a la industria razonablemente bien; desde la perspectiva de la capacidad de programación de la red SNMP carece de bibliotecas para varios lenguajes de programación.
Una de las limitaciones que presenta el modelo tradicional de gestión es la carencia de una forma adecuada de comunicación máquina a máquina con la red que permita la interacción de los dispositivos terminales con la configuración de la infraestructura de la red de modo automático. 

Este es el lugar para las redes programables. Redes en la que la automatización es posible a partir de la implementación de un conjunto de herramientas de programación adecuadas para gestionar la configuración y la operación de la red.
La programabilidad de las redes ha introducido una serie de protocolos y herramientas cuyo nombre es cada vez más familiar: NETCONF, YANG, XML, etc.
Pero, ¿cuál es el lugar o la función que cumple cada uno de estos elementos nuevos?
Para comprender mejor la operación y flexibilizar su implementación y desarrollo es necesario contar con un modelo teórico que nos permite poner cada uno de estos elementos en un lugar específico. Este es el modelo de redes programables.

Este modelo de programabilidad puede representarse así:
  • Aplicación cliente
    Gestiona las configuraciones y monitorea los dispositivos de la infraestructura.
    La aplicación cliente se puede escribir en diferentes lenguajes de programación (p.e. Python) y los SDK se utilizan a menudo para simplificar la implementación de aplicaciones para la automatización de redes
  • SDK
    Conjunto de herramientas y bibliotecas de software que permiten al usuario final crear sus propias aplicaciones personalizadas para diversos fines incluida la gestión de plataformas de hardware.
  • Protocolo
    Las APIS basadas en modelos admiten múltiples protocolos. Los más utilizados en este momento son NETCONF, RESTCONF y gPRC.
    Los modelos de datos utilizados se basan en estos protocolos.
    La elección del protocolo depende de las herramientas disponibles, la experiencia en redes, programación y automatización.
  • Codificación
    Los datos pueden ser codificados en formatos como JSON, XML o GPB.
    En algunos casos el protocolo está vinculado a codificaciones específicas (como es NETCONF con XML). Esto está relacionado con el protocolo que puede o no admitir diferentes formatos de codificación.
  • Transporte
    Cada API soporta uno o más protocolos de transporte para establecer la comunicación con el dispositivo de red.
  • Modelo de datos
    Es la base de la API.
    Definen la sintaxis y la semántica de los datos, incluidas las limitaciones de esa API.
    Se utilizan parámetros bien definidos para estandarizar la representación de los datos de modo que la salida de diferentes plataformas sea la misma.

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.

 

20 de septiembre de 2020

Introducción a Cisco Umbrella - Gráficos

Umbrella es una importante herramienta de seguridad en redes de cualquier tamaño.

Esta intenta ser una introducción sencilla, en modo gráfico, a la operación de esta herramienta de seguridad. Espero sea 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.

 

12 de septiembre de 2020

CCNA desde cero (review)


Hace ya varios años publiqué una serie de posts con sugerencias para quienes están preparando su examen de certificación.
Sin embargo, las consultas siguen llegando y también algunos puntos de aquellas publicaciones han quedado desactualizadas. Por eso me ha parecido conveniente volver sobre el tema con algunas modificaciones que actualicen aquella propuesta.

Entonces... para quienes comienzan a preparar su examen de certificación aquí hay algunas recomendaciones.

1- El primer paso
 A mi juicio, quienes aspiran a desempeñarse en el ámbito de las redes informáticas o del networking deben comenzar por adquirir los conocimientos y habilidades básicos.
En este sentido creo que el primer paso es estudiar el temario que todos conocemos actualmente como el temario del examen CCNA 200-301 (hay una versión en castellano aquí)
En este punto me refiero a la adquisición de saberes, no necesariamente a la certificación. No hay que confundir la adquisición de conocimientos con su acreditación mediante un examen de certificación. En el esquema de certificaciones actual de Cisco es posible acceder a certificaciones de nivel profesional o experto sin ningún pre-requisito. Esto significa que ya no es necesario comenzar por certificar CCNA. 
Pero sí es necesario tener los conocimientos de un CCNA para poder abordar y comprender con precisión los temarios más avanzados.
Se puede eludir la presentación del examen de certificación pero no es posible ignorar o prescindir de los conceptos y habilidades básicas que abarca. Y estos conceptos y habilidades son los que se adquieren en CCNA.
¿Alcanza con solamente adquirir habilidades prácticas y luego seguir?
No.
La sola práctica sin respaldo teórico es como construir una casa de cartón. Se carece de los fundamentos teóricos, del conocimiento de los protocolos que permiten comprender lo que se está haciendo y a partir de allí desarrollar, innovar, profundizar.
Por otro lado la sola teoría sin práctica tampoco es suficiente. Estudiar el código de tránsito no da las habilidades necesarias para conducir un vehículo.
Teoría y práctica deben ir juntas; y CCNA es el comienzo.

2- ¿Qué necesito para iniciar?
Hay diferentes formas de introducirse en el área y la mejor opción es muy personal ya que depende de los conocimientos y experiencia previos de cada uno.
El mejor camino cuando se es nuevo en el área es tomar algún entrenamiento que no sólo me brinde conocimientos sino también la posibilidad de interacturar con técnicos que ya tienen experiencia en el área y que pueden servirnos de referencia o guía en nuestro propio camino.
En este punto tienen una relevancia particular los entrenamientos oficiales que ofrece Cisco y que tienen algunas ventajas específicas: acceso a los materiales oficiales elaborados por Cisco, accesos a laboratorios y guías de laboratorio para adquirir las habilidades necesarias, acceso a un Instructor certificado por Cisco, el respaldo, supervisión y control de Cisco.
En estos entrenamientos oficiales hay 2 posibilidades:
  • Cisco Networking Academy
    La red de academias oficiales de Cisco.
    Ofrecen un entrenamiento extendido en el tiempo (entre 1 y 2 años con asistencia entre 1 y 3 veces a la semana), con mucho trabajo de laboratorio y extenso intercambio con los instructores.
    A mi juicio es la mejor opción para quienes son completamente nuevos en el área y necesitan una inmersión completa. Aprenderán desde cómo armar un cable hasta la configuración básica de un router.
  • Cisco Learning Partners
    La red de socios de capacitación de Cisco.
    Ofrecen un entrenamiento más intensivo, acotado en el tiempo (entre 1 y 5 semanas), con acceso a laboratorios oficiales e instructores de mucha experiencia.
    Es un modelo de entrenamiento más corporativo.
    Según mi parecer es la mejor opción para quienes ya están iniciados en el área, posiblemente se encuentran trabajando, y necesitan apoyo para sistematizar y completar sus conocimientos.
Más allá del entrenamiento con el acompañamiento de un Instructor oficial por supuesto que es posible desarrollar el mismo programa a través del autoestudio. En este caso es conveniente conseguir un "mentor" que ya tenga experiencia en el universo de las redes para que pueda aconsejar o guiar por un camino que para muchos es nuevo y desconocido. Este mentor puede ser un compañero de trabajo o estudios que tenga experiencia y que pueda guiar o brindar referencias más concretas, clarificar dudas, etc.

3- Hay que conocer el camino
Particularmente importante cuando se elige el camino del autoestudio es conocer el temario a estudiar y a completar.
¿Cuáles son los conocimientos y habilidades que debo cubrir en este trayecto de mi desarrollo profesional?
En este punto la base no es la opinión de nadie en un foro o blog. La base es el temario de las certificaciones actuales que son lo que está requiriendo la industria en este momento.
Entre las certificaciones técnicas y los roles laborales hay una relación estrecha. Las certificaciones técnicas acreditan las capacidades técnicas de quienes aspiran a cubrir puestos de trabajo específicos. Es por esto que más allá de que aspiremos a presentar el examen de certificación, es sumamente importante conocer el temario de las certificaciones. Es lo que responde a la pregunta respecto de lo que se está requiriendo para aspirar a un puesto laboral. Y obviamente también responde la pregunta referida a qué debemos estudiar y practicar.
La referencia para esto es, en el caso de Cisco, el Sitio Oficial de Certificaciones de Cisco. Toda la información actualizada y necesaria se puede encontrar en ese sitio. 

4- ¿Con qué estudio?
Hay muchísimo material disponible para estudiar las certificaciones de Cisco.
Todo lo que puedas necesitar saber, en el caso de Cisco, está disponible en la documentación técnica de acceso gratuito en el sitio de Cisco. Pero más allá de eso siempre es conveniente contar con material de un estilo más didáctico que oriente y facilite el estudio.
Debés tener en cuenta que necesitás cubrir 2 aspecto de tu formación:
  • Para adquirir conocimiento (estudiar teoría) la mejor opción, a mi juicio, son las guías oficiales que entrega Cisco en los entrenamientos oficiales.
    Más allá de estos manuales oficiales que solo se acceden participando de los entrenamientos, hay excelentes guías de preparación.
    Hay que elegir una guía y estudiarla sistemáticamente de inicio a fin, no acumular cantidad de materiales diversos, de distinto origen.
    Cuando se necesita información adicional o complementaria, la consulta en línea al sitio de Cisco es el mejor recurso.
  • Para adquirir habilidades (práctica) siempre el óptimo es contar con dispositivos reales con los que pueda montarse una maqueta de estudio.
    Sin embargo no siempre es posible contar con dispositivos reales, en este caso un muy buen recurso son los emuladores que nos permiten virtualizar dispositivos y correr sistemas operativos reales.
    En este caso hay 2 emuladores ampliamente difundidos: GNS3 y Eve-ng. Ambos muy buenos.
    También es posible utilizar Cisco Modeling Labs.
    Finalmente, un recurso no tan evolucionado pero de implementación más simple son los simuladores. En esto destaca Packet Tracer, el simulador desarrollado por Cisco Networking Academy. Eso si, no hay que perder de perspectiva que se trata de un simulador, no de dispositivos físicos o virtualizados.
    Tanto en el caso de los emuladores, como de Packet Tracer, hay abundante información disponible en los sitios oficiales de cada uno para su instalación y uso.
Por último un comentario.
Lo importante no es saber hacer sino saber lo que se hace.
Centrarnos exclusivamente en la práctica descuidando la teoría termina conduciéndonos a ejecutar procedimientos que no entendemos, sobre los que no podremos luego realizar modificaciones, y lo que es peor, quedarán desactualizados antes cualquier cambio o actualización de un sistema operativo o un feature.
Pero tampoco sirve el conocimiento teórico sin el manejo de los procedimientos.
No se trata de un ejercicio académico sino de la preparación para el desempeño en un puesto laboral específico; y eso requiere de habilidades prácticas.

Claro que tampoco podemos perder de perspectiva la evolución de las redes sobre la que he estado publicando en publicaciones anteriores.
En las nuevas arquitecturas, con control y gestión centralizados, con un gran componente de automatización y aplicaciones avanzadas es muy probable que lo importante ya no sea tanto el conocimiento detallado de comandos de configuración cuanto el manejo de las nuevas herramientas de configuración y diagnóstico, el conocimiento detallado de la operación de los protocolos y, eso si, de los comandos de diagnóstico como por ejemplo los comandos show.
 



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.

 

9 de septiembre de 2020

Opciones de programabilidad de la red

Contenido incluido
en el temario de
CCNA 200-301




Cuando nos referimos a la programabilidad de la red hay múltiples opciones diferentes, ligadas a propuestas de arquitectura diversas.
Estas opciones pueden ser graficadas de la siguiente forma:







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.

7 de septiembre de 2020

Comparación URL Filtering vs. web proxy

Hace ya algunos años se introdujeron nuevas herramientas para asegurar las redes de datos de acuerdo a la evolución de la problemática de seguridad. Entre esas herramientas destacan los firewalls de última generación (NGFW - New Generation Firewall).

Estos firewalls de última generación son sistemas con capacidades que van mucho más allá de la inspección statefull que posibilitaban sus predecesores. Se trata de dispositivos que permiten el monitoreo e inspección de la porción de datos de los paquetes a partir de lo que adquieren capacidad de inspección de protocolos de capa de aplicación, aplicaciones, detección de intrusiones, control de malware, control de archivos en tránsito y filtrado de URLs; incluyendo capacidades de analítica, machine learning y automatización de tareas.

La incorporación de estos nuevos sistemas de firewalling generan en algunos casos confusiones. 

La primera confusión y la más evidente es asumir la integración de los NGFW como una simple actualización de hardware lo que lleva a un sub aprovechamiento de las capacidades de estos dispositivos.

Otra confusión frecuente es considerar que las capacidades de filtrado de URL de estos firewalls los convierten en equivalentes de los servidores web proxy. En esta última quiero concentrarme en esta oportunidad.


¿Qué es un web proxy?

Un servidor proxy es un sistema que intermedia en las peticiones de recursos que realiza un cliente hacia un servidor. En este caso se trata de intermediar en la solicitud de un servicio web (http o https) realizada utilizando un cliente web.

Al decir que se “intermedia” en las peticiones lo que se está indicando es que en estos casos la solicitud del servicio no se realiza de modo directo al servidor que aloja los recursos que se desea acceder sino a este intermediario que realizará la petición “en nombre” del cliente, recibirá la respuesta del servidor y luego la reenviará al cliente que realizó la solicitud original.


Analizado la operación desde la perspectiva del modelo OSI se trata de 2 comunicaciones, una entre el cliente y el servidor proxy, otra entre el servidor proxy y el servidor que aloja el recurso web.

El servidor proxy recibe la solicitud del cliente “en nombre” del servidor web destino y negocia un circuito TCP entre el cliente y el servidor proxy, y sobre él el cliente requiere un servicio http o https. 

A continuación el servidor proxy envía el requerimiento “en nombre” del cliente hacia el servidor web y negocia un nuevo circuito TCP entre el servidor proxy y el servidor destino sobre el que negociará el servicio http o https requerido si la política implementada en el servidor proxy lo permite.

Esta completa intermediación que realiza el servidor proxy en la comunicación TCP/IP posibilita que en el sistema se implementen políticas de seguridad (bloqueo de sitios web, inspección de malware, análisis de contenidos, etc.) e incluso que se realice almacenamiento de contenidos (cacheo) para responder a múltiples solicitudes de igual contenido.


¿Qué es el filtrado de URL de los NGFW?

Los NGFW son dispositivos que están en capacidad de hacer inspección y análisis completo de los paquetes TCP/IP incluyendo la porción de datos. Para esta tarea utilizan poderosos motores de inspección que son los que permiten detectar amenazas latentes en los encabezados o en el contenido transportado por los paquetes.

Entre las inspecciones que están en capacidad de realizar estos nuevos sistemas está la posibilidad de verificar los diferentes comandos de los protocolos de capa de aplicación; de esta manera pueden, en el caso de solicitudes http, verificar la URL solicitada por un cliente de navegación web.

Por esto, a diferencia de los servidores proxy, un NGFW no intermedia en la comunicación TCP/IP que se establece entre un cliente y un servidor.

Analizado desde la perspectiva del modelo OSI el cliente web realiza la negociación TCP directamente con el servidor destino que aloja los recursos que desea acceder.

Esta negociación TCP atraviesa los motores de inspección del NGFW y es verificada de acuerdo a lo establecido en las políticas de control de acceso; si la solicitud es acorde a lo establecido en esas políticas el firewall permite la negociación y el consecuente establecimiento del circuito TCP entre el cliente y el servidor.


Establecido el circuito TCP el cliente web negociará la sesión http que también será sometida a inspección por el NGFW si así lo determinan las políticas de control de acceso configuradas.

Como parte de esa inspección el firewall puede verificar la URL solicitada por el cliente web para asegurar que esté encuadrada dentro de las políticas de uso aceptable configuradas en el sistema.



Como se desprende de este análisis, si bien aparentemente ambos mecanismos tienen un mismo resultado posible son absolutamente diferentes en cuando a su operación y posibilidades.

En caso de implementarse un servidor proxy la comunicación entre cliente y servidor web no será directa sino siempre intermediada por el proxy a partir de la división de la comunicación TCP/IP en dos comunicaciones diferentes; una entre el cliente web y el servidor proxy, otra entre el servidor proxy y el servidor web.

Cuando se trata de un filtrado de URLs implementado en un NGFW, en cambio, la comunicación entre cliente y servidor web es directa, a través de un único circuito TCP, que será inspeccionado y monitoreado por el firewall según se defina en las políticas de control de acceso del sistema.


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.