Currently viewing the category: "Redes"

Eliminar reglas iptables puede hacerse cambiando el -A o -I por el -D indicando todos los parámetros iguales como los añadimos, y eso a veces no es fácil o ágil enganchar la combinación exacta.

En estos casos es mejor eliminar reglas iptables por su posición, sin importar el contenido y tener que copiarlo. Para ello tenemos que mostrar reglas iptables en Linux con numeración de posición –line-numbers. Partimos del siguiente ejemplo:

Añadimos una regla en la posición 4, ya que la red cambia de un /24 a un /16. Eso significa que la regla 4 pasará a la posición 5 y succesivamente.

Eliminamos la regla que ya no hace falta, la del /24 ahora en la posición 5.

 

Cuando tenemos que indicar a un compañero que analice ciertas reglas iptables en un firewall Linux, será mejor hacerlo indicando un número, el de su posición. Sino con firewalls de mas de 100 reglas quizás es bastante complicado.

Para mostrar las reglas iptables con la numeración de su posición se hace con el parámetro: –line-numbers

 

Ya hemos visto la gran versatilidad que nos ofrecen las reglas iptables en nuestro firewalls, proxys, servidores, etc. Estos son algunos ejemplos que hemos hablado en este blog.

Cuando tenemos reglas iptables las tenemos que guardar en algún script/archivo para cargarlas de nuevo si reiniciamos el servidor/firewall, ya que no son persistentes a reinicios y deben cargarse de nuevo.

Para ello eso necesario tener un guardar y restaurar de las reglas iptables. Suponemos un firewall simple con control de acceso al servicio SSH. Es un ejemplo sencillo pero igualmente aplicable a grandes firewalls con muchas reglas.

– Primero guardamos las reglas iptables en un archivo, la ubicación a gusto del consumidor.

Ahora cada vez que hagamos cambios de reglas iptables y sea correctas deberemos ejecutar el anterior comando para guardarlas.

– Para restaurar las reglas iptables en el inicio del firewall basta con configurar lo siguiente: vi /etc/rc.local

Por último es habitual hacer cambios de reglas iptables y antes de guardarlas esperamos que todo funcione bien y en caso de pérdida de acceso remoto bastaría con reiniciar el servidor. No obstante si las reglas son correctas y nos olvidamos de guardarlas, en caso de reinicio repentino perderíamos esas reglas que no guardamos.

Por ejemplo, se podría programar un cron nocturno diario para intentar minimizar estos despistes y que se guarden todas las reglas iptables.

Verificamos la ejecución del cron.

 

Ya hemos hablado un poco de firewalls Debian y diferentes modos de enrutamiento, básicamente por IPs de origen y destino, añadiendo reglas con ip rule. Fueron estos artículos:

Ahora vamos a realizar una entrada completa de como balancear tráfico con iptables y reglas de mangle, marcando paquetes y enrutarlos por diferentes tablas de rutas. El esquema de red será el siguiente y ahí podemos ver qué protocolos/servicios vamos a desviar por la WAN 2 (10.0.2.1) en lugar de la conexión por defecto WAN 1 (10.0.1.1).

2WANBalancerIptables

Primero hay que añadir dos tablas de rutas nuevas en el firewall/proxy: vi /etc/iproute/rt_tables

Desactivamos la protección de Spoofing (reverse-path filter), para firewalls no debe estar activo y nos dará problemas con el doble enrutamiento y marcaje de paquetes con iptables en mangle: vi /etc/sysctl.conf

Mas detalles de la protección de spoofing aquí.

Ahora debemos añadir las rutas en las dos tablas nuevas, facilito la configuración del archivo de interfaces pero habrá que añadir las reglas manualmente sino queremos reiniciar el firewall/proxy: vi /etc/network/interfaces

Una vez cargadas las rutas podemos ver como tenemos las tablas main, wan1 y wan2.

A pesar de tener las tablas, no hay ninguna regla específica aún, todo el tráfico tanto del firewall/proxy sale por la WAN 1 a través de la tabla main y el tráfico de la LAN obedece a las misma tabla.

