martes, 1 de enero de 2019

Cisco IOS XE

Cisco IOS XE - Versiones

Por Oscar Gerometta

Ya me he referido varias veces a la migración en curso de sistema operativo IOS a IOS XE. 

Cada día son más las plataformas que operan con este sistema operativo y comienza a ser necesario que nos familiaricemos con la modalidad, versionado y ciclo de vida de este sistema operativo.

Plataformas soportadas
A diciembre de 2018 las plaformas soportadas por IOS XE son las siguientes:

Switches:

  • Catalyst 3650
  • Catalyst 3850
  • Catalyst 9200
  • Catalyst 9300
  • Catalyst 9400
  • Catalyst 9500
Controladores inalámbricos
  • Catalyst 9800
Routers de sucursales
  • ISR 1000
  • ISR 4221
  • ISR 4321
  • ISR 4331
  • ISR 4351
  • ISR 4431
  • ISR 4451
Routers de borde o agregación
  • ASR 900
  • ASR 1001-X
  • ASR 1002-X
  • ASR 1001-HX
  • ASR 1002-HX
  • ASR 1004
  • ASR 1006
  • ASR 1006-X
  • ASR 1009-X
  • ASR 1013
  • NCS 4200
Equivalencia en versiones de IOS con versiones IOS XE
Durante la transición Cisco implementó una equivalencia o mapeo de versiones de IOS 15.x con versiones de IOS XE 03.x
Tomando como base las versiones de IOS, la equivalencia sería la siguiente:
  • IOS 15.2 (2)          IOS XE 03.06.0x
  • IOS 15.2 (3)          IOS XE 03.07.0x
  • Sin equivalencia   IOS XE 16.x
Las imágenes (archivos .bin) de IOS de esta transición muestran en su nombre ambas versiones.
Por ejemplo, una imagen para un switch Catalyst 3650 puede presentar este nombre:

cat3k_caa-universalk9.SPA.03.06.08.E.152-2.E8.bin
  • IOS XE 03.06.08E
  • IOS 15.2(2)E8
Código de nombre de imágenes IOS XE
Como siempre, el código del nombre por defecto de las imágenes suministradas por Cisco proporciona información sobre la el contenido de esa imagen.
Tomo como referencia para el análisis el nombre de una imagen de IOS XE para un switch Catalyst 9300 de 24 puertos:

cat9k_iosxe.16.06.04a.SPA.bin
  • cat9k - Imagen para switches Catalyst serie 9000. En este caso Catalyst 9300, 9400 y 9500.
  • iosxe - Aclara que se trata de una imagen de IOS XE.
  • 16.06.04a - Versión de IOS XE de esta imagen
    16     Major release
    06     Minor release
    04a   Maintenance release
  • SPA - Imagen firmada digitalmente.
    S       Software firmado digitalmente
    P       Imagen implementada para producción
    A       Tipo de llave utilizada para la firma digital: de caracteres alfabéticos.
Versiones disponibles de IOS XE 16
  • IOS EX 16.1.1 Denali
  • IOS EX 16.2.1 Denali
  • IOS EX 16.3.1 Denali
  • IOS EX 16.4.1 Everest
  • IOS EX 16.5.1 Everest
  • IOS EX 16.6.1 Everest
  • IOS EX 16.7.1 Fuji
  • IOS EX 16.8.1 Fuji
  • IOS EX 16.9.1 Fuji
  • IOS EX 16.10.1 Gibraltar
En IOS XE hay 2 tipos de releases:
  • Standard-Support releases.
    Cisco compromete para estos releases soporte por 12 meses a partir de la fecha de FCS (First Customer Shipment).
  • Extended-Support releases.
    Estas versiones tienen un tiempo de soporte de 36 meses a partir de la fecha de FCS.
IOS XE 16.9.1 es el primer extended-support release generado de acuerdo a esta línea de tiempo definida por Cisco. Cada tercer release subsecuente a partir de este punto será entonces un extended-maintenance release (16.9, luego 16.12, y así).
Cisco sugiere migrar hacia un extended-maintenance release cuando ese release comienza a estar disponible.

Ciclo de vida de de los releases de Cisco IOS XE
  • FCS
    First Customer Shipment
    Marca el inicio del ciclo de vida del release.
  • Anuncio de EoL
    Para estandard- support releases se da 3 meses después del FCS.
    Para extended-support releases se da 12 meses después del FCS.
  • EoS
    End of Sale
    Para estandar-support releases, 3 meses a partir del anuncio de EoL.
    Para extended-support releases, 6 meses a partir del anuncio de EoL.
  • End of Software Maintenance
    Tanto para estándar-support como para extended-support releases, 6 meses después del EoS.
  • End of Vulnerability and Security Support
    Para estandard-support releases, 6 meses después del EoS.
    Para extended-support releases, 18 meses después del EoS.
  • Last Date of Support
    5 años después del EoS.
Tomado de: http://librosnetworking.blogspot.com/2018/12/cisco-ios-xe-versiones.html

lunes, 31 de diciembre de 2018

