En la edición anterior, se explicó las bases de Netfilter/IPTables. En esta segunda entrega, se dará a conocer algo de teoría, tablas adicionales y la puesta en marcha de un servidor de Proxy Transparente.

 

1.1 Iptables-save / Iptables-restore

Ya que es a veces “complicado” recordar las reglas que se anotan (y volverlas a anotar a mano), existen dos scripts adicionales, llamados iptables-save e iptables-restore.

Su misión es volcar las reglas de IPTables, y volverlas a cargar, respectivamente. Su formato es de texto, algo complicado de leer al principio, pero entendible a la larga.

Por ejemplo:

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       icmp --  anywhere             anywhere
DROP       tcp  --  anywhere             anywhere            tcp dpt:www
DROP       tcp  --  192.168.1.1          anywhere            tcp dpt:ssh

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
DROP       icmp --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
DROP       icmp --  anywhere             anywhere
# iptables-save
# Generated by iptables-save v1.2.9 on Thu May 27 11:17:22 2004
*filter
:INPUT ACCEPT [17884:23657771]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [6079:461673]
-A INPUT -p icmp -j DROP
-A INPUT -p tcp -m tcp --dport 80 -j DROP
-A INPUT -s 192.168.1.1 -p tcp -m tcp --dport 22 -j DROP
-A FORWARD -p icmp -j DROP
-A OUTPUT -p icmp -j DROP
COMMIT
# Completed on Thu May 27 11:17:22 2004

Para guardar las reglas, se puede volcar a un archivo de texto.

# iptables-save > reglas.txt

Para restaurar las reglas

# iptables -F
# cat reglas.txt | iptables-restore

Algunas distribuciones, como RedHat y Debian, poseen dentro de sus scripts de inicio algunas ayudas para guardar las reglas.

RedHat

Primero, crear las reglas y luego

# /etc/init.d/iptables save

Debian

Crear primero las reglas, luego crear el directorio /var/lib/iptables

# mkdir /var/lib/iptables

La regla “inactive” es la regla inactiva (generalmente no tiene nada, y por defecto, habilitada para ACCEPT). La regla “ACTIVE” es la regla que se carga al momento del arranque.

# iptables -A INPUT ...
# iptables -A INPUT ...
# /etc/init.d/iptables save active
# iptables -F
# /etc/init.d/iptables save inactive

Otras distribuciones

En caso de otras distribuciones, leer el archivo de arranque (/etc/init.d/iptables o similares)

2. TCP/IP

No voy a ponerme a hablar acerca de TCP/IP (ni de un curso práctico), ya que es ejercicio del lector entender las partes básicas de este protocolo. Sólo haré algunas reseñas necesarias para el buen entendimiento del artículo. 2.1 IP

Para que exista una comunicación entre hosts, es necesario que un paquete contenga tres elementos : dirección de origen, dirección de destino y los datos. Todo paquete de red, además, está escrito de forma MSBF (Most Significant Byte First) o también “Big Endian”.

Un paquete IP contiene una estructura, definida por “cabecera” y “datos”. Este paquete, en lenguaje C, podría escribirse como la siguiente estructura:

#typedef unsigned int uint;
#typedef unsigned char uchar;
struct ip_packet {
    uint version:4; // version, 4 bits
    uint header_len:4; // largo de la cabecera, 4 bits
    uint serve_type:8; // como servir, 8 bits
    uint packet_len:16; // largo del paquete en bytes, 16 bits
    uint ID:16; // identificador del paquete,16 bits
    uint _reserved:1; // reservado, siempre es 0
    uint dont_frag:1; // flag para fragmentacion, 1 bit
    uint more_frags:1; // flag para indicar que hay mas fragmentos, 1 bit
    uint frag_offset:13; // offset que sirve para reconstruccion
                         // de paquetes fragmentados, 13 bits
    uint time_to_live:8; // tiempo de vida del paquete, 8 bits
                         // tambien llamado numero de saltos de router
    uint protocol:8; // protocolo usado, 8 bits
    uint hdr_chksum:16; // suma de comprobacion de la cabecera
    uint IPv4_source:32; // direccion origen de la forma
                         // ABCDEF01 = AB.CD.EF.01
    uint IPv4_dest: 32; // direccion destino
    uchar options[]; // 40 bytes usados para opciones
    uchar data[]; // datos del paquete hasta 64 kbytes
};