Y ahora empezamos a añadir las reglas de iptables que deseamos para balancear tráfico por la WAN 1 o WAN 2.

Las reglas del chain «Balanceo» se interpretan de este modo, si tiene marca 1 (–set-mark 1) se desviará a la WAN 1, con marca 2 a la WAN 2 Sino hace match en ninguna regla usará la ruta por defecto del firewall, en este caso seria la WAN 1 (10.0.1.1). Destacar que a diferencia de otras tablas de iptables, en mangle si se hace match no finaliza la comprobación a no ser que se lo indiquemos, por eso después de cada regla se verifica si está marcado el paquete y salimos.

  • Las dos primeras reglas de Balanceo si ya contienen los paquetes alguna marca, 1 o 2 salimos y no comprobamos nada mas.
  • Reglas 3 y 4, marcamos el tráfico que se genera en la eth0 para que salga por la eth0, para tener gestión remota por SSH por ambas conexiones WAN.
  • Reglas 5 y 6, marcamos el tráfico qu ese genera en la eth1 para que salga por la eth1, para tener gestión remota por SSH por ambas conexiones WAN.
  • Reglas 7 y 8, el tráfico con origen del servidor interno 192.168.1.100 debe salir siempre por la WAN 2, cualquier puerto/servicio/protocolo.
  • Reglas 9 y 10, el tráfico del servidor OpenVPN se desvía por la WAN 2, dedicamos esa conexión al tráfico de VPN.
  • Reglas 11 y 12, el tráfico HTTPS de la videocámara 192.168.1.250 se desvía por la WAN 2.
  • Reglas 13 y 14, el tráfico HTTP de toda la LAN sale por la WAN 1.
  • Reglas 15 y 16, cualquier otro tipo de tráfico por puerto/servicio/protocolo saldrá por la WAN 1.

Una puntualización, de la regla 3 a la 6 se trata de habilitar la gestión remota, es exactamente el mismo objetivo que se explico en el artículo, mantener gestión remota al firewall Debian por las 2 conexiones WAN indistintamente. Únicamente que se trata de otro método para permitir la gestión remota por 2 conexiones WAN.

Y este el el resultado de las reglas iptables cargadas en la tabla mangle.

Y aquí las reglas de ip rule que indican cada tipo de marca (1 o 2) a qué tabla de rutas se envía.

Todo esto son las configuraciones, luego hará falta añadirlo a un script de boot, en el interfaces de red o donde queramos. También para los mas valientes y habilidosos podemos realizar un pequeño script que detecte caídas de las conexiones WAN, en caso de caída de alguna de ellas desviar todo el tráfico por la otra.

Por ejemplo, en caso de caída de la WAN 1, cambiar la ruta por defecto de la tabla main y wan1. Una vez recuperada la conexión se restablecen los valores anteriores y listo.

En algunos casos donde tengamos un Linux como firewall de una red, puede tener una cantidad enorme de reglas iptables las cuales puede complicar un poco su interpretación. También puede que por cuestión de orden nos interese añadir comentarios, igual como en la programación de un script bash. Veamos algunos ejemplos.

– Comentario con iptables indicando el Inicio y Fin de ciertos bloques de reglas, por ejemplo control de SSH. Es importante remarcar que la primera y última regla que usamos para loso comentarios no tengan «target» con el «-j«, de este modo no se realiza ninguna acción y se sigue evaluando el resto de reglas iptables.

– Añadir comentarios en las propias reglas iptables que realizan acciones.

 

Si tenemos detectado un abusón de ancho de banda de red en nuestro firewall, podemos bloquearlo con iptables por su IP de origen. Pero hay si su PC está con DHCP y otro día pasa a tener otra IP, ese bloqueo dejará de funcionar y quizás estaremos bloqueando a un usuario que si es legítimo.

En este caso puede ser útil bloquear el acceso al puerto 80 o directamente a cualquier tipo de tráfico a la espera que el infractor venga a preguntarnos porqué no tiene Internet…  🙂

Primero buscamos su MAC en la tabla ARP.

Un par de ejemplos, bloquear el tráfico HTTP y HTTPS.