El comando ip helper-address

ip helper-address

Muchos estamos habituados a implementar servicios DHCP proxy, y en dispositivos Cisco IOS eso significa utilizar el comando ip helper-address. Sin embargo, este comando ofrece mucho más que sencillamente un servicio de proxy para servicios DHCP.

¿Qué es un DHCP proxy?
En redes extensas o con múltiples subredes en la que se debe atender solicitudes de  clientes DHCP es habitual que el servidor DHCP se encuentre centralizado.

Sin embargo esto implica una dificultad ya que las solicitudes DHCP se realizan en formato de broadcast (en redes IPv4), y como todos sabemos, los paquetes de broadcast no son reenviados por los dispositivos de capa 3. 

Esto significa que una solicitud DHCP no va más allá del segmento de red en el cual se encuentra el cliente que la genera, ¿cómo podría entonces alcanzar un servidor que se encuentra en una red o segmento de red diferente?

Para esto se utiliza un DHCP proxy. El proxy recibirá la solicitud en formato de broadcast y la convertirá en un paquete unicast cuya dirección destino será la del servidor. 

De esta manera la solicitud se convierte en completamente ruteable y podrá alcanzar el servidor con la única condición de que exista ruta que permita llegar a esa dirección de destino.

ip helper-addreess
En redes Cisco IOS esto se puede implementar utilizando el comando ip helper-address en cliente que requiere una configuración IP utilizando DHCP. Sin embargo este comando no solamente reenvía solicitudes DHCP.

Varios servicios críticos para el funcionamiento de la red utilizan broadcast como DHCP: TACACS, DNS, TFTP, NetBios, etc.; y es común que en redes complejas y extensas estos la interfaz que opera como default-gateway del segmento de red en el que se encuentra el servidores se encuentren en un área de red específica, en otro segmento de red. 

Esto implica que es necesario enrutar solicitudes de todos estos servicios, que en su definición original se propagan por broadcast.

Esta es la situación a la que responde el comando helper-address; permite que los routers actúen como proxies al reenviar solicitudes de estos servicios que corren sobre UDP.

El router recibe las solicitudes UDP en formato de broadcast y las reenvía como paquetes unicast a una dirección IP específica. También puede reenviarlas a una red o subred en particular.

El comando ip helper-address reenvía por defecto 8 servicios UDP: Time, TACACS, DNS, DHCP server, DHCP client, TFTP, NetBios name service y NetBios datagram service.

Table 2-10 Default Forward UDP Services


Service Port
Time 37
TACACS 49
DNS 53
BOOTP/DHCP Server 67
BOOTP/DHCP Client 68
TFTP 69
NetBIOS name service 137
NetBIOS datagram service 138
Tabla obtenida de: http://www.ciscopress.com/articles/article.asp?p=330807&seqNum=9


Router#configure terminal
Router(config)#interface GigabitEthernet 0/0
Router(config-if)#ip helper-address 172.18.1.3

    Reenvía el tráfico de servicios UDP que se recibe a través de la interfaz GigabitEthernet a la dirección 172.18.1.3 . Este comando se puede repetir si es necesario direccionar hacia más de un servidor.
Router(config-if)#ip helper-address 172.18.1.255
    Reenvía el tráfico de servicios UDP que se recibe a través de la interfaz Fastethernet a la subred 172.18.1.0/24. Esta es la forma de aplicación cuando los diferentes servicios no están en una única dirección IP sino en varias de un mismo segmento de red, como ocurre en una granja de servidores.
Router(config-if)#interface GigabitEthernet 0/1
Router(config-if)#ip directed-broadcast
    Cuando se direccionan los servicios UDP a una granja de servidores, es preciso indicar a la interfaz del router que da acceso a la graja de servidores que los servicios que recibe redirigidos a una dirección de broadcast (p.e. 172.18.1.255), debe encapsularlos como broadcast de capa 2 para que entonces puedan ver la petición todos los nodos de la subred.
Router(config-if)#exit
Router(config)#ip forward-protocol udp 517 
    Agrega a la lista de 8 servicios que se reenvían por defecto, el tráfico de UDP que está dirigido al puerto 517.
Router(config)#no ip forward-protocol udp 49 
    Retira de la lista de servicios que se reenvían, el tráfico de TACACS (puerto 49).

Esta configuración puede verificarse utilizando el comando show ip interfaces

Post Relacionado:

Tomado de: http://librosnetworking.blogspot.com/2016/05/ip-helper-address.html

domingo, 30 de diciembre de 2018

Las 25 peores contraseñas del 2018


Por  

Cada año SplashData evalúa millones de credenciales a partir de filtraciones de datos y realiza un ranking de las contraseñas más inseguras. 

Este año entre las 25 primeras podemos encontrar combinaciones nemotécnicas de teclado, como ‘123456’, ‘qwerty’ o ‘zxcvbnm’, nombres propios, como ‘charlie’, e incluso el presidente de los estados unidos ‘donald’ no se libra de aparecer como contraseña.

Listado de las 25 peores contraseñas:


