Jose Antonio Cely Saidiza

Antiguo y olvidado, Weblog personal

MONTANDO UN GATEWAY GNU/LINUX CON TODO Y FIREWALL

By Jose Antonio Cely Saidiza

Se denomina Gateway al servidor que permite a las computadoras que se encuentran dentro de una determinada red conectarse a otras computadoras que se encuentran en otra red, la otra red es generalmente Internet.
Entonces la idea es montarnos un server que nos comparta una conexión dedicada a Internet. Para esto podemos usar cualquier CPU obsoleta que tengamos por ahí descuidada. Cualquier Pentium, o Pentium 2 nos puede servir. Asumimos que tenemos un Debian instalado, aunque esto funciona con cualquier distro.
Para compartir la conexión a Internet necesitamos hacer NAT  (Network Address Translation, en español Traducción de la dirección de red), dicho de una forma casta, es el proceso que hace algún dispositivo de hardware como un router o un servidor, el cual maneja dos redes, una interna (LAN) y una externa (Internet), comparte su conexión a Internet cambiando las IP de origen de las peticiones que vienen de la LAN por su propia IP enviándolas a Internet, cuando recibe la respuesta de Internet identifica el paquete y lo redirecciona dentro de la LAN a el equipo que hizo la solicitud. Este proceso es transparante tanto para el equipo dentro de la LAN como para el servidor que responde desde Internet
Tal vez esta animación que realicé para una capacitación aclare este concepto.

firewallejemplo.gifClick en la imagen para ver

 

QUE ES IPTABLES?

