Blog personal de Sergio Madrigal donde encontrar textos sobre ciencia y tecnología, psicología, cine y literatura y quizá alguna cosita más.

Etiqueta: CCNA (página 1 de 2)

Laboratorio de Redes #102 – BGP y OSPF – Redistribución 2

Ya tenéis disponible para descargaros el segundo capítulo de la serie de tutoriales de redes de sergiomadrigal.com.

En este capítulo abordo la implantación en una red CORE de un proveedor de servicios de un protocolo de enrutamiento dinámico, en este caso OSPF, cuya única finalidad será la de publicar las direcciones IP de las interfaces loopback de los dispositivos que van a componer la red BGP.

Esto se realiza de esta forma como parte de las buenas prácticas a la hora de configurar iBGP.

Así mismo configuro la redistribución de los dos procesos OSPF iniciales que publican las redes LAN de Madrid y Valencia con el núcleo BGP proporcionando así la estructura de enrutamiento dinámico necesaria para que ambos entornos, LAN de Valencia y LAN de Madrid sean accesibles entre sí.

Si tenéis cualquier duda o consulta disponéis de los comentarios tanto en el vídeo como en el blog.

[su_youtube url=»https://www.youtube.com/watch?v=n-AaEOUNPMA»]

Redes: El comando network

Si precisamente hace unos días durante la realización del videotutorial #101 – OSPF y BGP – Redistribución | Capítulo 1 os comentaba la pequeña característica especial que tiene el comando «network» a la hora de emplearlo cuando configuramos IGPs (Interior Gateway Protocol) como OSPF o EIGRP, he encontrado esta estupenda entrada en el blog «Mis Libros de Networking» donde explican a la perfección su uso y sus características especiales.

Más allá de las configuraciones en sí mismas que podréis revisar accediendo al enlace, me parece realmente interesante mencionar el siguiente párrafo:

El comando network es el que se utiliza para definir en todos los casos qué interfaces del dispositivo participan del proceso de enrutamiento. Los efectos prácticos del comando son 3

1. Identifica las interfaces a través de las cuáles se publica información del protocolo de enrutamiento hacia los dispositivos vecinos.

2. Identifica las interfaces a través de las cuáles se recibe información del protocolo de enrutamiento publicada por los dispositivos vecinos.

3. La red o subred a la que está asociada la interfaz va a ser incluida en el proceso del protocolo de enrutamiento.

Queda bastante clara la explicación y lo que no es el comando network: no publica las redes que define sino que activa las interfaces que la dupla red / máscara incluye y son las redes asociadas a esas interfaces las que se terminarán publicando.

Os recomiendo que le echéis un vistazo al artículo al completo porque no tiene desperdicio.

# El comando Network en Mis Libros de Networking

Conceptos básicos de redes: Wildcards

La mayoría de veces que trabajemos con direcciones IPv4 haremos uso de las conocidas máscaras de red. Tenéis en el blog un post dedicado íntegramente al concepto de subnetting en el que se profundiza en el uso de las máscaras de red.

Si embargo no siempre se usan estas máscaras en las configuraciones de los routers. Existe otro concepto bastante extendido que, al igual que las máscaras de red, se usa como patrón para delimitar qué porción de la dirección IP introducida corresponde a la dirección de red y qué porción a las posibles direcciones de host. Este concepto se conoce como «wildcard». 

No conozco si existe una traducción al castellano de este mecanismo y su traducción literal queda demasiado mal como para utilizarla en este artículo.

Las wildcards se caracterizan por ser un elemento complementario a las máscaras de red. El patrón que se aplica es, a diferencia de en éstas últimas, el opuesto: cuando hay un 0 se mantiene el valor y cuando hay un 1 se sustituye por un 0.

La mejor forma de entenderlo es con un ejemplo:

Si disponemos de una red /24 como la 192.168.0.1/24, sabemos que el 24 nos indica el número de 1’s que tiene la máscara de red asociada: 255.255.255.0. Si aplicamos la lógica AND entre esta máscara y la dirección IP tendremos como resultado la dirección de red: 192.168.0.x (Siendo x cualquier valor entre 0 y 255)

En el caso de las wildcards tendríamos que usar el número opuesto: 0.0.0.255 para obtener el mismo resultado.

De esta forma la máscara sería 00000000.00000000.00000000.11111111 y sólo en el caso de los 1’s existiría una sustitución por valor 0 en la dirección de red.

Existe un pequeño truco para obtener rápidamente qué valores tenemos disponibles como direcciones de host en una dupla dirección IP + wildcard.

Si por ejemplo disponemos de la dirección 10.0.0.0 con la wildcard 0.0.0.3 las direcciones de host disponibles serían de la 10.0.0.0 a la 10.0.0.3 ¿Sencillo verdad?

Así mismo, como sabemos que la máscara de red es la complementaria, tendríamos que en el ejemplo anterior, para la wildcard 0.0.0.3, nuestra máscara de red debería ser: 255.255.255.252

Se trata de un concepto relativamente sencillo pero que es vital conocer puesto que muchas configuraciones de protocolos de enrutamiento dinámicos, ACLs, route maps, etc., usan este elemento en lugar de las conocidas máscaras de red.

Introducción a la QoS

Con el aumento considerable de servicios proporcionados a través de las redes llegó un momento que se observó que existían dos recursos limitados: el ancho de banda y la latencia. 

Había llegado el momento de gestionar eficientemente estos dos recursos si se quería seguir prestando servicios de calidad puesto que se hacía inviable su aumento infinito. 

Parte de la solución para esta administración eficiente de recursos fue la llegada de la calidad de servicio o, en sus siglas en inglés: QoS. 

El mecanismo de la QoS es tan simple como efectivo. Entendemos que no todos los tráficos generados en nuestro ordenador tienen un comportamiento y un nivel de criticidad equivalente. No es lo mismo que una página web nos tarde un segundo más en cargar que el hecho de que una conversación a través de Skype tenga ese mismo retraso de un segundo. Para solucionar este problema se decidió priorizar el tráfico en función de su sensibilidad ante determinados factores inherentes a una red de computadores: latencia, pérdidas de paquetes, límite de ancho de banda, etc. 

Esta priorización se puede llevar a cabo en muchos niveles del modelo OSI pero la que aquí nos ocupa se realiza en el nivel 3, es decir, en los routers. 

¿Por qué? 

Fundamentalmente porque son elementos presentes en toda la cadena de comunicación desde el emisor de la información al receptor. Y aquí aparece la característica más importante a la hora de aplicar calidad de servicio a nuestro tráfico: todos y cada uno de los dispositivos que formen parte de la comunicación deben implementar QoS. En el momento en el que uno solo de estos dispositivos no tenga configurados los parámetros adecuados la QoS dejará de tener efecto. 

Esto es obvio si pensamos en que si nuestro objetivo es darle prioridad máxima a un tipo de tráfico, todos los dispositivos encargados de encaminar ese tráfico deben estar al tanto de esta situación. Si uno de ellos no lo hace, se producirá un retraso no previsto, una pérdida no deseada y, por tanto, una merma de la calidad del servicio. 

¿Cómo se prioriza?

La forma que tiene la QoS de ponerse a funcionar es tan simple como añadir una cabecera a los paquetes IP en la que se indique su nivel de QoS definido. La complejidad, esto es, el análisis y toma de decisiones, lo realizarán los routers dependiendo del tipo de QoS definida en ellos. La forma de decidir qué tráfico se marca con determinadas etiquetas se debe configurar y puede atender a variables de nivel 3: redes o subredes, vaiables de nivel 4: puertos/protocolos, interfaces específicas, etc. 

En la actualidad la QoS está muy presente en las empresas dado que debido a la convergencia de servicios, tráficos de voz, vídeo y datos suelen compartir medios de comunicación y es vital separar y dotar de la prioridad adecuada a cada uno de estos servicios.

Existe un interesante artículo que explica el tipo de marcado que se realiza a los paquetes IP en el siguiente enlace: http://diecarvi.wordpress.com/2013/05/05/understanding-qos-numbering/

Laboratorio de redes (I): Conexión serial entre routers Cisco.

El objetivo del laboratorio de redes es de disponer, para finales de este año, de todo un diseño de red complejo.

Pero como por algún sitio hemos de empezar, hoy nos dedicaremos a configurar la conexión entre dos routers Cisco.

En este ejemplo hemos empleado dos imágenes de un Cisco 3725 [ c3725-adventerprisek9-mz.124-25d ].

Screen1

Deberemos añadir en las ranuras de configuración de interfaces las correspondientes que necesitamos antes de encender ambos equipos. Como necesitamos al menos un puerto serie por cada uno de los dispositivos, configuraremos convenientemente el dispositivo tal y como muestra la figura.

Screen2

Una vez iniciados los dos equipos bastará con que accedamos por consola a ambos y configuremos las interfaces serie convenientemente.

Accederemos por consola al router 1 (R1):

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int serial 1/0
R1(config-if)#ip address 192.168.0.1 255.255.255.0
R1(config-if)#no shutdown
R1(config-if)#clock rate 64000

Una vez configurado el router 1, pasaremos a configurar el router 2:

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int serial 1/0
R2(config-if)#ip add 192.168.0.2 255.255.255.0
R2(config-if)#no shut

Es importante tener muy presente que una conexión serie es una conexión síncrona lo que explica la necesidad de definir un «clock rate» (tiempo de reloj) para sincronizar el equipo DCE, que será el que marque el sincronismo con el equipo DTE, que será el que esté a la espera de recibirlo. La decisión de que R1 sea el DCE es totalmente aleatoria y este mismo diseño podría haberse realizado siendo R2 el equipo DCE.

De esta manera, los dos routers serán capaces de comunicarse sin problemas al haber establecido una conexión serie completa:

R1#ping 192.168.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/21/28 ms

R2#ping 192.168.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/22/32 ms

 

Herramientas de redes: ping y traceroute.

Ante cualquier anomalía de red un técnico debe actuar de forma concisa y rápida buscando aislar por completo la fuente de error.

En la mayoría de los casos el primer paso será comprobar el alcance de la anomalía y qué servicios o equipos están inaccesibles debido a ella.

Para poder obtener esta información de forma rápida y más o menos precisa todo técnico de redes dispone de dos herramientas básicas para ello: el ping y el traceroute.

Ping

PING’ el acrónimo de Packet Internet Groper, el que puede significar «Buscador o rastreador de paquetes en redes» es una utilidad que envía paquetes ICMP de solicitud y respuesta y cuya finalidad es comprobar que el equipo destino está activo y disponible. También se puede emplear para obtener la latencia (o tiempo de respuesta RTT) entre dos equipos para tener una noción del retardo existente en la conexión. [fuente: Wikipedia]

Esta utilidad suele venir instalada en la práctica totalidad de sistemas operativos/equipos de red y de ahí que ante cualquier situación problemática con una red podamos hacer uso de ella.

Para poder emplearla bajo sistemas Microsoft Windows deberemos primero lanzar una ventana de MS-DOS:

blog_pingtracert_01

Una vez en ella bastará con que empleemos el comando: ping -equipo-, siendo equipo la dirección IP o el nombre de la máquina (siempre que dispongamos de su traducción DNS correspondiente):

Si el resultado es satisfactorio la respuesta nos dirá además el tiempo de respuesta o latencia y el TTL (Time-to-live). Este último parámetro indica el número de saltos que el paquete ha realizado hasta llegar a destino, pero es un número que depende de otros factores como el tipo de conexión y que explicaremos más adelante.

blog_pingtracert_03

Si, por el contrario, el equipo no es accesible, la respuesta obtenida será la siguiente.

blog_pingtracert_04

De este modo con una única utilidad podremos obtener información acerca de la disponibilidad de determinado equipo y, por ende, de determinado servicio.

Traceroute

Traceroute es una utilidad de diagnóstico que permite seguir la pista de los paquetes que vienen desde un host (punto de red). Se obtiene además una estadística del RTT o latencia de red de esos paquetes, lo que viene a ser una estimación de la distancia a la que están los extremos de la comunicación. [fuente: Wikipedia]

En este caso lo que se realizan son llamadas a cada uno de los saltos que realiza el paquete y, por tanto, se nos informa del camino (traza la ruta) que sigue el paquete.

Mediante esta utilidad podemos comprender de forma más coherente el camino que siguen los paquetes e identificar problemas de enrutamiento, balanceo, filtado, etc.

En los sistemas MS Windows la aplicación a emplear es tracert. El procedimiento a seguir es similar, deberemos abrir una ventana de MS DOS y lanzar la aplicación: tracert -equipo-

En la respuesta veremos reflejados todos y cada uno de los saltos que realiza el equipo

blog_pingtracert_05

Si observamos, algunas líneas muestran * en lugar de valores. Esto se debe a que en ese salto nuestro equipo no ha recibido respuesta del equipo destino: hay varias razones para ello pero entre otras el equipo puede tener deshabilitadas las respuestas por motivos de seguridad.

Generalmente si realizamos esta consulta dentro de nuestra red local deberíamos poder ver todas las respuestas.

Con estas dos utilidades, un técnico de redes puede en cuestión de minutos aislar casi por completo la fuente de error de la red y de este modo enfocar todos sus esfuerzos en resolver el punto de fallo. En entornos donde existen una gran cantidad de equipos de red funcionando resulta fundamental discriminar la mayor cantidad de equipos para poder comenzar con el proceso de análisis con un número de variables reducido.

Conceptos básicos de seguridad de red (I)

blog_seguridad

Cuando nos enfrentamos ante la realidad de tener que proporcionar las medidas de seguridad necesarias para preservar la integridad de una red de comunicaciones es fundamental tener muy claros y definidos los conceptos básicos que subyacen a la securización de estas redes.

Confidencialidad, Integridad y Disponibilidad.

Existen tres puntos que debemos asegurar:

Confidencialidad: Sólo los usuarios o sistemas autorizados deben poder ver información sensible o clasificada. Encriptar los datos y separar las redes (datos, management) son un buen primer paso.

Integridad: Los cambios en la información deben ser realizados sólo por usuarios o sistemas autorizados. La corrupción de datos provoca un fallo importante en la seguridad. Existen mecanismos de hashing (resumen) que proporcionan respuesta a esta necesidad asegurando que la información no ha sido modificada durante su transporte.

Disponibilidad: Mantenimiento del estado normal de funcionamiento de los sistemas y la información. Ataques como los DoS (Denial of Service) buscan tumbar sistemas para que la información no esté disponible. Esto puede afectar muy negativamente al normal desarrollo de la actividad de la empresa.

Análisis de seguridad – Conceptos clave.

  • Activo: Cualquier cosa que es valiosa para una organización.
  • Vulnerabilidad: Debilidad explotable en un sistema o en su diseño.
  • Riesgo: Daño potencial a un activo.
  • Contramedida: Acción que de alguna manera mitiga el riesgo potencial.

El valor de un activo depende de muchos factores. La relación coste-beneficio se obtendrá teniendo en cuenta el valor del activo y el coste de su protección.

Vulnerabilidades

Una lista de posibles vulnerabilidades

  • Errores en política de seguridad.
  • Errores de diseño.
  • Debilidad de protocolos.
  • Errores de configuración.
  • Vulnerabilidad de software o hardware.
  • Factores humanos.
  • Software malicioso.
  • Acceso físico a los recursos de red.

Contramedidas

  • Administrativas: Políticas de seguridad, procedimientos, guías y estándares.
  • Físicas: Seguridad física, vigilancia.
  • Lógicas: Contraseñas, firewalls, IPS, Listas de acceso, conexiones seguras vía VPN, etc.

Atacantes potenciales

El perfil de los atacantes ha variado mucho desde que Internet y las redes de comunicaciones iniciaran sus pasos hace ya unos cuantos años. Se ha pasado de un atacante que buscaba notoriedad o el simple hecho de conseguir acceso a algo para lo que no disponía del mismo a empresas y organizaciones dedicadas al espionaje y al robo de información relevante (financiera, política, etc.). Así, grupos terroristas, agencias gubernamentales, estados, hackers, empleados disgustados, competidores, etc., pueden ser potenciales atacantes de nuestras redes.

Métodos básicos de ataque

Reconocimiento: Se trata de un técnica que busca descubrir información sobre la red atacada. Suele ser el primer paso que se da y en el que se obtienen parámetros básicos de la red: direccionamiento, hosts, tipo de tráfico, medidas de seguridad, etc.

Ingeniería social: Su objetivo es el usuario final de forma que obtengan información de él. El Phising, un enlace que parece el real pero que no lo es y que proporciona información al atacante y el Pharming, redirigir al usuario de una página válida a una que no lo es, son métodos de ingeniería social muy extendidos.

Escala de privilegios: Ir ganando privilegios de acceso a determinados servicios o sistemas.

Puertas traseras: Tanto el software como el hardware pueden tener fallos de diseño que permitan a un individuo acceder sin permiso a determinadas partes. Así mismo, terceras aplicaciones (Troyanos) abren puertas para que los atacantes accedan a los sistemas.

Debemos, pues, centrar nuestros esfuerzos en evitar que esos métodos puedan llevarse a cabo con éxito.

Redes Básico (II): Servidor DNS

Hace unos días explicaba de forma introductoria el significado y la utilidad de las direcciones IP. Si recordáis, aquellas matrículas que identifican a todos los dispositivos en Internet.

Sin embargo, pese a que en nuestro día a día navegamos continuamente por distintas páginas web, no creo que hayáis escrito demasiadas direcciones IP en la ventana de vuestro navegador. ¿Por qué?

Bien, los sesudos creadores de la red de redes se dieron cuenta al pasar un poco tiempo, que recordar retahílas de 4 números de 0 a 255 para acceder a los distintos servicios era algo excesivamente complejo hasta para ellos y por tanto pusieron en marcha sus engranajes para desarrollar una solución a este pequeño contratiempo.

Y así nació DNS. DNS son las siglas de Domain Name System y es » un sistema de nomenclatura jerárquica para computadoras, servicios o cualquier recurso conectado a Internet o a una red privada. Este sistema asocia información variada con nombres de dominios asignado a cada uno de los participantes. Su función más importante, es traducir (resolver) nombres inteligibles para las personas en identificadores binarios asociados con los equipos conectados a la red, esto con el propósito de poder localizar y direccionar estos equipos mundialmente.»  [Fuente: Wikipedia España].

Para que nos entendamos, DNS es un sistema compuesto por miles de servidores distribuidos por el mundo que almacenan una tabla en la que relacionan directamente las direcciones IP con el nombre del servidor. De esta forma, cuando nosotros tecleamos en la barra de nuestro navegador www.google.es, en realidad, el navegador lo primero que hace es realizar una consulta DNS.

Esta consulta DNS se realiza al servidor DNS que tengamos configurado y lo que se le solicita es que «resuelva» la dirección IP de «www.google.es». Una vez el servidor la encuentra y nos la devuelve, nuestro navegador realizará a partir de entonces las consultas necesarias mediante la ya conocida matrícula única (la dirección IP).

De nuevo nos encontramos ante un sistema jerárquico. Si las consultas que realizamos a nuestro servidor DNS no devuelven resultado entonces éste realizará una petición un servidor de nivel jerárquico superior (el cual se supone que tiene más duplas dirección IP – nombre del servidor) y así sucesivamente hasta hallar la correspondencia o descartar esa dirección por no existir.

La duda que te puede surgir es ¿y por qué no centralizar en un único superservidor toda la información y no tener que distribuir la información? De esta forma las consultas siempre serían al mismo equipo y si no tuviera la información la resolución sería automática.

La respuesta son en realidad dos: tiempo y seguridad.

Si tuviéramos un único equipo éste debería estar localizado físicamente en algún sitio. Es bastante lógico pensar que si, por ejemplo, estuviera en EE.UU., las consultas tardarían infinitamente más si éstas debieran realizarse hasta allí que si las realizamos contra un servidor alojado a escasos kilómetros de casa. Y con ese servidor, en un porcentaje muy elevado de ocasiones nos basta. Si analizáis vuestro comportamiento en la red veréis como vuestras costumbres de navegación os hacen visitar siempre las mismas páginas.

Disponer de un servicio como éste centralizado supone tener un único punto de fallo. La caída de ese único servidor provocaría dejar sin este servicio al 100% de usuarios.

De modo que normalmente configuramos los servidores DNS que nos proporciona nuestro proveedor de acceso a Internet.

¿Dónde se configuran?

La mayoría de vosotros accederéis a Internet a través de una red con el DHCP habilitado. Esto, en resumidas cuentas, es un «enchufa y funciona», es decir, una vez conectáis el PC al dispositivo de red, éste configura el equipo con todos los parámetros, incluyendo los servidores DNS.

Aún así, si queréis modificar este parámetro no tenéis más que acceder a vuestra configuración de redes y en la pestaña DNS cambiar las direcciones IP de los servidores.

¿Qué alternativas tengo?

Además de los ya mencionados servidores DNS que proporcionan los proveedores, si no quieres pasar por ellos tienes alternativas:

– Google DNS: 8.8.8.8 / 8.8.4.4 [ https://developers.google.com/speed/public-dns/ ]

– Open DNS: 208.67.222.222 / 208.67.220.220 [ http://www.opendns.com/ ]

Porque piensa que estos servidores están recibiendo todas y cada una de las direcciones URL que introduces en tu navegador, ya sea la de la encilopedia Británica, como la de la web de contactos en la que entras a escondidas.