12 de mayo de 2021

Meraki, control en la nube

Cisco Meraki introduce la tecnología necesaria para desplazar la gestión y control de los dispositivos a la nube. De esta manera ofrece una funcionalidad completa que se puede gestionar y monitorear fácilmente desde cualquier lugar con acceso a Internet y a través de ella, a la nube. Por otra parte, la integración de los dispositivos a esta nube es sumamente simple:

  • Se implementa el dispositivo en las instalaciones de la empresa. 
  • Como consecuencia de esto el dispositivo adquiere una dirección IP (vía DHCP) de gestión y acceso a Internet.
  • El dispositivo se conecta automáticamente en forma segura a la nube Cisco Meraki.
  • Desde el panel de control se registra el dispositivo en la red adecuada, se actualiza el firmware y se descarga la configuración de modo automático.
  • Se inician las tareas de gestión y monitoreo desde el panel de control que brinda herramientas para estas tareas.


Los dispositivos Meraki se entregan preconfigurados con el nombre de host y las direcciones IP necesarias para poder establecer una conexión segura con la nube de Meraki. Esta configuración inicial incluye un certificado digital que se utiliza en el proceso para establecer un túnel cifrado entre el dispositivo y la nube de Meraki para asegurar el tráfico de gestión y control que circula a través de ese circuito.

  • Todo el tráfico que se intercambia con la nube de Meraki circula en un túnel cifrado con un algoritmo basado en AES 256.

El tablero de control es una interfaz web a la que se puede acceder utilizando cualquier navegador web y desde dónde se administran y monitorean todos los dispositivos Meraki de la red corporativa. Cada dispositivo establece su propio túnel cifrado y a  través de esta conexión con la nube:

  • Cada dispositivo independientemente genera un tráfico de entre 1 y 2 Kbps para la gestión y control.
  • A través de ese túnel se descargan configuraciones y e envían datos de monitoreo que se procesan en la nube.
  • El tráfico de los usuarios se reenvía independientemente sin que pase por la nube de Meraki.

Nota: Las cámaras Meraki MV pueden generar picos de tráfico hacia la nube de hasta 200 Kbps cuando tienen activada la función de detección de movimiento. Esta función puede ser desactivada para reducir el consumo de ancho de banda.


Las objeciones más frecuentes están referidas a:

Seguridad
¿En algún momento el tráfico que circula por la red corporativa fluye a través de la nube de Meraki?

  • El tráfico de los usuarios nunca ingresa a la nube de Meraki.
    Esto permite afirmar que todas las implementaciones de Cisco Meraki cumplen con los requerimientos para certificar HIPAA y PCI.
Confiabilidad
¿Qué ocurre si en algún momento los dispositivos de la infraestructura corporativa no pueden acceder a la nube de Meraki?
  • La nube de Meraki tiene una disponibilidad garantizada del 99,99%.
    Este servicio está basado en centros de datos distribuidos en diferentes puntos del planeta.
    Los problemas de conectividad de dispositivos a la nube se deben en su inmensa mayoría a problemas de conectividad del dispositivo hacia la nube, no de disponibilidad de la nube: interrupciones de servicio del ISP, problemas de cableado, o reglas de bloqueo de tráfico.
  • Si se da una interrupción de la conexión con la nube de Meraki los dispositivos continúan reenviando el tráfico de la red corporativa sin interrupciones porque la última configuración conocida de los dispositivos reside localmente en los mismos.
    De ser necesario, cada dispositivo tiene una interfaz web local que se puede utilizar para realizar cambios de configuración básicos (por ejemplo los que puedan impactar en su acceso a Internet).
Previsibilidad
¿Cómo se realizan las actualizaciones de firmware? 
¿Están aseguradas?
¿Con qué frecuencia se publican actualizaciones?
  • Las actualizaciones de firmware se programan y envían a través del panel de control de Meraki. No requieren ninguna operación local.
  • Cisco Meraki tiene 3 categorías de actualizaciones de firmware: estable, candidato a estable y beta.
    El Administrador puede seleccionar la versión de firmware deseada a través del panel de control y programar el momento (día y hora) en que desea que se realice la actualización; o bien puede activar las actualizaciones manualmente.