Algunos de los campos de la cabecera que realmente interesan son

• Version : número de versión del protocolo IP. Se usa “4” para definir IPv4 y “6” para IPv6.

• ID : indica un numero “mágico” para diferenciar un paquete único de una comunicación (importante dentro de “connection tracking”). Este numero es usando principalmente para la reconstrucción de paquetes fragmentados

• TTL (time to live) : antiguamente era el tiempo en segundos que un paquete podía “vivir” durante su tránsito por la red. Actualmente, se define como la cantidad de saltos máximos permitidos entre routers antes de descartar el paquete.

2.2 ICMP

ICMP (Internet Control Message Protocol) es una de las capas construidas sobre los paquetes básicos IP. Prácticamente todas las máquinas conectadas a Internet utilizan ICMP para mensajes (error y control). Generalmente es usado para diagnosticar conectividad entre dos puntos.

Una cabecera ICMP, puede definirse (en sintaxis C) como

#typedef unsigned char ui8;
#typedef unsigned short int ui16;
struct ICMP_header {
    ui8 type; // tipo de error
    ui8 code; // codigo de error
    ui16 checksum; // checksum
    uchar msg[];
};

Cuando type y code son 0, significa que existe respuesta de eco (pong).

2.3 UDP

UDP (User Datagram Protocol) se usa para las comunicaciones no orientadas a la conexión. Estas comunicaciones se realizan a diferentes destinos sin volver a crear los canales de comunicación (sockets) y es uno de los protocolos sin conexión más comunes.

Una cabecera UDP puede explicarse con la siguiente sintaxis de C

#typedef unsigned char ui8;
#typedef unsigned short int ui16;
struct UDP_header {
    ui16 src_port; // puerto origen
    ui16 dst_port; // puerto destino
    ui16 length; // tamaño del mensaje
    ui16 checksum; // suma comprobación
    uchar data[]; // datos
};

2.4 TCP

TCP (Transmission Control Protocol) es el protocolo de sockets mas usado en Internet. Es totalmente orientado a la conexión, y requiere un canal de comunicación nuevo en cada nueva conexión.

Una cabecera TCP puede ser expresada en C como sigue:

typedef unsigned char ui8;
typedef unsigned short int ui16;
typedef unsigned int ui32;
typedef unsigned int uint;
struct TCP_header {
    ui16 src_port; // puerto de origen
    ui16 dst_port; // puerto de destino
    ui32 seq_num; // numero "magico" de secuencia
    ui32 ack_num; // numero de acuso de recibo (confirmacion)
    uint data_off:4; // offset de datos
    uint ___res:6; // reservado (6 bits)
    uint urg_flag:1; // bandera de estado urgente
    uint ack_flag:1; // bandera de acuso de recibo valido
    uint psh_flag:1; // prioridad
    uint rst_flag:1; // reiniciar la conexion debido a errores
    uint syn_flag:1; // bandera de inicio de apertura de conexion
    uint fin_flag:1; // bandera de conexion finalizada
    ui16 window; // cuantos bytes se esperan recibir
    ui16 checksum; // suma de comprobacion
    ui8 options[]; // opciones
    ui8 __padding[]; // necesitado para alinear data
    uchar data[]; // datos del mensaje
};

Esta cabecera es de tamaño variable.

La cabecera TCP usa el mismo numero de puerto utilizado por UDP. Pero seq_num y ack_num permiten seguirle el rastro a la conexión. Cuando se envía cualquier mensaje por red, se asigna de manera automática un número de secuencia. El receptor responde con un número de acuse de recibo, que es superior a seq_num. Esto permite también que los paquetes de acuse de recibo también pueden transportar datos.

2.5 El punto de vista de IPTables

Una vez explicado como funciona (a nivel de cabeceras) TCP/IP, se vuelve más simple explicar (y entender a la vez) el funcionamiento de IPTables.

Por ejemplo, en el articulo pasado se vio una regla para denegar el acceso al puerto 25

# iptables -A INPUT -i eth1 -p tcp --dport 25 -j DROP

