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:

• DHCP Relay

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

Las 25 peores contraseñas del 2018

Por Víctor Reyes 

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

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

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

• Configuración de enlaces troncales en swtiches Catalyst
• Comandos: show interfaces status

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

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

 

Tomado de: https://unaaldia.hispasec.com/2018/09/explicando-wpa3-mas-seguridad-y-mas.html

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 Leobardo Mendez

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.

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

Oferta Agosto 2018 - Compra el Manual IPv6, lleva el BRIDGE de regalo

Por la compra de tu libro de Protocolo de Internet Versión 6, en 250 Bolivianos, te mandamos de REGALO el Bridge CCNA de 200-120 a 200-125, incluye el despacho por courier dentro de territorio Boliviano y la versión digital de la guía CCNA 200-120 GRATIS.


Para clientes antiguos: Si ya compraste el BRIDGE o el IPv6 anteriormente, consulta por una oferta especial.

Oferta válida hasta el 31 de Agosto de 2018 o hasta agotar STOCK del Bridge  
Mas info: libros.networking.bolivia@gmail.com

Estado de la implementación de IPv6

Por Oscar Gerometta

Periódicamente vuelvo a encontrarme con diferentes publicaciones en las que se pone en dudas o se cuestiona la implementación de IPv6. Incluso algunas que siguen considerándola como una propuesta a futuro que podría o no darse.

Ya muchas veces he abordado el tema en este blog, incluso he publicado un manual con los conceptos básicos de IPv6. Pero evidentemente es necesario cada tanto volver sobre el tema.

La implementación de IPv6 no es una posibilidad, es una realidad que no podemos desconocer. Hay mucha información disponible sobre el tema.

La implementación al día de hoy

Como dije, IPv6 no es un proyecto a futuro sino una tecnología ya implementada cuya penetración es creciente cada día. Así lo muestra la información disponible.

Un ejemplo. Google publica en línea el porcentaje de tráfico de sus data centers que utiliza IPv6. Este es el reporte al día de hoy que, como podemos ver, muestra que el 21,09% del tráfico de los data centers de Google es tráfico IPv6 nativo:

Esta información está disponible en línea para quien quiera consultarla en este enlace.

Si lo que queremos es conocer la disponibilidad de conectividad IPv6 a nivel global, este mapa puede servir de primera aproximación:

Una mirada rápida nos permite verificar que el despliegue actual está centrado en América del Norte, Brasil, Europa, India, Japón, Australia y otros países asiáticos. El país con mayor nivel de adopción en este momento es Bélgica con el 62,59% de sus usuarios conectados utilizando IPv6.

Se puede acceder a la información detallada, país por país, desde este enlace.

¿Qué pasa en América Latina?

Como muestra el mapa global, si bien América Latina no se encuentra a la cabeza de la implementación global, tampoco está a la cola de la misma. En los últimos años varios países han disparado sus procesos de adopción

La vista regional del estado de adopción está volcada en este mapa en el que la intensidad del color verde indica un porcentaje creciente de usuarios conectados a IPv6.

Si consideramos el porcentaje de usuarios conectados con IPv6 un índice adecuado de evaluación del proceso, el líder en la región es entonces Uruguay con un 28,4% de sus usuarios conectados a la red IPv6.

Claro que por sus dimensiones, población y peso en la región no podemos ignorar a Brasil que se presenta con un 23,5% de sus usuarios conectados a IPv6.

Lo que es posible verificar de la observación de la información histórica de implementación en la región es que la misma se ha comenzado a desarrollar con mayor intensidad a partir del año 2015.

Esto es para empresas, ¿no para conexiones domiciliarias?

Este es otro prejuicio falso respecto a la implementación de IPv6. No hay un Internet corporativo y otro hogareño. Claro que todo depende de nuestro proveedor de acceso.
 
Pero como un ejemplo, yo estoy en este momento utilizando una conexión hogareño de cable módem, y estoy conectado utilizando IPv6:

Y no se trata solamente de recibir direccionamiento IPv6 global unicast, sino que también opero utilizando IPv6 como primer opción:

Si querés saber si estás verdaderamente operando en la red IPv6 hay varios sitios que permiten verificar esto. Uno de ellos es el sitio de verificación en línea dispuesto por Google:

También es posible utilizar servicios en línea con un análisis más detallados como el de IPv6 Test:

¿Qué debemos esperar a futuro?

A futuro debemos esperar un despliegue creciente de IPv6. Tanto en el ámbito corporativo como en el hogareño.

• Hace ya tiempo que se han agotado las direcciones IPv4 para seguir creciendo.
• El despliegue de IoE es una realidad que ya está instalada y sigue creciendo.
• El requerimiento de direccionamiento IP global es consecuentemente creciente.
• La respuesta para los requerimientos actuales de entonces IPv6.

Podemos discutir la velocidad con la que se realiza el despliegue, pero ya no es posible poner en dudas que se ha de hacer y que debemos ponernos en esta línea de trabajo.

Para quienes mayores precisiones sobre el crecimiento, hay un sitio que hace proyecciones para el despliegue de IPv6 a nivel global y por países. De acuerdo a vyncke.org el despliegue previsible para los próximos 2 años, a nivel global, es el siguiente:

Poner en dudas la implementación de IPv6 parece, entonces, un acto de ignorancia. La pregunta, creo, no es ya si IPv6 se implementará o no sino cuándo la implementaremos y si estamos listos para hacerlo.

Enlaces útiles:

• Estadísticas Google IPv6
• 6lab de Cisco
• Proyecciones de Vyncke.org
• Test IPv6 de Google
• IPv6 Test
• Bibliografía sugerida: Protocolo de Internet versión 6, v3.1
• Presentación: ¿Estás preparado para IPv6?

Tomado de: http://librosnetworking.blogspot.com/2018/03/estado-de-ipv6.html