Bloqueamos absolutamente todo el tráfico de esa MAC.

 

Cuando tenemos un inventario de nuestro parque informático con las MACs de las tarjetas de red de cada equipo, resulta que necesitamos saber su IP para conectarnos al portátil para realizar unas gestiones cualquiera, pero desconocemos la IP ya que se conecta por Wifi y con DHCP.

Para este caso podemos consultar la tabla ARP de nuestro firewall donde tendremos una relación de IP junto a su MAC correspondiente.

 

Cuando hay dos conexiones WAN de salida en un firewall/proxy Debian, sin hacer mucha cosa no vamos a tener gestión remota (p.e: por SSH) por las 2 conexiones, únicamente la tendremos por la conexión que es la ruta por defecto del propio firewall. Veámoslo con un ejemplo con el siguiente esquema de red.

2WAN_LookupTable

Muy importante para entenderlo, leeros este artículo, se utiliza la misma relación de IPs, red y tablas de rutas alternativas. Doble enrutamiento en Debian con 2 tablas de rutas y desviar el tráfico según la IP de origen por otra salida WAN.

Es fácil, los paquetes entrando por eth1 (WAN 2) del firewall son retornados por el default gateway del mismo, por la eth0 (WAN 1) perdiéndose la conexión.

Si el default gateway del fireall/proxy fuera la WAN 2 (10.0.2.1) el efecto seria exactamente el mismo pero a la inversa, solo habría gestión remota desde la WAN 2 y no la WAN 1.

Y aquí la solución, añadir dos reglas con ip rule para indicar que el tráfico generado en cada una de las interfaces de salida WAN sean devueltos por la correspondiente.

Y ahora ya tenemos acceso remoto desde las 2 conexiones WAN indistintamente.

 

Anteriormente vimos como se podía hacer doble enrutamiento en Debian con 2 tablas de rutas y desviar el tráfico según la IP de origen por otra salida WAN.

Es muy importante leer antes la entrada anterior ya que el esquema de red y definición de tablas de rutas es exactamente el mismo.

En el otro ejemplo vimos como enrutar una IP de origen por otra tabla de enrutamiento, tal qué:

Pero el ejemplo que nos ocupa ahora es hacer lo contrario, desviar una IP de destino, quizás para dedicar una conexión ADSL al tráfico con destino a nuestro servidor CRM corporativo, VoIP, e-mail, etc.

Y ahora podemos hacer las verificaciones y ver como sale por la WAN 1 (10.0.1.1) o por la WAN 2 (10.0.2.1) dependiendo de la IP de destino.

 

Con un entorno Debian podemos controlar casi el mundo, pero hoy vamos a explicar como tener un firewall/proxy Debian con 2 salidas WAN (ADSL, FTTH, etc…) y desviar el tráfico de un equipo interno de la LAN detrás del firewall por la segunda salida WAN de forma prioritaria. Dejando la primera salida WAN para todo el tráfico sobrante.

El esquema de red es el siguiente:

2WAN_LookupTable

Primero hay que añadir dos tablas de rutas nuevas: vi /etc/iproute/rt_tables

Ahora debemos añadir las rutas en las dos tablas nuevas, facilito la configuración del archivo de interfaces pero habrá que añadir las reglas manualmente sino queremos reiniciar el firewall/proxy: vi /etc/network/interfaces

Una vez cargadas las rutas podemos ver como tenemos las tablas main, wan1 y wan2.

A pesar de tener las tablas, no hay ninguna regla específica aún, todo el tráfico tanto del firewall/proxy sale por la WAN 1 a través de la tabla main y el tráfico de la LAN obedece a las misma tabla.

Veamos como añadir una IP de origen de la LAN, forzando su salida por la WAN 2.

Podemos hacer un traceroute desde el servidor 192.168.1.100 y veremos como sale por la WAN 2 (10.0.2.1).

Por otro lado desde cualquier otra IP de la misma LAN saldrá por la WAN 1 (10.0.1.1).

De este modo podemos desviar fácilmente toda una IP por otras conexiones alternativas a la principal.