Escalabilidad
¿Cómo puede crecer la red?
  • La red puede crecer o expandirse de modo muy simple, sencillamente agregando dispositivos y licencias en el tablero de control.


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.



14 de abril de 2021

Un protocolo de verificación para redes inalámbricas

Una solicitud que he recibido muchas veces es la referida a la necesidad de un protocolo, método o lista de verificación para probar la operación de una red inalámbrica después de su implementación o ante la presunción de alguna necesidad específica.

Mi respuesta habitualmente tiende a ser más o menos la siguiente: lo que están buscando es un protocolo de prueba que en realidad debiera haberse definido en el momento de diseñar esa red inalámbrica. La red inalámbrica no es un ente teórico sino un despliegue de tecnología que se supone que debe responder a una necesidad o requerimiento de la organización que la implementa. 
Es por esto que un buen diseño debiera incluir una prueba a ejecutar inmediatamente después de la implementación que verifique el cumplimiento de esos requerimientos.

Por lo tanto el inicio de toda verificación debiera ser una pregunta: "¿cuál es el requerimiento al que se está respondiendo?" La prueba debe diseñarse pensando en responder a ese requerimiento, no a parámetros puramente teóricos.
Es decir, no se trata de verificar parámetros puramente técnicos, sino el cumplimiento de objetivos específicos; muchas veces objetivos vinculados a la operación de la empresa, el desarrollo del negocio u otras áreas vinculadas.

Estas verificaciones debieran considerar al menos 4 elementos básicos.

1. ¿A qué dispositivos se desea dar conectividad?

No todos los dispositivos terminales inalámbricos operan exactamente igual.
La capacidad de de las terminales inalámbricas para conectarse a la red depende básicamente del hardware y el software con el que operan. Y hay diferencias muy significativas entre diferentes terminales, aún del mismo fabricante.
Las terminales pueden tener una sola radio (generalmente de 2,4 GHz) o dos radios (2,4 y 5 GHz); además, pueden estar dotadas de 1, 2 o 3 antenas; y su sensibilidad de recepción es diferentes (típicamente un smartphone tiene menor sensibilidad que una laptop).
Al mismo tiempo, pueden dar soporte a diferentes estándares, hoy, típicamente 802.11n, 802.11ac u 802.11ax, con diferentes anchos de canal, con diferente cantidad de cadenas de transmisión simultáneas.
Diferentes dispositivos, de diferentes fabricantes (o aún del mismo fabricante) pueden responder de modo diferente al conectarse a nuestra red. Esto es lo que explica porqué en muchas situaciones, dos dispositivos colocados uno junto al otro, conectados al mismo access point, presentan performances diferentes.

En este sentido es importante, entonces, que el diseño de la red inalámbrica esté ajustado para dar la mejor respuesta posible a los dispositivos terminales a los que debe ofrecer conectividad; y es eso lo que debemos verificar.

Esto es determinante también al momento de definir con qué dispositivos se van a hacer las pruebas. En este punto debieran elegirse dispositivos que reflejen la realidad operativa del día a día y no terminales de alto nivel que pueden brindar una percepción errónea de lo que luego será el día a día de esa red.

2. ¿Cuál es el throughput esperado?

El concepto es throughput, no data rate.
Lo que debemos considerar es la performance que han de experimentar los usuario, la capacidad real de transporte de datos que brinda la red inalámbrica.
Los usuarios no esperan simplemente conectarse a la red; esperan conectarse y poder operar en condiciones mínimas de performance que consideran adecuadas. ¿Cuáles son esas condiciones? ¿cuántos terminales deben conectarse en esas condiciones dentro de la misma celda? ¿Cuál es throughput total que se espera de la celda?
Porque el througput de una conexión no sólo es resultado del data rate que negocia la conexión sino también de la cantidad y tipo de terminales conectadas simultáneamente dentro de la misma celda.

Para ser claros, para este tipo de mediciones no es adecuada la información que brinda normalmente el software de las terminales, que expresa "data rate". Tampoco se trata de una medición puramente técnica de potencia de la señal o RSSI. Lo que se requiere es una medición de throughput.
La mejor forma de hacerlo es utilizar alguna aplicación diseñada con ese propósito, como puede ser Jperf.

