Crear una regla en el firewall de Windows

Muchas veces, realizando las prácticas de redes o de servicios en red, nos pasa que, cuando usamos sistemas Windows, y sobre todo sistemas como Windows 7 y Windows 8 (con una política de firewalling mucho más restrictiva que sus hermanos anteriores) nos ocurre algo muy típico:

• Creo una subred, meto varias máquinas dentro y me encuentro con que, desde Windows a Linux (por ejemplo) me deja hacer PING, pero al revés no responde. Profe, ¿a qué se debe?

La mayoría de las veces, descartando errores en la configuración, nos encontramos con que el firewall de Windows está denegando las peticiones entrantes del protocolo ICMP. Con las salientes no se mete pero con las entrantes las bloquea por motivos de seguridad.

¿Qué hacemos? La opción más rápida, y sin que nadie nos oiga, es desactivar el firewall de Windows. Esta es la opción de matar moscas a cañonazos. Lo mejor es habilitar una regla que permita dichas conexiones. El proceso es el siguiente.

• Hay que conseguir ir al Panel de Control. Algo que parece trivial pero que en Windows 8 no lo es tanto.
• Una vez allí, vamos a la categoría de Sistema y Seguridad.
• Elegimos la subcategoría de Firewall de Windows y, en vez de hacer clic en la opción de Activar o desactivar el firewall de Windows, pulsamos en Configuración avanzada.
• Vamos a las reglas de entrada (recordemos que son las peticiones entrantes las que se están denegando) y tenemos que buscar lo siguiente:

• Vemos que hay opciones para ICMPv4 e ICMPv6. De momento habilitaremos sólo las de ICMPv4, ya que no estamos trabajando todavía con ICMPv6 (aunque deberíamos). Para hacer esto, nos dirigimos a la parte derecha, donde nos encontramos algo como esto:
  
• El resultado final es tener las dos entradas habilitadas (una de dominio y otra privada/publica).
  

Una vez habilitadas deberíamos poder hacer ping de manera bidireccional sin nigún tipo de problema.

DNS maestro y esclavo con BIND

Voy a tratar de explicar como montar un DNS maestro usando BIND en Debian 7 y, después, como hacer las modificaciones pertinentes para montar un DNS esclavo del mismo. Lo primero que tenemos que hacer es disponer de una máquina limpia, yo me he decantado por la última versión de Debian sin entorno gráfico porque estoy un poco cansado de Ubuntu Server y su gestión de interfaces. Una vez actualizados los respositorios e instalado el paquete correspondiente (apt-get install bind9) me dispongo a explicar la configuración:

1. Vamos a definir las zonas de búsqueda tanto directas como inversas. Para ello vamos a modificar el fichero /etc/bind/named.conf.local. En mi caso voy a crear una zona llamada "casa.local". En este fichero se indica cual va a ser el tipo del servidor (maestro, esclavo,...) y las rutas de los ficheros de zona.
   
2. Ahora vamos a crear el fichero de búsqueda directa (casa.db). Podemos usar de base uno de los que trae BIND con la instalación para no tener que escribir todo desde cero. Por ejemplo: db.local. Hay que incluir aquellos equipos cuyos nombres queramos que sean resueltos. Ojo con la sintaxis, procurad ser estrictos porque no tolera fallos de caracteres (puntos, puntos y comas,...).
   
3. Hacemos lo mismo con la búsqueda inversa: creamos un fichero (puede usarse uno de ejemplo) y añadimos los datos pertinentes.
   
4. Tenemos que indicar en el fichero de interfaces que el servidor DNS que vamos a utilizar es el servidor que acabamos de montar, es decir: 127.0.0.1.
   
5. En este caso vamos a activar los forwarders para que el equipo solicite externamente aquello que no puede resolver por si mismo, por ejemplo: www.google.com.
   
6. Ya estaría el servidor montado y configurado. Reiniciamos los interfaces de red, reiniciamos el servicio y hacemos pruebas de resolución con varios clientes e, incluso, pruebas de resolución externa.

A partir de esta configuración vamos a montar ahora un nuevo servidor DNS en otra máquina que funcione como esclavo. Los primeros pasos son los mismos: una máquina nueva, actualización de repositorios e instalación del paquete con el servidor. Lo que cambiaría son los siguientes pasos:

1. En el fichero de resolución directa del DNS Maestro hay que añadir dos líneas: una en la que indiquemos el servidor dns2 y otra en la que indiquemos la IP que va a tener (192.168.1.60 en este caso).
   
2. También hay que añadir una línea en el fichero de resolución inversa, para indicar el servidor DNS esclavo.
   
3. Ahora tenemos que comunicar la existencia del nuevo servidor esclavo al servidor maestro. Esto lo haremos modificando el fichero de configuración: named.conf.local.
   