Para evitar caer en esta lista y ser vulnerable a ataques de fuerza bruta es importante seguir una serie de directrices para que tus credenciales sean seguras:
  • Crea contraseñas que combinen letras mayúsculas y minúsculas, números y símbolos.
  • Importante que la contraseña no tenga menos de 15 caracteres: cuantos más dígitos tenga la contraseña, más difícil es romperla por fuerza bruta si se consigue su hash.
  • No reutilizar la misma contraseña en diferentes servicios. Si es necesario, utilizar un gestor de contraseñas como KeePass, Bitwarden, etc. Con ellos puedes generar contraseñas seguras.
  • No utilizar patrones de teclado, por ejemplo ‘qwertyuiop’ o ‘1qaz2wsx3edc’
  • No apuntar la contraseña en notas y pegarlas al escritorio u ordenador, aunque parezca obvio, es algo muy común.
  • Por último una buena acción es comprobar que la contraseña no está en diccionarios de passwords públicos.
Más información: 
TeamsID - https://www.teamsid.com/100-worst-passwords-top-50/

Fuente: Una al día - https://unaaldia.hispasec.com/2018/12/las-25-peores-contrasenas-del-2018.html

sábado, 8 de diciembre de 2018

Diferencias entre SSH1 y SSH2


Hoy aprenderemos sobre las diferencias entre SSH1 y SSH2.

SSH1 (Secure Shell) proporciona un canal encriptado (cifrado) a los usuarios para conectarse remotamente a un dispositivo usando la red de datos. Podemos ejecutar comandos en un servidor y mover archivos de un servidor a otro. Proporciona una autenticación de usuarios y dispositivo-a-dispositivo robusta.  También proporciona comunicaciones seguras encriptadas sobre la Internet.

SSH2 es una versión mucho más segura, eficiente y portable de SSH. Incluye SFTP, la cual es una funcionalidad similar a FTP pero encriptada con SSH2.

Ahora veamos algunas de las protecciones que proporciona SSH2 y que SSH1 no tiene:

1) Eavesdropping: SSH2 encripta toda la información lo cual la protege contra eavesdropping, haciendo la información ilegible a potenciales eavesdroppers.

2) Spoofing de IP y DNS: SSH2 evita este tipos de ataques autenticando criptográficamente la identidad del servidor. Cuando una sesión se establece, el cliente SSH valida la llave de usuario del servidor contra una lista local de llaves disponibles que son asociadas con los nombres de servidor y las direcciones. Si estas no coinciden, entonces inmediatamente se despliega una advertencia.

3) Man in the Middle: SSH2 puede brindar protección contra ataques de man-in-the-middle gracias a la autenticación servidor-a-host. Debido a que el atacante no tiene la llave privada del servidor. En segundo lugar, SSH2 proporciona una autenticación mas robusta para el cliente. Los passwords podrían ser vulnerables a este tipo de ataques, pero las llaves publicas y los certificados son esencialmente inmunes.

Tomado de: https://hoststud.com/resources/what-is-the-difference-between-ssh1-ssh2.278/ con algunos aportes del editor del blog. Traducido por Ing. José R. Torrico Gumucio - Cisco NetAcad instructor desde el 2006

domingo, 7 de octubre de 2018

Verificación de troncales en switches Catalyst

Verificación de enlaces troncales en switches Catalyst

Por Oscar Gerometta

La operación y mantenimiento de enlaces troncales en switches Cisco Catalyst, respecto de su operación específica como troncal, requiere también de herramientas a nivel del sistema operativo que permiten verificar y monitorear la operación de los enlaces troncales que operamos.
 
En este sentido Cisco IOS y Cisco IOS XE proporcionan una serie de comando show que aplican a este propósito:

  • show interfaces status
  • show interfaces trunk
  • show interfaces switchport

show interfaces status

Se trata de un comando poco utilizado en el monitoreo de enlaces troncales que proporciona una rápida visibilidad de cuáles son los puertos que se encuentran operando en modo troncal.
 
No da mayor información sobre la operación.

Switch> show interfaces status

 Port   Name     Status     Vlan      Duplex Speed Type
 Fa0/1           disabled   routed      auto  auto 10/100BaseTX
 Fa0/2           disabled   routed      auto  auto 10/100BaseTX
 Fa0/3           disabled   routed      auto  auto 10/100BaseTX
 Fa0/4           disabled   routed      auto  auto 10/100BaseTX
 Fa0/5           disabled   routed      auto  auto 10/100BaseTX
 Fa0/6           connected  10        a-full a-100 10/100BaseTX
 Fa0/7           connected  10        a-full a-100 10/100BaseTX
 Fa0/8           connected  200       a-half a-100 10/100BaseTX
 Fa0/9           connected  trunk     a-full a-100 10/100BaseTX
 Fa0/10          disabled   routed      auto  auto 10/100BaseTX
 Fa0/11          disabled   routed      auto  auto 10/100BaseTX
 Fa0/12          disabled   routed      auto  auto 10/100BaseTX
 [se omiten líneas]