Y lo que debemos evaluar es el throughput total de la celda. Por ejemplo, si se considera que lo adecuado es que una terminal pueda disponer de un throughput de unos 20 Mbps para operar, y se estima que en una celda puede haber aproximadamente 10 terminales conectadas simultaneamente, el objetivo a cubrir es un throughput promedio de 220 Mbps por celda (20 Mbps x 10 terminales y un adicional del 10% por la degradación que genera el incremento en el número de terminales).

3. ¿Cuál es el área de cobertura esperada?

Es sumamente importante tener claro el área o superficie dentro de la cual se espera lograr una conectividad aceptable.
Esto incluye espacios complejos para la propagación de la señal de los APs como son ángulos o rincones, cajas de escalera, sitios en los que la señal de radiofrecuencia pueda estar bloqueada por columnas o paredes gruesas, etc.
¿Dónde esperan lograr conectividad los usuarios?

Para esto es importante contar con un plano del lugar, marcar el área de cobertura acordada y seleccionar los puntos en los que se harán las mediciones de throughput. Es importante contar con la información del site survey previo a la implementación que nos mostrará áreas más difíciles o complejas para verificar cobertura y throughput en los puntos más difíciles.

4. ¿Hay un requerimiento de roaming?

Si en los requerimientos se incluye soportar movilidad para algunos servicios, es importante tenerlo presente y aclarar a qué tipo de servicios hay que dar soporte. Puede tratarse simplemente de movilidad para aplicaciones de datos, o en casos más complejos aplicaciones de voz y/o video.
Es igualmente importante aclarar qué aplicaciones deben operar con movilidad y verificar para esas aplicaciones cuáles son las condiciones soportadas de pérdida de paquetes, delay y jitter.
Otro elemento necesario es determinar las "rutas de roaming", es decir, los caminos más probables a recorrer por los usuarios mientras mantienen operativas sus aplicaciones. Estas rutas son relevantes porque han de estar cubiertas por celdas específicas que son las que deben cumplir con requerimiento de superposición y de sensibilidades mínimas al momento de hacer roaming.

Pero al hablar de movilidad también es preciso tener presente que, por defecto, la determinación del momento de cambio de celda es realizada por el dispositivo terminal, y consecuentemente la operación del roaming está supeditada también a la terminal con la que se está trabajando. Por este motivo, la respuesta al roaming puede variar entre diferentes terminales.

En este punto también es importante, al momento de evaluar si una implementación responde a los objetivos inicialmente propuestos, hacerlo utilizando terminales similares a las que luego se desplegarán en el día a día de la organización.


Mucho más se puede decir sobre el tema pero creo que esta es una primera síntesis que espero pueda ser útil.


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 febrero de 2021

Apunte Rápido CCNA 200-301 versión 7.1

El 24 de febrero de 2020 Cisco introdujo un cambio mayor en su sistema de certificaciones. Parte de ese cambio ha sido la actualización de su certificación CCNA, la que a partir de ese momento se obtiene presentando un único examen de certificación, el examen CCNA 200-301.

Inicialmente, para quienes están preparando su examen de certificación utilizando manuales generados para las certificaciones anteriores publique el manual Bridge a CCNA 200-301 versión 7.0 que desarrolla únicamente los temas que se han agregado a este examen respecto del temario de los exámenes precedentes.

Toca ahora poner a disposición de quienes están preparando su examen de certificación un nuevo manual desarrollado específicamente para el examen CCNA 200-301. Este es el nuevo Apunte Rápido CCNA 200-301 versión 7.1.
Este Apunte Rápido está concebido como un manual sencillo y directo que permite encontrar a quien está preparando su examen de certificación, en un único texto de estudio, la totalidad del temario teórico requerido para obtener su objetivo. Todo y solo aquello que debés estudiar está en este manual. No tiene requisitos previos.

Como en sus versiones anteriores, este manual presenta de modo sintético (quizás no tanto) la totalidad 
del temario del examen de certificación 200-301.
Si eres un alumno de Academia o de Learning Partner, es posible que este manual te sea suficiente y al momento de estudiar utilices los materiales oficiales que recibiste durante tu cursada para aclarar dudas o buscar referencias necesarias.
Para quienes estudian por sí mismos (auto-estudio), este manual desarrolla el temario íntegro del examen de certificación de modo claro, preciso y completo.
No incluye laboratorios o ejercicios prácticos para poner en acción los conceptos desarrollados.