Del punto de vista de la cabecera TCP (la opción -p tcp) indica que dst_port es 25, ignorando los otros valores presentes.

Puede hacerse que el procesado sea mucho mas efectivo, por ejemplo, diciéndole que filtre el tráfico hacia el puerto 25, en la interfaz eth1, siempre que los paquetes vengan marcados con las banderas SYN y ACK al mismo tiempo

# iptables -A INPUT -i eth1 -p tcp --dport 25 --tcp-flags ALL SYN,ACK -j DROP

La opción –tcp-flags requiere dos argumentos. El primero, los flags a examinar, y el segundo, los flags que deben estar en 1. En este caso, IPTables examina todos los flags, pero SYN y ACK deben estar en 1.

Mezclando los conceptos anteriores, mas el artículo pasado , tenemos

• Nivel de Dirección

# iptables [...] -s [direccion] [...]
# iptables [...] -d [direccion] [...]
# iptables [...] -s [direccion] -d [direccion] ...

• Nivel de Protocolo

# iptables [...] -p [protocolo] [acciones especificas] [...]

• Ambos Niveles

# iptables [...] -s [direccion] -p [protocolo] [acciones especificas del protocolo] [...]

3. Más de IPTables

 

3.1 Extensiones

 

LOG

Hemos visto algunas extensiones simples de IPTables, como ACCEPT, DROP y REJECT. Junto con ellas, existen extensiones adicionales, como la posibilidad de “loguear” las coincidencias. Para esto, se usa la extensión LOG, que envía los avisos de coincidencias encontradas hacia el servicio de logging del sistema (syslog).

Por ejemplo,

# iptables -A INPUT -i eth0 -p tcp --dport 25 -j LOG

hará que cualquier conexión al puerto 25 por TCP sea logueada. En el log de sistema, aparecerá lo siguiente (en mi caso):

Feb 22 08:49:36 pumba kernel: IN=eth0 OUT= MAC=00:80:ad:71:fb:26:00:00:86:4d:d3:b2:08:00
SRC=192.168.1.2 DST=192.168.1.1 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=47613 DF PROTO=TCP
SPT=32771 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0

Esto indica que se realizó, al menos, una conexión hacia el puerto 25. Nótese que además se indican las banderas TCP (SYN).

Se puede además agregar una leyenda adicional, generalmente usada para distinguir la regla, o bien para facilitar la lectura de los logs.

# iptables -A INPUT -i eth0 -p tcp --dport 25 -j LOG --log-prefix "Conexion al puerto 25"

MASQUERADE

Otra, ya vista, fue MASQUERADE (o MASQ), usada para nat. Visto en el articulo pasado.

MARK

Esta extensión permite marcar los paquetes, permitiendo alterar el método de enrutamiento, pudiendo ser usado por otros subsistemas para cambiar su comportamiento.

TOS

Existe otra, llamada TOS (type of service). La orientación de esta extensión es proveer la alteración de paquetes (o sea, mangle) de acuerdo al servicio a prestar, priorizando el trafico proveniente de distintas partes. Por ejemplo, minimizar los tiempos de espera (Minimize Delay). Es usada con las cadenas PREROUTING y POSTROUTING.

Por ejemplo, para minimizar la demora en el servicio telnet

# iptables -t mangle -A PREROUTING -p tcp --dport telnet -j TOS --set-tos Minimize-Delay

Los tipos de servicio pueden ser

• Minimizar los tiempos de espera (Minimize-Delay)

• Maximizar el flujo de salida (Maximize-Throughput)

• Maximizar la confiabilidad de la transmisión (Maximize-Reliability)

• Minimizar los costos de la transmisión (Minimize-Cost)

• Servicios normales (Normal-Service)

REDIRECT

Otra extensión es REDIRECT (redirigir). Su misión es alterar los paquetes, de manera de cambiar el puerto de destino, pero sin modificar opciones adicionales, como en el caso de mangle.

Por ejemplo

# iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 3200

desvía los paquetes que llegan al puerto 80 para redirigirlos al puerto 3200. Es útil para Web servers, ya que se puede correr Apache en un puerto superior al 1024 (user ports) y desviar el tráfico desde el puerto 80 al puerto donde realmente está corriendo, de forma transparente.

SNAT y DNAT