show interfaces trunk

 Este comando permite verificar múltiples elementos de la operación de los enlaces troncales:

  • Modo en que el puerto se establece como troncal.
    El puerto puede establecerse como troncal a través de una negociación de DTP o por configuración manual.
    En este caso se indica modo "on", esto es configuración manual en modo troncal.
  • Protocolo de etiquetado de VLANs utilizado.
    En el ejemplo de abajo es 802.1Q
  • Estado operativo del puerto.
    En el ejemplo el estado es "trunking".
  • VLAN nativa definida en el puerto.
    En nuestro ejemplo, la VLAN 99.
  • VLANs permitidas en ese puerto troncal.
    En el ejemplo son las VLANs 10 y 99.
  • VLANs permitidas y activas en ese troncal. Puede ocurrir que en un enlace troncal una VLAN esté permitida pero no se encuentre creada en el switch, con lo que estará permitida pero no activa. Es el caso habitual de puertos con configuración por defecto que tienen todas las VLANs posibles permitidas, pero activas solamente las que están creadas en el switch.
    En el ejemplo son las VLANs 10 y 99.
  • VLANs que en este enlace troncal están en modo forwarding (el troncal es parte de la topología activa de STP) y por lo tanto están permitiendo el tráfico de esa VLAN.
    En este ejemplo ambas VLANs utilizan este enlace troncal para el reenvío de tráfico. No hay VLANs bloqueadas.
Switch# show interfaces trunk
Port        Mode    Encapsulation    Status    Native vlan
Gi0/1       on      802.1q           trunking  99

Port        Vlans allowed on trunk
Gi0/1       10,99

Port        Vlans allowed and active in management domain
Gi0/1       10,99

Port        Vlans in spanning tree forwarding state and not pruned

Gi0/1       10,99

Si se indica un puerto específico muestra solamente la información correspondiente a ese puerto. Si no se indica un puerto, muestra todos los puertos troncales del dispositivo.
 
En el caso del ejemplo el switch tiene un solo puerto troncal.


show interfaces switchport

El comando nos permite verificar el estado operativo del puerto en cuanto a su operación en capa 2.

  • Modo administrativo: Muestra la configuración realizada en el puerto.
    En este caso se ha configurado como troncal estáticamente utilizando el comando switchport mode trunk.
  • Modo operativo: Muestra el modo en que el puerto está operando. Cuando se utiliza DTP muestra el resultado de la negociación del protocolo.
    En este caso el modo en que está operando es troncal.
  • Encapsulación administrativa: Refiere a la configuración de encapsulación del puerto.
    En el ejemplo, está configurado para operar utilizando IEEE 802.1Q que es el protocolo por defecto y el único disponible en este caso.
  • Encapsulación operativa: Es la encapsulación que de hecho se está utilizando en el enlace.
    En este caso es 802.1Q.
  • Negociación: Indica si está operativa la negociación de DTP en el puerto.
    En el ejemplo muestra que la negociación está activa.
  • VLAN en modo acceso: Es la VLAN en la cual se colocará el puerto en caso de estar operando en modo acceso si no se indica otra cosa.
  • VLAN nativa en modo troncal: Es la VLAN que se asume como VLAN nativa en caso de que el puerto esté operando en modo troncal, si no se indica otra cosa.
  • Voice VLAN: Indica si se ha definido una VLAN de voz en ese puerto, y en caso de que se haya definida cuál es el ID de VLAN.
    En el caso del ejemplo no hay VLAN de voz definida.
  • A continuación se presenta la información correspondiente a la definición de private VLANs.
Switch# show interfaces GigabitEthernet1/0/1 switchport
 Name: Gig0/1
 Switchport: Enabled
 Administrative Mode: trunk
 Operational Mode: trunk
 Administrative Trunking Encapsulation: dot1q
 Operational Trunking Encapsulation: dot1q
 Negotiation of Trunking: On
 Access Mode VLAN: 1 (default)
 Trunking Native Mode VLAN: 1 (default)
 Voice VLAN: none
 Administrative private-vlan host-association: none
 Administrative private-vlan mapping: none
 Administrative private-vlan trunk native VLAN: none
 Administrative private-vlan trunk encapsulation: dot1q
 Administrative private-vlan trunk normal VLANs: none
 Administrative private-vlan trunk private VLANs: none
 Operational private-vlan: none
 Trunking VLANs Enabled: ALL
 Pruning VLANs Enabled: 2-1001
 Capture Mode Disabled
 Capture VLANs Allowed: ALL

 Protected: false
 Appliance trust: none

Mensaje CDP


Cuando hay diferencia en la definición de la VLAN nativa entre los 2 puertos que componen un enlace troncal, no hay un mensaje de error directo del puerto; sin embargo en los switches Catalyst que tienen activo CDP, la diferencia de configuración entre ambos extremos del troncal genera un mensaje de evento CDP que indica esa falta de coincidencia.

*Mar 1 06:45:26.232: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet0/1 (2), with S2 GigabitEthernet0/1 (99).