Fecha de publicación: 10 de febrero de 2021

Autor: Oscar A. Gerometta
CCSI / CCNA / CCDA / CCNAwir / CCNA sec. / CCNP sec. / CCBF.
Creador –en el año 2000- del primer curso de apoyo para alumnos de Cisco Networking Academy program que se preparan a rendir su examen de certificación CCNA y una larga trayectoria como desarrollador de cursos y autor de materiales de estudio para diferentes exámenes de certificación.

Texto:

Se trata de un manual de estudio que incluye la totalidad del temario comprendido en el nuevo examen de certificación CCNA 200-301.
Está alineado al examen CCNA 200-301.

Para revisar una versión demo de este manual ingrese aquí

Contenidos:

  • El Examen de certificación CCNA
  • 1. Principios de operación de redes TCP/IP
  • 2. Direccionamiento IP (IPv4/IPv6)
  • 3. Operación de dispositivos Cisco IOS
  • 4. Conmutación LAN
  • 5. Fundamentos de redes inalámbricas
  • 6. Enrutamiento IP
  • 7. Servicios IP
  • 8. Tecnologías WAN
  • 9. Introducción a la seguridad
El índice detallado puede consultarse en la versión demo en línea
Cantidad de páginas: 714 (versión ebook)

Para la compra: 

Apunte Rápido CCNA versión 7.1 ya está disponible en formato e-book e impreso en papel y se puede comprar en línea ingresando al sitio de Ediciones EduBooks.

Para revisar las características de los ebooks de EduBooks ingresar aquí.

Para revisar las características de los impresos adquiridos en línea ingresar aquí.

Para alternativas de pago u otras consultas diríjase directamente a Ediciones EduBooks por correo electrónico escribiendo  a libros.networking@gmail.com

Para facilitar la compra de ebooks desdeBolivia
contactar a: libros.networking.bolivia@gmail.com


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


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.



11 de febrero de 2021

Apunte Rápido CCNA 200-301 - versión demo

Edubooks ha puesto en línea la versión demo de mi nuevo Apunte Rápido CCNA 200-301 versión 7.1

Los Apuntes Rápidos son un formato de manual que adopté desde los inicios de mi tarea como autor de publicaciones. Son manuales sencillo, sintéticos, claros, claramente orientados a desarrollar exclusivamente el temario del examen de certificación y ceñido al mismo. Como siempre este nuevo Apunte Rápido cubre la totalidad del temario del examen aunque sin proponer ejercicios prácticos (laboratorios).

Esta versión 7.1 se mantiene en la línea inicial de estos manuales, pero ahora con un desarrollo extenso y detallado del temario del examen de certificación CCNA 200-301. De ahí que este ebook tenga más de 700 páginas.

En esta versión demo se puede consultar el índice completo del manual y apreciar el inicio del desarrollo del mismo.

En los próximos días estará disponible para la compra tanto en formato ebook como impreso a través de la página web de la Editorial: www.edubooks.com.ar

Apunte Rápido CCNA 200-301 ... by Edubooks Ediciones


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.

23 de enero de 2021

Verificación de la imagen de IOS

Contenido incluido
en el temario de
CCNA 200-301

Es prudente tomar precauciones de seguridad durante todo el ciclo de vida de las imágenes de Cisco IOS dado que son el corazón de la operación de la infraestructura de la red corporativa. Un primer paso en esta dirección es verificar que la imagen de IOS no se haya dañado o haya sido alterada de ninguna manera durante el tránsito desde el centro de descargas de Cisco. Para esto Cisco proporciona un hash de verificación de integridad de la imagen de sistema operativo o de otro software proporcionado, hash que es generado utilizando MD5 o SHA y que se puede obtener en el centro de descarga de software de Cisco.