Estas extensiones permiten realizar transformaciones de dirección (origen y destino, respectivamente) de los paquetes. DNAT indica que la dirección de destino debe ser modificada. SNAT, la dirección de origen.

Permiten, por ejemplo, redirigir el tráfico hacia un host específico

# iptables -t nat -A POSTROUTING -d 192.168.1.1 -p tcp --dport 80 -j SNAT --to 192.168.1.3

O permitir que el tráfico desde Internet sea enviado a una máquina dentro de la LAN

# iptables -t nat -A PREROUTING -d 10.200.1.18 -j DNAT --to 192.168.1.8

MIRROR

La extensión MIRROR permite intercambiar el origen y el destino y retransmitir el paquete de vuelta al emisor.

Por ejemplo

# iptables -A INPUT -i eth0 -p tcp --dport 3128 -j MIRROR

Extensiones adicionales para coincidencias

De acuerdo al manual de IPTables, las extensiones para coincidencias (matches) pueden ser cargadas de dos maneras :

• por protocolo (-p)

• por coincidencia (-m)

Cada uno de ellos puede cargar módulos adicionales, en el caso que así sea, o soportar extensiones adicionales.

Por ejemplo

# iptables -A INPUT -m tcp -j ACCEPT

es inválido.

Algunas de las extensiones por coincidencia (-m) son

• limit : este módulo permite hacer coincidir paquetes de acuerdo a una tasa limitada de transferencia

• state : indica el estado de la transmisión (ver Inspección de Estado, a continuación)

• ttl : tiempo de vida del paquete

• owner : el propietario (UID, GID, PID) de la transmisión o paquete (solo usado en OUTPUT)

• tos : tipo de servicio

• length : largo del paquete

• mark : marca del paquete

• mac : MAC Address (dirección física de la tarjeta de red)

• unclean (experimental) : verifica la “limpieza” del paquete

Existen otras, pero son demasiado específicas (como ah y esp, usados específicamente con IPSec, otro paquete usado para enrutamiento).

3.2 Inspección de Estado

En el artículo anterior, se comentó acerca de la Inspección del Estado de la conexión. Ésta trata de interpretar todos los paquetes que provienen de una cierta conexión en particular, entendiendo así protocolos de alto nivel como NFS, HTTP y otros. Esta clase de comportamiento solo es posible examinando la cabecera de la información contenida dentro del paquete. Si, por ejemplo, un paquete es parte de una conexión, y calza con alguna de las coincidencias, entonces es procesado.

Las anteriores implementaciones no tenían esta característica. Así, por ejemplo, podía hacerse pasar un paquete como legítimo “a la fuerza”, siendo parte de una conexión arbitraria, como por ejemplo, Portscanning (”escaneo” o barrido de puertos).

Los estados en los cuales puede estar un paquete dentro de una transacción son

• NEW : un paquete que intenta iniciar una conexión

• RELATED : un paquete que es parte de una conexión

• INVALID : un paquete que no es parte de ninguna conexión

• ESTABLISHED : un paquete que, además de ser parte de una conexión, indica que es parte de una conexión establecida exitosa.

• RELATED+REPLY : un paquete que no es parte de alguna conexión existente, pero está relacionada con una. Generalmente asociados a ftp-data y ftp-control.

Por ejemplo, para permitir el FORWARD entre dos interfaces, sólo por conexiones nuevas, ya establecidas y relacionadas:

# iptables -A FORWARD -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

3.3 Cadenas de Usuario

En el articulo pasado dijimos que IPTables tenia 3 tablas (nat, filter y mangle), además de las cadenas INPUT, OUTPUT….

Una de las utilidades mas prácticas es que se puede crear cadenas de usuario (user chains) para coincidencias mas complejas y ciertamente útiles.

Para un ejemplo simple, supongamos que se desea aceptar el tráfico para ssh desde dos hosts y denegar el resto. Se puede lograr con

# iptables -A INPUT -s [direccion1] -p tcp --dport ssh -j ACCEPT
# iptables -A INPUT -s [direccion2] -p tcp --dport ssh -j ACCEPT
# iptables -A INPUT -p tcp --dport 22 -j DROP