El mensaje indica que:
  • El puerto GigabitEthernet0/1 de este switch utiliza la VLAN 2 como VLAN nativa.
  • El puerto GigabitEthernet0/1 del switch vecino (S2) utiliza la VLAN 99 como VLAN nativa.
Esta diferencia de configuración genera el mensaje "NATIVE VLAN MISMATCH".

Tomado de: http://librosnetworking.blogspot.com/2018/09/verificacion-de-enlaces-troncales-en.html

Otros post sobre el tema

domingo, 23 de septiembre de 2018

Enlaces troncales en switches Cisco Catalyst






Por Oscar Gerometta

Configuración de enlaces troncales en switches Catalyst

Respecto de la implementación de VLANs y enlaces troncales, los switches Cisco Catalyst presentan varias definiciones por defecto que debemos tener presentes:

  • Por defecto está creada la VLAN 1, y todos los puertos del switch están asignados a esa VLAN 1.
  • La VLAN 1 es la VLAN de gestión (management) por defecto, y la VLAN nativa por defecto en los enlaces troncales.
  • En la mayoría de los switches en la actualidad no es necesario definir un protocolo de etiquetado de tramas ya que se asume por defecto IEEE 802.1Q. Sin embargo, si el dispositivo soportara ISL, no hay encapsulación por defecto y se debe especificar.
  • Cuando se define un enlace como troncal, por defecto, en ese enlace están permitidas todas las VLANs que se encuentran creadas en el switch.
  • Todos los puertos del switch implementan por defecto DTP para definir dinámicamente si operan en modo acceso o modo troncal.

Configuración básica del troncal

En primer lugar debemos tener presente que un troncal es un enlace que conecta 2 puertos de 2 switches diferentes, que son independientes entre sí. Por lo tanto es esencial que la configuración de ambos puertos sea compatible ya que se configuran de modo independiente.

Switch(config)#interface fastethernet 0/1
Switch(config-if)#shutdown

  • En los manuales de procedimiento se aconseja desactivar la interfaz antes de iniciar propiamente la configuración del puerto para evitar que los procesos de autonegociación estén negociando permanentemente mientras cambiamos la configuración.
Switch(config-if)#switchport trunk encapsulation dot1q
  • El comando define el protocolo de etiquetado de etiquetas que utilizará al operar en modo troncal.
  • No todas las plataformas permiten variar la encapsulación por defecto que se utiliza en los enlaces troncales. En aquellos dispositivos que solamente soportan IEEE 802.1Q este comando no está disponible.
Switch(config-if)#switchport mode trunk
  • Coloca el puerto en modo troncal.
  • Utilizará el protocolo de etiquetado de trama especificado con el comando anterior. Si el comando no está disponible, utilizará por defecto IEEE 802.1Q
  • Todas las VLANs creadas en el switch están permitidas en el enlace.
  • Al utilizar 802.1Q hay siempre una VLAN nativa, y en este caso la VLAN nativa por defecto es la VLAN 1.
Switch(config-if)#no shutdown
  • Terminada la configuración es necesario activar nuevamente el puerto.

Buenas prácticas sugeridas

En este caso se trata de prácticas de configuración sugeridas, no obligatorias, que apuntan a mejorar la seguridad o performance de la red.

1. Desactivar DTP

DTP es el protocolo que negocia, en los swtiches Catalyst, el modo de operación del puerto (troncal o acceso). 

Esto permite que, por ejemplo, un enlace entre 2 switches negocie automáticamente como troncal sin necesidad de intervención del Administrador.
 
DTP está activo por defecto en todos los puertos de los switches Catalyst.
 
Dado que este protocolo permite que un enlace podría negociar sin intervención alguna como troncal, y que ese troncal permitiría por defecto el tráfico de todas las VLANs existentes, DTP es un potencial riesgo de seguridad. De alli que se recomienda desactivarlo.

Switch(config-if)#switchport nonegotiate

  • El comando suprime toda negociación de DTP en el puerto.
  • Este comando es necesario aún cuando el puerto sea colocado manualmente en modo acceso o troncal, ya que el protocolo sigue activo.
  • Esto hace necesario que el otro extremo del enlace también sea configurado manualmente como troncal.
2. Cambiar la VLAN nativa

Todo enlace troncal 802,1Q tiene una VLAN nativa o untagged.
 
En los switches Catalyst la VLAN nativa en los puertos troncales 802.1Q es por defecto la VLAN 1.
 
Dado que la VLAN nativa puede ser aprovechada por un potencial atacante para "saltar" la división de VLANs en la red, se sugiere cambiar la VLAN nativa a otra VLAN en la que no se coloquen puertos de acceso, preferentemente una VLAN que esté en desuso.

Switch(config-if)#switchport trunk native vlan 999

  • Tenga presente que la VLAN nativa debe coincidir en ambos extremos del enlace.
  • Una disparidad en la definición de la VLAN nativa en ambos extremos no genera mensajes de error.
    En el caso de switches Catalyst CDP generará un mensaje de evento 
    CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on... que puede visualizarse en el puerto consola o en el registro de eventos.