4. Y a la inversa, es decir, indicar en el servidor esclavo quien es el maestro. También tenemos que decirle que va a ser del tipo esclavo (slave).
   
5. Es importante indicar en el fichero de interfaces de red del servidor esclavo que la línea dns-nameservers tiene que apuntar a 127.0.0.1, es decir, que él mismo (el servidor esclavo) será el encargado de resolver los nombres. Reiniciamos interfaces de red (en ambos casos) y servicios (en ambos casos) y debería funcionar la resolución de nombres tanto en servidores como en clientes.

Realizando esta tarea me he encontrado problemas relacionados sobre todo con la sintaxis de los ficheros (desaparece algún punto o punto y coma), con la configuración de los interfaces (es importante no olvidarse que la línea correspondiente del fichero de interfaces tiene que apuntar al servidor correcto) y, uno de los más latosos, con el fichero /etc/resov.conf. Este fichero puede darnos verdareros problemas si nos empeñamos en indicar una configuración en un lado (/etc/network/interfaces) y otra configuración en otro (/etc/resolv.conf), ya que casi con total seguridad puede coger la de este último mientras nosotros estamos plenamente convencidos de que no lo hace.

NAT estático en Packet Tracer

Antes de nada deberemos saber que es NAT. NAT (network Address Translation) es un servicio que traduce IPs privadas en IPs públicas. Hay varios tipos: estático y dinámico. Hoy nos vamos a centrar en el estático porque es el más sencillo para empezar. También es conveniente saber que en NAT estático tiene que haber como mínimo tantas IPs públicas como IPs privadas. Lo que haremos será configurar una red privada con un equipo y una red pública con un equipo unidas mediante un router.

Configuramos cada uno de los interfaces para que haya conexión (que los enlaces se pongan en verde) entre los diferentes dispositivos de la siguiente manera:

• Interfaz PC-PT: 192.168.1.100/24 con gateway 192.168.1.1/24
• Interfaz Server-PT: 200.168.1.100/24 con gateway 200.168.1.1/24
• Router1: 192.168.1.1/24 (fa0/0) 200.168.1.1/24 (fa0/1)

Cuando tengamos conexión, si probamos a enviar un paquete ICMP del PC-PT al Server-PT, funcionará y sin hacer NAT. ¿Por qué? Pues es tan sencillo como que el router tiene, respectivamente, sus interfaces en la misma red que cada uno de los equipos. Es el mismo router el que se encarga de hacer esta gestión automáticamente. De hecho, si nos fijamos en el paquete ICMP cuando llega al Server-PT tiene el siguiente aspecto:

Si nos fijamos, le acaba de llegar un paquete con el origen 192.168.1.100. Esto plantea un serio problema y es que, en Internet los routers están configurados según la RFC , es decir, están configurados para eliminar aquel tráfico que provenga o que vaya a redes privadas. ¿Cómo solucionamos esto? Con NAT. Lo que podemos hacer es convertir la IP privada en una IP pública. En un caso real, esta IP pública será proporcionada por nuestro ISP. En nuestro caso utilizaremos la IP pública de nuestro router, es decir, la 200.168.1.1. De este modo, cuando le llegue un paquete al Server-PT le llegará con el siguiente formato:

Si nos fijamos ahora la IP de origen ya no es una IP privada, sino que es la IP pública de nuestro router, se ha enmascarado, se ha hecho NAT. Para conseguir ésto hay que introducir en la consola del router los siguientes comandos:

• ip nat inside source static 192.168.1.100 200.168.1.1 (IP privada e interna por la IP pública del router)
• interface fa0/0
• ip nat inside
• interface fa0/1
• ip nat outside

Vemos como quedaría en la consola (CLI) del router:

Configuración de direccionamiento y enrutamiento

Hay varias maneras de configurar un interfaz en Linux (vamos a ver distribuciones basadas en Debian). Una de ellas sería modificar el fichero /et/network/interfaces y levantando y tirando cada interfaz con los comandos ifdown e ifup. Otra podría ser directamente con el comando ifconfig. Y la última sería utilizando el conjunto de comandos proporcionados por el paquete iproute2. Una de las ventajas de utilizar este paquete es que también nos permite realizar enrutamiento con los comandos que proporciona. Aunque se pueden ejecutar los comandos ip addr help y man ip para conocer las opciones con más detalle, vamos a verlo:

Direccionamiento

• ip addr flush dev eth0: elimina las direcciones IP de la interfaz eth0.
• ip addr del 192.168.1.100/24 dev eth0: elimina las direcciones IP de la interfaz eth0. 
• ip addr add 192.168.1.100/24 dev eth0: asigna la dirección IP 192.168.1.100 con la máscara de red 255.255.255.0 en la interfaz eth0.
• ip addr: visualiza el direccionamiento de todas las interfaces de nuestro equipo.