Si se necesita una regla adicional, como por ejemplo, el puerto 80, para estos mismos hosts, son 3 comandos más. Así, suma y sigue cuando se requieren puertos adicionales bajo la misma regla.

Para ahorrar tecleos, se puede crear una regla de usuario, con un nombre arbitrario (menos los nombres de las cadenas ya existentes)

# iptables -N control
# iptables -A control -s [direccion1] -j ACCEPT
# iptables -A control -s [direccion2] -j ACCEPT
# iptables -A control -j DROP

Y luego, para agregar a las reglas de entrada

# iptables -A INPUT -p tcp --dport ssh -j control

La opción “-j control” permite que las cadena recién creada se ejecute al momento que la coincidencia ocurra. En este caso, permitir el trafico TCP por el puerto 22, pero la acción a realizar es la cadena de usuario “control”, verificando que se permita el trafico desde dos direcciones únicamente, denegando la conexión desde el resto.

Así, se puede tener reglas mas complejas, para mayor control.

3.4 Acciones por defecto

Las cadenas básicas pueden tener acciones por defecto. Para eso se usa -P. No funciona con las cadenas de usuario.

Por ejemplo

# iptables -P INPUT DROP

indica que todas las conexiones en la cadena INPUT serán descartadas.

4. Firewalling

Suena algo extraña la palabra (eh, primer smiley en el documento).

NOTA : Esta parte del documento es meramente teórica.

Al momento de crear las reglas para Firewalls, existen dos formas de abordar el problema

• Cerrar todo, luego permitir

• Permitir todo, luego cerrar

Si bien ambos métodos son simples de entender, muchas veces es solamente aplicable uno de los dos métodos, ya que es más fácil que el otro.

Por ejemplo, si se desea permitir la conexión por SSH solamente

# iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# iptables -P INPUT DROP

(Cerrar todo, permitir después)

o bien

# iptables -P INPUT ACCEPT
# iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# iptables -A INPUT -p tcp --dport 80 -j DROP
# iptables -A INPUT -p tcp --dport 110 -j DROP
# iptables -A INPUT -p tcp --dport 500 -j DROP

...

(Permitir todo, luego cerrar)

Creo que quedo clara la idea.

4.1 Seguridad

En seguridad informática, cualquier dispositivo que ayude a incrementar la seguridad además minimiza los riesgos que eventualmente pudieran ocurrir (intrusiones, por ejemplo). Y debe cumplir ambos objetivos al mismo tiempo.

El asunto del costo que implica tener un dispositivo de seguridad (tiempo y recursos) se reduce de manera importante al usar soluciones FLOSS, ya que es posible usar un humilde 486DX/16 MB Ram para construir un cortafuego (otra cosa es el funcionamiento óptimo, que se incrementa a medida que aumenta el poder de proceso y almacenamiento), sobre Linux o sobre alguna variante de BSD.

(Esta parte es teoría pura. En la tercera parte, se aborda un script completo para cortafuegos).

Otro problema es “transparencia”. Es decir, las comunicaciones deben realizarse de manera simple, sin que los dispositivos de seguridad intervengan de manera de crear un problema, en vez de resolverlo. Es decir, es innecesario tener un cortafuego que no permita todas las comunicaciones desde la LAN hacia Internet. O bien, que simplemente no funcione. Sale más económico tirar del cable que tener un firewall.

Otro concepto importante es la necesidad de tener un dispositivo de seguridad. En el artículo anterior, se vio que es necesario para:

• Control de Trafico Entrante y Saliente, restringiendo que debe entrar y salir, así como también determinar qué es tráfico innecesario

• Seguridad de Servicios de Red, permitiendo que conexiones no autorizadas tengan acceso a recursos que no corresponden

• Observación del Trafico actual, para determinar el estado del tráfico y para la detección de anomalías de conexión

Cualquier configuración necesaria debe ajustarse a cada una de las necesidades de organizaciones o personas. Además, el nivel de seguridad requerido depende de los activos que se quiera proteger.

5. Puesta en Marcha de un Servidor de Proxy Transparente

Era demasiada cháchara, así que ahora a lo práctico.

Es bastante común que se compartan las conexiones a Internet (una sola conexión para varios clientes). En el artículo anterior, se realizó a través de NAT.