3. Restricción de las VLANs transportadas en el enlace troncal

Al activar un enlace troncal, por defecto se permite el transporte de todas las VLANs existentes a través de ese enlace troncal.
 
En algunos casos el diseño de la red requiere restringir las VLANs que se transportan en algunos troncales. Cuando no es así se sugiere, como buena práctica, que se limite las VLANs permitidas a solamente las necesarias.
 
Esto se hace permitiendo solamente las VLANs deseadas con lo que automáticamente quedan excluidas todas las VLANs que no son explíticamente permitidas.

Switch(config-if)#switchport trunk allowed vlan 2-10,20,30

  • De este modo se restringe el troncal exclusivamente a las VLANs que se declaran en el comando. En este caso es el rango de VLANs que va desde la 2 hasta la 10, y además las VLANs 20 y 30.
  • Todas las demás VLANs están excluidas de este enlace troncal.
Switch(config-if)#switchport trunk allowed vlan remove 5
  • Este comando remueve de las VLANs permitidas en el enlace, exclusivamente aquellas que se especifican en el comando. En este caso remueve la VLAN 5 del grupo de VLANs permitidas.
  • Si se aplica en un troncal que está operando con valores por defecto, el resultado será que siguen estando permitidas todas las VLANs salvo aquellas que se indiquen específicamente.
Switch(config-if)#switchport trunk allowed vlan add 40
  • Este comando agrega a las VLANs permitidas en el troncal aquella que se indica específicamente en el comando.
  • ATENCIÓN: Si se intenta agregar una VLAN sin el keyword "add" el resultado será que se sobrescribirán las VLANs permitidas y quedarán como permitidas solamente aquellas que se están especificando en el comando.

Procedimiento de configuración de troncales

1. Ingrese al modo de configuración de la interfaz.
2. Desactive la interfaz.
3. Selecciona la encapsulación a utilizar (si corresponde).
4. Coloque la interfaz en modo troncal.
5. Desactive DTP
6. Modifique la VLAN nativa.
7. Restrinja las VLANs permitidas en el enlace troncal.
8. Reactive la interfaz.

Tomado de: http://librosnetworking.blogspot.com/2018/09/configuracion-de-enlaces-troncales-en.html

sábado, 15 de septiembre de 2018

WPA3: más seguridad y más fácil de usar



Esta nueva versión incluye el nuevo protocolo SAE, que hará inviable nuevos ataques como KRACK; aunque también se incluyen mejoras para hacer más fácil y seguro compartir redes y usar redes públicas

Durante más de una década, el uso de PSK (clave pre-compartida, comúnmente conocido como 'four-way handshake') se ha considerado seguro, hasta que en 2016 un grupo de investigadores belgas descubrieron lo que se denominaría KRACK, dejando de manifiesto la necesidad de buscar una alternativa: SAE (Simultaneous Authentication of Equals). 

Este nuevo protocolo empleado por WPA3 (que en realidad data de 2008), se trata de una variación de dragonfly handshake, contando entre sus novedades resistencia a ataques como el de KRACK, pero además hace inútil los ataques por diccionario a los paquetes interceptados. 


Por si fuese poco, además cuenta con 'forward secrecy'. Esto significa, que aunque se obtenga la clave, un atacante no podrá descifrar los mensajes anteriormente cifrados con dicha clave, porque ésta cambia con cada comunicación.

SAE a diferencia de PSK, tal y como indica su nombre (Simultaneous Authentication of Equals) trata a cada cada parte como iguales, y cualquiera de ellas puede establecer la comunicación. Este nuevo método se contrapone a la forma de trabajar de PSK, en que router y cliente se encontraban diferenciados, y era posible forzar la desconexión entre ambos para analizar los 'handshake' (tal y como hace KRACK).

Además de SAE, WPA3 en su modalidad WPA3-Enterprise contará con cifrado de 192-bits, al contrario que WPA3-Personal, que utilizará 128-bits. Esta seguridad adicional puede ser excesiva para el mercado doméstico, pero su uso puede ser requerido por instituciones y gobiernos.

WPA3 no es sólo más seguro, sino también más fácil de usar. 


Muestra de ello es Easy Connect, un nuevo protocolo que ha sido creado para facilitar compartir (y seguro) el acceso a una red. 

Esta nueva modalidad hace uso de códigos QR únicos, que deben ser escaneados por los dispositivos. 

Para aquellos dispositivos sin posibilidad de escanear el código QR, también será posible utilizar un código legible por un ser humano, e incluso compartirlo mediante sonido. 

Este tipo de medidas evitan compartir la contraseña (lo cual es más inseguro) y reduce los errores comunes al almacenar la clave para compartirla (a.k.a apuntarlo en un post-it). 

Sólo esperemos que estas nuevas facilidades, no se conviertan en un agujero de seguridad, como ya ocurrió con WPS.

Relacionado con lo anterior, el nuevo protocolo Enhanced Open protegerá a los usuarios que se conecten a redes abiertas, como aeropuertos o cafés, de ver sus datos comprometidos por el resto de usuarios de la red. 