Para crear un firewall necesitamos ejecutar comandos de IPTABLES, que es la aplicación firewall para el Kernel Linux en las series del núcleo 2.4 y posteriores, reemplaza a ipchains de las series 2.2 e ipfwadm de las series 2.0. En la mayoría de los manuales que he visto de Iptables, explican como compilar el Kernel para activar Iptables, pero NUNCA lo he tenido que hacer, en las distribuciones que he probado (que son bastantes) siempre esta Iptables funcionando, no hay necesidad de recompilar el Kernel, eso lo que hace es confundir a usuarios noveles como me paso a mi hace unos años :(.
Volviendo al tema, un comando de iptables modifica el comportamiento del Kernel con respecto a la administración de los paquetes de red, es decir que le podemos decir al kernel que haga y que no haga con los paquetes, no les parece fantástico ? … Generalmente tenemos que digitar mas de un comando de Iptables para crear un firewall, es por eso que tenemos que hacer un script con los comandos para no estar digitando cada que iniciamos la maquina los comandos, pero nótese que el firewall NO ES EL SCRIPT!, en el script guardamos son los comandos de Iptables, el firewall es el mismisimo Kernel en persona, no es una aplicación por ahí volando.

EL FIREWALL CON IPTABLES

Aca pueden bajar el script que a continuación trato de explicar

#!/bin/bash
# firewall de ejercicio, con NAT, y bloqueo de puertos

Los caracteres #! indican que el shell /bin/sh es el programa a para ejecutar este script.

IPTABLES="/sbin/iptables"         # ubicacion de iptables
INTERNET="eth0"             # tarjeta de red que se conecta a Internet
LAN="eth1"                 # tarjeta de red que se conecta a la red local
IP_INTERNET="192.168.1.3"          # dirección IP de la tarjeta de red que se conecta Internet

Aca configuro variables en shell para el firewall, esto se hace para que sea mas practico hacer cambios al script. Adaptadlo a tus necesidades.

$IPTABLES -F
$IPTABLES -t nat -F


Borro reglas anteriores, esto es en caso que se haya ejecutado alguna otra sentencia de iptables, por ejemplo algún script de arranque en la distribución que usen o pruebas anteriores de nosotros mismos

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

Activamos el reenvío de paquetes en el Kernel poniendo un ‘1’ en el archivo /proc/sys/net/ipv4/ip_forward , si no se hace, el kernel sencillamente ignoraría los paquetes, por que no son suyos.

$IPTABLES -t nat -A POSTROUTING -o $INTERNET -j SNAT –to $IP_INTERNET

Masquerading es un caso especial de SNAT (source NAT) donde se cambia la dirección IP de origen por la de la interfaz por la cual sale el paquete.

# Dejo pasar los paquetes ICMP
$IPTABLES -A INPUT -i $INTERNET -p ICMP -j ACCEPT

Dejo pasar paquetes ICMP, esto es para que el firewall responda pings, nada mas, algunos dirán que es algo inseguro, pero anda tíos que este es un tutorial básico y para el troubleshoting es mejor habilitar pings.

$IPTABLES -A INPUT -i $INTERNET -p TCP –dport 80 -m state –state NEW -j ACCEPT
$IPTABLES -A INPUT -i $INTERNET -p TCP –dport 22 -m state –state NEW -j ACCEPT

Permito conexiones al puerto 80 (Web) y al puerto 22 (ssh), para poder acceder a estos servicios desde Internet

$IPTABLES -A INPUT -p TCP -m state –state RELATED -j ACCEPT

Acepto paquetes de conexiones ya establecidas

$IPTABLES -A INPUT -i $INTERNET -m state –state NEW,INVALID -j DROP
$IPTABLES -A FORWARD -i $INTERNET -m state –state NEW,INVALID -j DROP


Rechazamos paquetes de conexiones nuevas y rechazamos paquetes de forwarding de conexiones no establecidas. En palabras castas diría que bloqueo todo lo que venga de Internet y no coincida con las reglas anteriores, este es un firewall cuya política por defecto es bloquear todo.

Cuando llega un paquete al firewall, este es analizado por el kernel siguiendo el ORDEN DE LAS REGLAS, es por eso que primero aceptamos las conexión al servidor web y ssh, si un paquete es para alguno de estos servicios entonces el Kernel acepta el paquete y no continua con las demás reglas, pero si el paquete no coincide con las reglas del servidor web y ssh entonces continuara analizándolo con alguna de las ultimas reglas que sencillamente dicen que destruya el paquete.

AÑADIMOS NUESTRO FIREWALL AL ARRANQUE

Guardamos nuestro script en alguna parte de nuestro sistema de archivos, por ejemplo creamos una carpeta en /etc llamada firewall y ahí guardamos nuestros firewalls, por ejemplo nos quedaría así:

/etc/firewall/firewall.sh

Ahora nos aseguramos que nuestro script tenga permisos de ejecución con el comando

chmod +x /etc/firewall/firewall.sh

Ahora debemos añadir nuestro script al arranque, en el caso de Debian Sarge, lo podemos insertar en los archivos de configuración de los adaptadores de red, para que el script se ejecute siempre que se inicien los adaptadores de red. El archivo generalmente es  /etc/network/interfaces
Al archivo le añadimos la siguiente linea:

pre-up /etc/firewall/firewall.sh Esta linea le indica que ejecute el script antes de arrancar el dispositivo de red. El siguiente es un ejemplo de como quedaría el archivo.

labs:/etc/firewall# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
#
        pre-up /etc/firewall/firewall.sh
        address 192.168.1.3
        netmask 255.255.255.0
        gateway 192.168.1.1

auto eth1
iface eth1 inet static
        address 192.168.0.1
        netmask 255.255.255.0

Para usuarios de otras distribuciones como Fedora pueden sencillamente pegar el path completo al firewall en el final del archivo /etc/rc.local, y se ejecutará siempre al arranque después de que todos los servicios inicien.

DNS CACHE

Ahora necesitamos montar un DNS cache, es decir un servidor de solo cache, que almacene las peticiones DNS que le han hecho, para que cuando otro cliente vuelva a realizar la misma petición, el servidor la entrega directamente sin necesidad de buscarla directamente de Internet, esto suena simple, vale… es simple, pero nos puede ahorrar ancho de banda y optimizar nuestra red cuando se trata con bastantes equipos.
Para esto en Debian Sarge sencillamente ejecutamos

apt-get install bind9

y listo… nos aseguramos que se este ejecutando servidor al arranque y con la configuración que trae por defecto nos sirve de DNS cache. Para usuarios de otras distribuciones (joder tíos, ya es hora para que se pasen a Debian ) creo que también funciona con la configuración por defecto, por ejemplo probé con Fedora Core 3 y me funciono, pero con la versión 2 toca hacer algunos ajustes al archivo /etc/named.conf .

CONFIGURACIÓN DE LOS CLIENTES

A los clientes les configuramos como Gateway y servidor DNS la dirección IP de nuestro servidor y vola!, funciona como magia.
Ejemplo de una configuración:

Dirección IP servidor 192.168.0.1

Dirección IP maquina cliente192.168.0.10
Mascara de Red 255.255.255.0
Gateway 192.168.0.1
Servidor DNS 192.168.0.1

Ahora podemos poner nuestra maquina como Gateway… podemos dejar esta maquina sin teclado en algún rincón y os garantizo que no tendrá ningún problema (tal vez solo problemas de hardware, por dejarla descuidada en un rincón ;-) …)