A diferencia de NAT, un Proxy es un puente intermedio, solamente para conexiones HTTP. Es decir, un proxy “habla” en HTTP, que es un protocolo de alto nivel. Se le llama de alto nivel ya que la base del protocolo es en comandos, humanamente entendibles (como GET, por ejemplo). Además, permite tener un respaldo o caché de las páginas más visitadas, reduciendo la cantidad de ancho de banda utilizado para navegar en Web, evitando tráfico innecesario.

Se le llama “transparente” a esta puesta en marcha, ya que los clientes (Linux o Win) no requieren de configuración adicional en los navegadores, siendo transparente la forma de navegar en Internet.

Y lo último, un Proxy permite además crear reglas de control de acceso, para determinar que ver, y en que horarios. Muchas empresas utilizan este método, ya que así determinan que es lo que pueden ver sus trabajadores durante el horario de oficina. La productividad baja un resto cuando se pierde tiempo navegando en páginas pornográficas, por ejemplo. Así, determinar qué ver y cuándo ver, es tarea de un software, en vez de darle este trabajo a los usuarios.

5.1 Como funciona

Un navegador de Internet realiza, por lo general, una conexión hacia el puerto 80 (http) hacia un servidor remoto, enviando una petición HTTP, por ejemplo

GET / HTTP/1.0

y el servidor responde con el código de error respectivo y el recurso pedido. La mayoría de las veces el servidor HTTP informa del cierre de la conexión cuando la transacción esté completa.

Aunque la conversación entre navegador y servidor es mucho mas extensa, prefiero enfocarme en lo necesario.

Cuando existe un servidor Proxy de por medio, el navegador hace la petición hacia él, y luego el Proxy realiza la conexión al servidor indicado. (por ejemplo, cuando se configura el Proxy en el navegador).

Ahora, un Proxy transparente “intercepta” una conexión a un servidor remoto, realiza la petición, la entrega al usuario, sin que el navegador ni el usuario se den cuenta de esta intercepción.

5.2 Materiales

Los materiales son exactamente los mismos que el artículo pasado : una máquina con Linux y otras máquinas con Win o Linux.

Se procede exactamente igual, con la salvedad que no se permite FORWARDING.

Algún servidor Proxy debe estar instalado. Recomiendo usar Squid, es un programa común dentro de las distribuciones de Linux.

5.3 Puesta en Marcha

Suponiendo que Squid esta instalado y corriendo en la máquina Linux (que funcionará de puente entre Internet y la LAN), probar su funcionamiento con alguna otra máquina, conectándose manualmente al Proxy en las opciones del navegador. Por lo general, el puerto de Squid es el 3128. Otros, usan el 8080, dependiendo de la configuración utilizada.

Si funciona, entonces en la máquina Linux de puente:

# iptables -F

para borrar todas las reglas anteriores

Desviar el tráfico desde la interfaz de la LAN que vaya por Web hacia el puerto que está corriendo Squid

# iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 3128

y ya está.

Probar si funciona la conexión a Web, sin configurar manualmente el proxy.

Para permitir el IP Forward de algunas conexiones,

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

Aunque la puesta en marcha es bastante simple, queda además agregar algo de seguridad a la máquina puente (nunca está demás), junto con agregar algunos puertos necesarios (como el de DNS y HTTPS).

Permitir el trafico desde la LAN

# iptables -A INPUT -i eth1 -j ACCEPT
# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Para no recibir tráfico innecesario

# iptables -P INPUT DROP

Para aceptar el tráfico desde la LAN

# iptables -A INPUT -i eth1 -j ACCEPT

IMPORTANTE : la interfaz local también es necesaria

# iptables -A INPUT -i lo -j ACCEPT

Para determinar si el paquete es parte de alguna conexión

# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Y para enmascarar puertos necesarios

# iptables -t nat -A POSTROUTING -p tcp --dport 53 -j MASQUERADE
# iptables -t nat -A POSTROUTING -p tcp --dport 443 -j MASQUERADE
# iptables -t nat -A POSTROUTING -p udp --dport 53 -j MASQUERADE
# iptables -t nat -A POSTROUTING -p udp --dport 443 -j MASQUERADE

Este tipo de puesta en marcha es de tipo “cerrar, luego permitir”.

 

Fuente: Tux.cl