Los checksums proporcionan un mecanismo de verificación de la integridad de la imagen de IOS o el software descargado. Si la imagen está dañada, la comprobación MD5 o SHA fallará.
Para esto, entonces:
  1. Conéctese al sitio oficial de Cisco y verifique la conexión SSL para asegurar que está conectado al sitio real.
  2. Ingrese al sistema de descargas de software y busque el software que desea descargar.
  3. Abra la ventana de detalles correspondientes a la imagen a descargar (posicione el cursor sobre el nombre de la imagen).
  4. Copie el checksum MD5 o SHA (puede utilizar el ícono de la derecha para copiarlo al portapapeles).
  5. Descargue la imagen a un dispositivo local.
  6. Concluida la descarga, utilice una calculadora de hash para calcular el checksum de la imagen que acaba de guardar.
  7. Verifique que el checksum calculado coincida con el publicado en el sitio de Cisco.
En la actualidad se sugiere utilizar el checksum de SHA por ser considerado más seguro.
Si desea verificar una imagen de IOS que ya está siendo utilizada en un dispositivo, puede hacerlo utilizando el comando verify:

Router#verify /md5 flash:/c2900-universalk9-mz.SPA.154-2.T1.bin
...............................................................................<…Output Omitted…>.......................Done!
verify /md5 (flash:/c2900-universalk9-mz.SPA.154-2.T1.bin) = c1cb5a732753825baf9cs68d329a7be
  • El comando calcula el checksum correspondiente a la imagen guardada en la memoria flash, no la que está corriendo en ese momento en la memoria RAM.
  • De este modo puede verificarse también una imagen descargada pero aún no en uso.


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.

16 de enero de 2021

Diseño de iACL

Contenido incluido
en el temario de
CCNA 200-301

Las iACLs deben ser pensadas como la primera línea de defensa contra amenazas externas, por este motivo deben implementarse en los puntos de entrada de la red para proteger la infraestructura de diferentes riesgos potenciales, tanto accidentales como maliciosos. 
Las iACLs son listas de acceso extendidas que restringen el acceso externo al espacio de direcciones de la infraestructura corporativa. Permiten que solo los dispositivos autorizados se comuniquen con elementos que integran la infraestructura como son los routers y switches, al mismo tiempo que permiten que el tráfico de tránsito fluya libremente.
Por ejemplo, las iACLs implementadas en un punto de entrada a la red desde Internet deben considerar implementar las recomendaciones de los RFCs 1918 y 3330, y la inclusión del filtrado anti-spoofing.

Al diseñar una iACL se debe analizar cuáles son los protocolos cuyo funcionamiento es requerido por la infraestructura. Aunque cada red tiene requisitos diferentesy específicos ciertos protocolos son de implementación habitual y por lo tanto deben ser considerados. Por ejemplo, las conexiones BGP externas a dispositivos externos (del proveedor de servicio, por ejemplo) deben permitirse explícitamente. También se debe permitir explícitamente cualquier otro protocolo que requiera acceso directo a los routers de infraestructura. Por ejemplo, si finaliza un túnel GRE en un router de infraestructura central, entonces el protocolo 47 (GRE) debe permitirse explícitamente. 
Además de los protocolos requeridos para la operación de la infraestructura es necesario identificar también el espacio de direcciones que se utilizan en la infraestructura, ya que este es el espacio de direcciones que debe proteger la iACL. El espacio de direcciones de la infraestructura incluye todas las direcciones que se utilizan para la red interna y a las que rara vez acceden fuentes externas, como es el caso de las interfaces de los routers, el direccionamiento de los enlaces punto a punto y de servicios de infraestructura crítica. Dado que estas direcciones se utilizan para identificar el destino del tráfico en las iACL, la sumarización es fundamental. Siempre que sea posible, estas direcciones deben agruparse, de ser posible, en bloques CIDR.
Dado que muchos ataques se basan en inundar los routers con paquetes fragmentados, el filtrado de fragmentos entrantes a la infraestructura es otro elemento que se debe considerar y que proporciona una medida adicional de protección al mismo tiempo que ayuda a garantizar que un atacante no pueda inyectar fragmentos simplemente haciendo coincidir las reglas de Capa 3 en la iACL. Para esto las sentencias correspondientes que se incorporan en la iACL deben utilizar la keyword fragments que obliga a la sentencia a denegar o permitir fragmentos no iniciales con mayor granularidad.
El uso de una sentencia de denegación (deny) para los fragmentos no iniciales al inicio de la iACL bloquea todos los fragmentos no iniciales evitando que accedan al router. Son raras las circunstancias en las que una sesión válida puede requerir fragmentación.