Dudas, comentarios, sugerencias?
Links:
http://www.netfilter.org/
http://bulma.net/body.phtml?nIdNoticia=1522

7 Responses so far

Hi Lord,

Si ven que confianza le tengo a José.
Bueno el caso es que gracias a este pequeña
introducción al mundillo de los proxys, he
salido avante de mis lagunas mentales cuando
montaba proxys, bajo la supervision de José, pero
sin tener idea de que era lo que hacia con el famoso
IPtables y con el «pequeño firewall editado por electrojacs».
Aunque debo admitir que me deje mamar gallo
de Fedora 3 y 4, y por eso pense que no podian tener
DNS, que ingenuo que fui……pero bueno…..quien se
deshace por completo de su ingenuidad?

Le recomiendo tutoriales con HTB, shorewall, y con algunas
de las opciones de configuración que no hemos usado
de squid.

Espero su distro para pasarme a debian.

See Ya

Att: Dileo

Muy útil artículo José. Me ha dado una ide más clara sobre el NATing. Se lo recomiendo a todos los que comienzan. Un artículo sencillo, claro, concreto y amistoso.

Gracias José.

no me puedo conectar a internet si marca i se conecta pero sale un mensaje cuando abro internet explorer y dice que no sirve por el dns dice q no esta que puedo hacer

jhon:
Primero que todo supongo que tienes un servidor GNU/linux y por calamidad familiar, o por amenazas terroristas, tienes un cliente windows!
Entonces, si eso es correcto, primero probaremos en el servidor GNU/linux que el servicio DNS este funcionando, esto lo podemos hacer con el scanner nmap, con el siguiente comando (Cambiar la IP por la que corresponda en tu caso)

nmap 192.168.0.1

Entre las salidas que arroja el scaneo, te deben salir este puerto

53/tcp open domain

Si te arroja ese resultdo, lo más probable es que este funcionando el DNS cache.
Otra forma de confirmar que no puedes navegar por simple problema de DNS, es poner una dirección IP directamente en la barra de direcciones del navegador. Ejemplo, si pones

http://200.93.155.68

Te debe abrir la página de TECSUA, (si es que no estamos caidos :D ), entonces SI es un problema de DNS, pero si tampoco funciona, el problema no de DNS…

Excelente José me aclara mucho el panorama!!

Hola, es justo la ayuda que estaba buscando, gracias me fue muy util!!

Funciona en Based Debian 9! Y si quisiera abrir un puerto para que salga trafico desde un cliente o sobre un protocolo como podria ser.
Gran guia.
Saludos

Leave a comment