Éste es un problema grave existente hasta ahora del que muchos usuarios no son conscientes, siendo la única solución utilizar una VPN (algo, que la mayoría de personas no utilizarán). 

Aunque el uso de una VPN en una red desconocida seguirá siendo aconsejable (porque no sabemos quien controla la red), este nuevo protocolo protegerá en gran medida a los usuarios que no usen una VPN.



Juan José Oyague
joyague@hispasec.com
 

domingo, 26 de agosto de 2018

4 formas de proteger la red WiFi de tu empresa

 

El acceso inalámbrico a Internet se ha vuelto casi ubicuo en establecimientos y organizaciones de casi todos los tamaños, y es rara la empresa que no desea proporcionar acceso wifi a sus huéspedes. Pero ante las ciberamenazas, se necesita cierta precaución.

Por

Las organizaciones de todos los tamaños se están transformando para enfrentar los desafíos cambiantes de la economía empresarial global de hoy. 

Las nuevas innovaciones y los nuevos modelos de negocio están permitiendo nuevos tipos de productividad, ventajas competitivas y crecimiento de los ingresos que impulsan la eficiencia en los recursos de conectividad de una empresa.

Es muy probable que muchas de las expectativas de tus empleados y clientes en cuanto a conectividad inalámbrica en tu negocio estén aumentando, exigiendo tener acceso a una red WiFi para acceder a información en tiempo real en cualquier momento y en cualquier lugar; lo cual presenta grandes beneficios, pero a la vez representa importantes retos, sobre todo en cuestión de ciberseguridad.

Y quizá las empresas en crecimiento son las que tienen el mayor riesgo en esta materia, se estima que 62% de los ciberataques tienen como principal foco las pequeñas y medianas empresas, en alrededor de 4.000 incidentes al día a nivel mundial. 

Cuando una empresa permite conectividad inalámbrica en sitio abierta a empleados, clientes o cualquier visitante externo, el campo de ataque potencial se amplía exponencialmente debido a los distintos usuarios y dispositivos tienen acceso a la red.

Las ventajas de contar con una red WiFi segura

Pero es importante destacar que no todo es una calamidad. La conectividad inalámbrica en una empresa tiene importantes beneficios que en la mayoría de los casos, compensa los potenciales riesgos:

  • Permite el acceso a los recursos de red desde cualquier ubicación dentro del área de cobertura de la red inalámbrica.
  • El acceso inalámbrico a Internet y a los recursos de la compañía ayudan a su personal a ser más productivo y colaborativo.
  • Ya no depende de cables, como es el caso con las redes cableadas. La instalación de los dispositivos de conectividad resulta más rápida y rentable.
  • Puede expandir fácilmente la red donde y según sea necesario.
  • Al eliminar o reducir los gastos de cableado, la red inalámbrica puede costar menos para operarse que una red cableada.

¿Cómo proteger tu red inalámbrica empresarial?

Puedes pensar que la ciberseguridad de tu WiFi red es un gasto que no ayudará a tu empresa a crecer. En lugar de pensar en la seguridad de la red como un problema técnico, piensa en el como un problema de continuidad del negocio.

Las redes se han convertido en una parte básica de hacer negocios hoy en día, por lo que la planificación de la ciberseguridad de tu negocio es tan importante como las ventas y el marketing. 

A continuación, comparto cuatro factores que una empresa debe considerar al configurar una red WiFi de una manera segura:

  1. Ninguna empresa, sin importar su tamaño, debería de dejar el acceso a su red WiFi abierto. Se recomienda que una red se configure con un identificador de conjunto de servicios (SSID), una identificación única que consta de 32 caracteres y se usa para nombrar redes inalámbricas. Esto te permite generar múltiples redes inalámbricas que tengan accesos distintos (por ejemplo: una red dedicada para visitantes, que sea distinta a la red de tus empleados). Cuando varias redes inalámbricas se utilizan en una ubicación determinada, los SSID aseguran que los datos se envían al destino correcto.
  2. Si tienes un flujo constante de visitantes externos que necesitan acceso a la red WiFi, es recomendable contar con un mini portal o páginas web en la cual enlistes tus políticas de acceso a la red local de invitados, a través del cual deben conectarse primero antes de conectarse a la red. Incluye un botón de acuerdo, enumerando los términos y condiciones que deben cumplirse antes de que los invitados se puedan conectar a la red. Esto proporciona cierta protección si un invitado infringe las políticas de tu empresa. Probablemente también sea una buena idea tener un software de filtrado de contenido para evitar que alguien visite sitios inapropiados o maliciosos.
  3. Los administradores de red pueden limitar simple y fácilmente el tiempo límite de los accesos a la red de invitados. Las credenciales de inicio de sesión de los invitados deben caducar después de un período definido, ya sea varias horas, el final del día hábil, 24 horas, varios días o al cierre de la sesión de acceso. Elija un límite de tiempo que se adapte mejor a las necesidades de tu negocio y tus políticas de seguridad.
  4. No asumas que los ciberataques a la red solo pueden provenir de usuarios externos o visitantes a tu negocio. Tus empleados pueden crear vulnerabilidades de seguridad accidentalmente, por lo que es crítico establecer políticas de seguridad y educar a tus colaboradores de las prácticas seguras para el uso de redes inalámbricas.