En consecuencia. Las iACLs deben incluir 3 tipos de sentencias:
  • Sentencias que bloquean los paquetes IP fragmentados.
  • Sentencias que filtran el ingreso desde la red externa (Internet) de tráfico con una dirección IP privada como dirección de origen.
  • Sentencias que filtran tráfico de protocolos requeridos por la infraestructura de la red, según dirección IP de origen.
Un ejemplo de estas iACL podría ser el siguiente:

Rtr(config)#access-list 101 deny tcp any 209.165.200.224 0.0.0.31 fragments
Rtr(config)#access-list 101 deny udp any 209.165.200.224 0.0.0.31 fragments
Rtr(config)#access-list 101 deny icmp any 209.165.200.224 0.0.0.31 fragments

  • Filtrado de fragmentos de tráfico IP que tiene como destino el espacio de direccionamiento IP público que implementa la red corporativa (209.165.200.224/27 en este ejemplo).
  • Se genera una sentencia para cada protocolo (TCP, UDP, ICMP) para tener contadores del tráfico que coincidan con cada sentencia por separado.

Rtr(config)#access-list 101 deny ip 10.0.0.0 0.255.255.255 any
Rtr(config)#access-list 101 deny ip 172.16.0.0 0.15.255.255 any
Rtr(config)#access-list 101 deny ip 192.168.0.0 0.0.255.255 any
  • Bloquea todo el tráfico que tiene como dirección de origen los bloques de direcciones IP privadas definidas en el RFC 1918.
Rtr(config)#access-list 101 deny ip host 0.0.0.0 any
Rtr(config)#access-list 101 deny ip 127.0.0.0 0.255.255.255 any
Rtr(config)#Rtr(config)#access-list 101 deny ip 192.0.2.0 0.0.0.255 any
Rtr(config)#access-list 101 deny ip 224.0.0.0 31.255.255.255 any
  • Bloquea tráfico que tiene como dirección de origen direcciones IPv4 especiales que no debieran aparecen como origen de tráfico.
  • Son las direcciones incluidas en el RFC 3330.
Rtr(config)#access-list 101 permit tcp host 209.165.201.2 host 209.165.201.1 eq bgp
Rtr(config)#access-list 101 permit tcp host 209.165.201.2 eq bgp host 209.165.201.1
  • Se deben permitir los protocolos requeridos para la operación de la infraestructura y cuya dirección IP destino coincide con esa misma infraestructura. En estos casos la buena práctica sugiere que además la dirección IP de origen sea conocida para autorizar explícitamente esa dirección y hacer más granular el permiso.
  • En este ejemplo se está permitiendo el tráfico BGP que se genera en el dispositivo peer con el que se intercambia información de ruteo con ese protocolo.
Rtr(config)#access-list 101 deny ip 209.165.200.224 0.0.0.31 any
  • Bloquea el tráfico IP que tiene como dirección IP de origen el bloque de direcciones públicas asignado a la red corporativa. Esto previene ataques que hagan spoofing de IP utilizando ese bloque de direcciones.
Rtr(config)#access-list 101 permit ip any any
  • Finalmente se permite todo otro tráfico IPv4.
  • Esto permite todo tráfico IP que tiene un destino diferente que la infraestructura protegida y deja el filtrado de ese tráfico a otro dispositivo como puede ser un firewall.
Las iACLs se diseñan para proteger la infraestructura no para proteger otros objetivos de posibles ataques.

 


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 enero de 2021

Nueva actualización del Glosario de Siglas (v1.7)

En la espera de la publicación del Bridge a CCNA 200-301 y mientras reviso textos y escribo otros manuales para las nuevas certificaciones, he actualizado el Glosario de Siglas y Términos de Networking que hace ya más de 5 años está disponible de manera completamente libre en la Biblioteca Virtual de EduBooks en Scribd.

Este texto fue publicado por primera vez en el año 2015 como un desprendimiento de los glosarios de las Guías de Preparación para el examen de certificación, con la intención de construir un complemento a todos los manuales que publico. Esta es ahora la séptima actualización del mismo.





Como siempre, es mi deseo que esta nueva revisión del Glosario sea de ayuda para muchos y utilidad de todos, utilicen o no los manuales de mi autoría.



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.