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