Activación/Desactivación

• ip link set dev eth0 up: activa/levanta el interfaz eth0.
• ip link set dev eth0 down: desactiva/tira el interfaz eth0. 

Enrutamiento

• ip route add 192.168.1.0/24 via 192.168.2.1 dev eth0: añade la ruta a la red 192.168.1.0/24, enviándolo por el router con la IP 192.168.2.1 y por el interfaz del equipo eth0.
• ip route add default via 192.168.2.1 dev eth0: añade la ruta por defecto (0.0.0.0), enviándolo por el router con la IP 192.168.2.1 y por el interfaz del equipo eth0.
• ip route: visualiza la tabla de rutas del equipo.

NAT con IPTABLES (II) - Implementación

Vamos a ver su implementación en Ubuntu Server. Lo primero que tenemos que hacer es activar el enrutamiento:

• nano /proc/sys/net/ipv4/ip_forward

Y modificamos el valor del parámetro a 1. O también lo podemos hacer directamente:

• echo "1" > /proc/sys/net/ipv4/ip_forward

Si no queremos realizar esta operación cada vez que se arranque el equipo deberemos incluir la siguiente línea en el fichero /et/network/options:

• ip_forward=yes

Para ver las reglas que están en vigor:

• Iptables -t nat -L
• -t: indica la tabla (nat, filter,...)
• -L: Listar.

Si queremos borrar todas las reglas de la tabla:

• Iptables -t nat -F
• -F: indica flush, borrar.

Para establecer las políticas por defecto:

• Iptables -t nat -P PREROUTING ACCEPT
• Iptables -t nat -P OUTPUT ACCEPT
• Iptables -t nat -P POSTROUTING ACCEPT

Hacer un NAT POSTROUTING:

• Iptables -t nat -A POSTROUTING -s <red_interna>/<máscara> -o <interfaz> -j SNAT -to-source <ip_externa>
• -A: agrega, -D elimina.
• -s: red origen, por ejemplo 192.168.1.0/24
• -o: interfaz por donde entran los paquetes, por ejemplo eth1.
• -j: tipo de enmascaramiento, SNAT, MASQUERADE,...
• -to-source: Ip de la interfaz de salida del encaminador 10.0.52.100. En el caso de hacer MASQUERADE esta opción no sería necesaria.

NAT con IPTABLES - Introducción

Cuando un equipo recibe un paquete el destino puede ser el propio equipo (será enviado a los protocolos superiores) o puede ser otro equipo. Es en este caso cuando decimos que está funcionando como un encaminador o Forwarder. Por eso, si queremos comunicar una red privada con una red pública, los clientes de la red privada envían paquetes con la dirección de origen perteneciente a la red privada así que, cuando vienen de vuelta, o hacemos NAT o no podrían recibir las respuestas. Así que vamos a ver como configurar un equipo para que realice NAT (Network Address Translation).

Cuando hacemos NAT tenemos:

• SNAT: cambiar la dirección IP:puerto de origen.
• DNAT: cambiar la dirección IP:puerto de destino.

También tenemos varios tipos de enmascaramiento:

• SNAT: cuando un cliente de la red privada solicita información externa - de la red pública -. El encaminador, cuando recibe el paquete, cambia la IP y el puerto de origen con su IP externa y un puerto no usado. Almacena en una tabla - de traducciones - el valor de la IP y el puerto original frente al valor de la IP y el puerto de salida, es decir, una vez modificados. Cuando reciba la respuesta restaurará los valores originales (UN-NAT automático) antes de proceder a su envío.
• DNAT: se usa normalmente cuando se requiere un servicio de la red privada, por ejemplo: un servidor WEB. El encaminador cambia la IP y el puerto de destino y no existirán UN-DNAT, ya que ese paquete no tendrá retorno.
• MASQUERADE: es idéntico al SNAT, la diferencia redica en que en las reglas de SNAT debes especificar cual es la IP (y puertos) a la que la debe traducir mientras que MASQUERADE averigua cual es la IP de tu interfaz de salida de modo automático. Esto es más cómodo pero menos eficiente, ya que se incrementa el tiempo de proceso. Es recomendable utilizar MASQUERADE si la IP de salida es dinámica.

VLANs en Packet Tracer

Hay varias maneras de crear VLANs en el simulador Packet Tracer

1. VLANs en modo gráfico: hacemos clic en el switch -> config y luego en la pestiñita de base de datos. Desde ahí podemos crear una nueva VLAN.
2. VLANs desde la consola: hacemos clic en el switch -> CLI y tenemos que escribir los siguientes comandos: 
   • enable
   • configure terminal
   • vlan <numero_de_vlan>
   • name <nombre_de_vlan>
   • exit

De todos modos, cuando creamos una en modo gráfico podemos obtener los comandos de la consola que va generando él automáticamente.