La seguridad es fundamental para aprovechar, con confianza, los beneficios de productividad y colaboración que ofrecen las redes inalámbricas para lograr el éxito empresarial. 

Una red inalámbrica que cumple con prácticas de seguridad básicas se puede convertir en la plataforma que permita a tu empresa cumplir con estas desafiantes necesidades de negocio, a la vez que mantiene la confiabilidad, escalabilidad y eficiencia operacional, para que puedas dormir tranquilo. 

Te invito a conocer más sobre el amplio y diverso portafolio de seguridad de redes de Cisco así como los equipos de conectividad Cisco para empresas en crecimiento que te permitirán abordar los complejos desafíos de seguridad que se enfrentan en este entorno.

Tomado de: https://gblogs.cisco.com/la/en-leobardo-4-formas-de-proteger-la-red-wifi-de-tu-empresa/ con algunos aportes del editor del blog.

martes, 31 de julio de 2018

El comando "show ipv6 rip database"


Por Oscar Gerometta

Los comandos de monitoreo de protocolos de enrutamiento IPv6 son comandos específicos de cada protocolo. En el caso de RIPng el comando show ipv6 rip tiene una variantes específica de importancia que es show ipv6 rip database.

El comando en sí mismo fue introducido en IOS 10.0 y tuvo algunas modificaciones de consideración en IOS 12,2(15)T y IOS 15.1(2)S. La variante "database" fue introducida en IOS 12.2(3)T.
 
La adición del argumento "database" permite verificar la información correspondiente a las entradas de la tabla de rutas obtenidas por RIPng.

Un ejemplo de este comando en un dispositivo que implementa RIPng:

Router#show ipv6 rip one database
RIP process "one", local RIB
 2001:72D:1000::/64, metric 2
     Ethernet2/2001:DB8:0:ABCD::1, expires in 168 secs
 2001:72D:2000::/64, metric 2, installed
     Ethernet2/2001:DB8:0:ABCD::1, expires in 168 secs
 2001:72D:3000::/64, metric 2, installed
     Ethernet2/2001:DB8:0:ABCD::1, expires in 168 secs
     Ethernet1/2001:DB8::1, expires in 120 secs
 2001:72D:4000::/64, metric 16, expired, [advertise 119/hold 0]
     Ethernet2/2001:DB8:0:ABCD::1
 3004::/64, metric 2 tag 2A, installed
     Ethernet2/2001:DB8:0:ABCD::1, expires in 168 secs



Lectura del comando
Revisemos ahora el resultado de la ejecución del comando:

Router#show ipv6 rip one database

  • Pide la información almacenada en la base de datos que corresponde al proceso de RIPng etiquetado con el nombre "one".
RIP process "one", local RIB
  • "RIP process"
    Indica el nombre del proceso de RIPng al que corresponde la información de enrutamiento que se muestra a continuación.
 2001:72D:1000::/64, metric 2
  • "2002:72D:1000::/64"
    Prefijo IPv6 que identifica la red IPv6 de destino.
  • "metric"
    Cantidad de saltos a travesar para alcanzar la red de destino.
     Ethernet2/2001:DB8:0:ABCD::1, expires in 168 secs
  • "Ethernet2"
    Interfaz a través de la cual la ruta ha sido aprendida.
  • "2201:DB8:0:ABCD::1"
    Dirección IPv6 que corresponde al próximo salto a través del cual se alcanza la red destino.
  • "expires in"
    Tiempo en segundos antes de que la ruta expire.
 2001:72D:2000::/64, metric 2, installed
  • "installed"
    Ruta IPv6 que ha sido instalada en la tabla de enrutamiento IPv6 del dispositivo.
     Ethernet2/2001:DB8:0:ABCD::1, expires in 168 secs
 2001:72D:3000::/64, metric 2, installed
     Ethernet2/2001:DB8:0:ABCD::1, expires in 168 secs
     Ethernet1/2001:DB8::1, expires in 120 secs
 2001:72D:4000::/64, metric 16, expired, [advertise 119/hold 0]

  • "expired"
    La ruta está marcada como inaccesible (métrica = 16 saltos) por haber vencido el temporizador de espera.
  • "advertise"
    En el caso de una ruta "expirada", período de tiempo en segundos durante el cual la ruta será anunciada como inalcanzable.
  • "hold"
    Valor en segundos del temporizados de holddown que se le aplica a la ruta.
     Ethernet2/2001:DB8:0:ABCD::1
 3004::/64, metric 2 tag 2A, installed

  • "tag"
    Etiqueta asociada a la ruta IPv6 que se muestra.
     Ethernet2/2001:DB8:0:ABCD::1, expires in 168 secs

Tomado de http://librosnetworking.blogspot.com/2018/07/comandos-show-ipv6-rip-database.html