Esta es una pregunta canónica propuesta sobre la comprensión y la depuración del firewall del software en sistemas Linux.

En respuesta a la respuesta de EEAA y al comentario de @ Shog de que necesitamos un Q&A canónico adecuado para cerrar preguntas comunes relativamente simples sobre iptables.

¿Cuál es un método estructurado para depurar problemas con el firewall de software de Linux, el marco de filtrado de paquetes de netfilter , comúnmente conocido por la interfaz de usuario iptables ?

¿Cuáles son los escollos comunes, las preguntas recurrentes y las cosas simples o un poco más oscuras para verificar que un administrador de firewall ocasional podría pasar por alto o de lo contrario beneficiarse de saber?

Incluso cuando utiliza herramientas como UFW , FirewallD (alias firewall-cmd), Shorewall o similares, puede beneficiarse de mirar debajo del capó sin la capa de abstracción que ofrecen esas herramientas.

Esta pregunta no pretende ser una guía práctica para construir firewalls: consulte la documentación del producto para eso y, por ejemplo, contribuya con recetas a iptables Trips & Tricks o busque en las preguntas etiquetadas de iptables ufw firewalld firewall-cmd las puntuaciones existentes frecuentes y bien consideradas de alto puntaje Preguntas y respuestas

En general:

Ver y modificar la configuración del firewall requiere privilegios de administrador ( root) al igual que abrir servicios en el rango de número de puerto restringido. Eso significa que debe iniciar sesión como rooto utilizar alternativamente sudopara ejecutar el comando como root. Intentaré marcar tales comandos con el opcional [sudo].

Contenido:

1. El orden importa o la diferencia entre -Iy-A
2. Mostrar la configuración actual del firewall
3. Interpretando la salida de iptables -L -v -n
4. Conoce tu entorno
5. Las cadenas INPUT y FORWARD
6. Módulos del núcleo

1. El orden importa o la diferencia entre -Iy-A

Lo que debe recordar es que las reglas del firewall se verifican en el orden en que se enumeran. El núcleo dejará de procesar la cadena cuando se active una regla que permitirá o deshabilitará un paquete o conexión.

Creo que el error más común para los administradores de firewall novatos es que siguen las instrucciones correctas para abrir un nuevo puerto, como el siguiente:

[sudo] iptables -A INPUT -i eth0 -p tcp --dport 8080 -j ACCEPT

y luego descubre que no tendrá efecto.

La razón de esto es que la -Aopción agrega esa nueva regla, después de todas las reglas existentes y dado que muy a menudo la regla final en el firewall existente era una que bloquea todo el tráfico que no está explícitamente permitido, lo que resulta en

...
7    2515K  327M REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited
8        0  0    ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:8080

O equivalente en iptables-save:

...
iptables -A INPUT  -j REJECT
iptables -A INPUT  -p tcp --dport 8080 -j ACCEPT

y nunca se alcanzará la nueva regla que abre el puerto TCP 8080. (como lo demuestran los contadores que permanecen obstinadamente en 0 paquetes y cero bytes).

Al insertar la regla con -Ila nueva regla habría sido la primera en la cadena y funcionará.

2. Visualice la configuración actual del firewall

Mi recomendación para el administrador del firewall es mirar la configuración real que está ejecutando el kernel de Linux, en lugar de tratar de diagnosticar problemas de firewall con herramientas fáciles de usar. A menudo, una vez que comprende los problemas subyacentes, puede resolverlos fácilmente en un asunto respaldado por esas herramientas.

El comando [sudo] iptables -L -v -nes tu amigo (aunque a algunas personas les gusta iptables-savemás). A menudo, cuando se discuten configuraciones, es útil usar la --line-numbersopción también para numerar líneas. Refiriéndose a la regla #X hace que discutirlos sea algo más fácil.
Nota: las reglas de NAT están incluidos en la iptables-savesalida, pero que muestran por separado mediante la adición de la -t natopción es decir, [sudo] iptables -L -v -n -t nat --line-numbers.

Ejecutar el comando varias veces y verificar el incremento de contadores puede ser una herramienta útil para ver si una nueva regla realmente se activa.

[root@host ~]# iptables -L -v -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     784K   65M fail2ban-SSH  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22
2    2789K  866M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
3       15  1384 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
4    44295 2346K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
5    40120 2370K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:80
6    16409  688K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:443
7    2515K  327M REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT 25 packets, 1634 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain fail2ban-SSH (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 REJECT     all  --  *      *       117.239.37.150       0.0.0.0/0           reject-with icmp-port-unreachable
2        4   412 REJECT     all  --  *      *       117.253.208.237      0.0.0.0/0           reject-with icmp-port-unreachable

Alternativamente, la salida de iptables-saveda un script que puede regenerar la configuración de firewall anterior:

[root@host ~]# iptables-save
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [441:59938]
:fail2ban-SSH - [0:0]
-A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A fail2ban-SSH -s 117.239.37.150/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-SSH -s 117.253.208.237/32 -j REJECT --reject-with icmp-port-unreachable
COMMIT

Es una cuestión de preferencia lo que encontrará más fácil de entender.

3. Interpretar la salida de iptables -L -v -n

La política establece la acción predeterminada que usa la cadena cuando no coincide ninguna regla explícita. En la INPUTcadena configurada para ACEPTAR todo el tráfico.

La primera regla en la cadena INPUT es inmediatamente interesante, envía todo el tráfico (fuente 0.0.0.0/0 y destino 0.0.0.0/0) destinado al puerto TCP 22 ( tcp dpt:22) el puerto predeterminado para SSH a un destino personalizado ( fail2ban-SSH) . Como su nombre lo indica, fail2ban mantiene esta regla (un producto de seguridad que, entre otras cosas, analiza los archivos de registro del sistema para detectar posibles abusos y bloquea la dirección IP del abusador).

Esa regla habría sido creada por una línea de comandos de iptables similar ao iptables -I INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSHse encuentra en la salida de iptables-save as -A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH. A menudo encontrará cualquiera de esas anotaciones en la documentación.

Los contadores indican que esta regla ha coincidido con 784'000 paquetes y 65 megabytes de datos.

El tráfico que coincide con esta primera regla es procesado por la fail2ban-SSHcadena que, como una cadena no estándar, se enumera debajo de la cadena de SALIDA.

Esa cadena consta de dos reglas, una para cada abusador (dirección IP de origen 117.253.221.166 o 58.218.211.166) que está bloqueada (con a reject-with icm-port-unreachable).

 -A fail2ban-SSH -s 117.253.221.166/32 -j REJECT --reject-with icmp-port-unreachable
 -A fail2ban-SSH -s 58.218.211.166/32 -j REJECT --reject-with icmp-port-unreachable

Los paquetes SSH que no son de esos hosts bloqueados aún no están permitidos ni deshabilitados, y ahora que la cadena personalizada se haya completado se verificará con la segunda regla en la cadena INPUT.

Todos los paquetes que no estaban destinados al puerto 22 pasaron la primera regla en la cadena INPUT y también serán evaluados en la regla INPUT # 2.

La regla de ENTRADA número 2 hace que este sea un firewall con estado , que rastrea las conexiones. Esto tiene algunas ventajas, solo los paquetes para las nuevas conexiones deben verificarse con el conjunto completo de reglas, pero una vez permitidos, se aceptan paquetes adicionales que pertenecen a una conexión establecida o relacionada sin una verificación adicional.

La regla de entrada n. ° 2 coincide con todas las conexiones abiertas y relacionadas y los paquetes que coinciden con esa regla no tendrán que evaluarse más.

Nota: los cambios de reglas en la configuración de un firewall con estado solo afectarán las conexiones nuevas, no las conexiones establecidas.

En contraste, un filtro de paquete simple prueba cada paquete contra el conjunto completo de reglas, sin rastrear el estado de la conexión. En dicho firewall no se utilizarían palabras clave de estado .

La regla INPUT # 3 es bastante aburrida, todo el tráfico que se conecta a la lointerfaz loopback ( o 127.0.0.1) está permitido.

Las reglas INPUT 4, 5 y 6 se usan para abrir los puertos TCP 22, 80 y 443 (los puertos predeterminados para SSH, HTTP y HTTPS resp.) Al otorgar acceso a NUEVAS conexiones (las conexiones existentes ya están permitidas por la regla INPUT 2).

En un firewall sin estado, esas reglas aparecerían sin los atributos de estado:

4    44295 2346K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
5    40120 2370K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
6    16409  688K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0

o

-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

La regla INPUT final, # 7 es una regla que bloquea todo el tráfico al que NO se le otorgó acceso en las reglas INPUT 1-7. Una convención bastante común: todo lo que no está permitido se niega. En teoría, esta regla podría haberse omitido al establecer la POLÍTICA predeterminada en RECHAZAR.

Siempre investiga toda la cadena.

4. Conoce tu entorno

4.1. La configuración en un firewall de software no afectará la configuración de seguridad mantenida en otra parte de la red, es decir, a pesar de abrir un servicio de red con iptableslas listas de control de acceso no modificadas en los enrutadores u otros firewalls en su red, aún puede bloquear el tráfico ...

4.2. Cuando no hay ningún servicio escuchando, no podrá conectarse y obtener un error de conexión rechazada , independientemente de la configuración del firewall. Por lo tanto:

• Confirme que un servicio está escuchando (en la interfaz de red / dirección IP correcta) y utilizando los números de puerto que espera [sudo] netstat -plnuto utiliza alternativamente ss -tnlp.
• Si aún no se supone que sus servicios se estén ejecutando, emule un escucha simple con, por ejemplo, netcat: [sudo] nc -l -p 123o openssl s_server -accept 1234 [options] si necesita un escucha TLS / SSL (verifique las man s_serveropciones).
• Verifique que puede conectarse desde el propio servidor, es decir, telnet <IP of Server> 123o echo "Hello" | nc <IP of Server> 123cuando pruebe el servicio seguro TLS / SSL openssl s_client -connect <IP of Server>:1234, antes de intentar lo mismo desde un host remoto.

4.3. Comprenda los protocolos utilizados por sus servicios. No puede habilitar / deshabilitar adecuadamente los servicios que no comprende suficientemente. Por ejemplo:

• ¿Se utiliza TCP o UDP o ambos (como con DNS)?
• ¿utiliza el servicio un puerto predeterminado fijo (por ejemplo, algo como el puerto TCP 80 para un servidor web)?
• alternativamente, ¿se elige un número de puerto dinámico que puede variar (es decir, servicios RPC como NFS clásico que se registra con Portmap)?
• FTP infame incluso utiliza dos puertos , un número de puerto fijo y uno dinámico cuando se configura para usar el modo pasivo ...
• Las descripciones de servicio, puerto y protocolo /etc/servicesno coinciden necesariamente con el servicio real que utiliza un puerto.

4.4. El filtro de paquetes del núcleo no es lo único que puede restringir la conectividad de red:

• SELinux también podría estar restringiendo los servicios de red. getenforceconfirmará si SELinux se está ejecutando.
• Aunque los TCP Wrappers se vuelven un poco oscuros siguen siendo una herramienta poderosa para hacer cumplir la seguridad de la red. Consulte con ldd /path/to/service |grep libwrapy los /hosts.[allow|deny]archivos de control.

5. INPUTo FORWARDcadenas

El concepto de cadenas se explica más a fondo aquí, pero en resumen:

La INPUTcadena es donde abre y / o cierra puertos de red para servicios que se ejecutan localmente, en el host donde emite los comandos de iptables.

La FORWARDcadena es donde aplica reglas para filtrar el tráfico que el núcleo reenvía a otros sistemas, sistemas reales, pero también contenedores Docker y servidores de Servidores invitados virtuales cuando su máquina Linux actúa como un puente, enrutador, hipervisor y / o dirección de red traducción y reenvío de puertos.

Una idea errónea común es que, dado que un contenedor Docker o un invitado KVM se ejecuta localmente, las reglas de filtro que se aplican deben estar en la cadena INPUT, pero ese no suele ser el caso.

6. Módulos del núcleo

Dado que el filtro de paquetes se ejecuta dentro del kernel de Linux, también se puede compilar como módulo dinámico, en realidad, múltiples módulos. La mayoría de las distribuciones incluyen netfilter como módulos y los módulos de netfilter necesarios se cargarán en el kernel según sea necesario, pero para algunos módulos un administrador de firewall deberá asegurarse manualmente de que se carguen. Esto se refiere principalmente a los módulos de seguimiento de conexión, como los nf_conntrack_ftpque se pueden cargar insmod.

Los módulos cargados actualmente en el kernel en ejecución se pueden mostrar con lsmod.

El método para garantizar que los módulos se carguen de forma persistente en los reinicios depende de la distribución de Linux.

Problemas comunes con diferentes protocolos

DNS: DNS utiliza el puerto 53 UDP de manera predeterminada, pero los mensajes que no caben en un solo datagrama UDP se transmitirán utilizando TCP en su lugar (generalmente transferencias de zona y similares) que requieren que el puerto 53 TCP también se abra cuando ejecuta un servidor de nombres .

Correo electrónico: muchos ISP de los consumidores bloquean el tráfico SMTP (o al menos el puerto predeterminado TCP 25), lo que hace imposible recibir o enviar correos electrónicos directamente y sus clientes se ven obligados a usar el relé SMTP del ISP para todo el correo saliente y a veces también para el correo entrante. . Se relaciona con §1.1.

FTP: FTP es un protocolo extraño en el sentido de que se utilizan dos conexiones. La primera es la conexión de control, por defecto un servidor FTP escuchará en el puerto TCP 21 para eso. La conexión de control se utiliza para la autenticación y la emisión de comandos. Las transferencias de archivos reales y cosas como la salida de un listado de directorio pasan por una segunda conexión TCP, la conexión de DATOS. En FTP activo, esa conexión de DATOS se iniciaría desde el servidor FTP desde el puerto TCP 20 y se conectaría al cliente FTP. El FTP activo no funciona muy bien con usuarios detrás de firewalls y puertas de enlace NAT, por lo que ha caído en desuso. La mayoría de los servidores FTP admiten FTP pasivo en su lugar. Con FTP pasivo, el servidor FTP abre un escucha para la conexión de DATOS en un segundo puerto, al que el cliente FTP puede conectarse. El problema para un firewall es que el puerto DATA puede ser cualquier puerto no privilegiado disponible entre 1024-65536.

En un firewall sin estado que generalmente se resuelve restringiendo la cantidad de puertos pasivos que el servidor FTP puede asignar y luego abriendo explícitamente esos puertos. es decir

iptables -A INPUT -p tcp --match multiport --dports 21000:21050 -j ACCEPT

En un firewall con estado, no es necesario abrir explícitamente el puerto DATA, el módulo auxiliar netfilter reconocerá el puerto dinámico que se asigna y abrirá dinámicamente ese puerto para el cliente correcto marcando la conexión DATA RELATEDdespués de lo cual coincidirá con la regla genérica :

  iptables -I INPUT -p tcp -m state ESTABLISHED,RELATED -j ACCEPT

Esto requiere que se cargue el módulo de kernel correcto , en el caso de FTP, ejecutando manualmente, por ejemplo insmod nf_conntrack_ftp, lo que hace que persistente dependa de reiniciar depende de la distribución.

Nota: El módulo de seguimiento de la conexión FTP fallará cuando se use FTP con SSL, ya que la conexión de control estará encriptada y el nf_conntrack_ftp ya no podrá leer la respuesta PASV.

NFS y servicios RPC similares : el problema con los servicios RPC es que, por diseño, no utilizan un puerto fijo específico. Pueden elegir cualquier puerto disponible al azar, que luego se registrará con el demonio RPC Portmap. Un cliente que intente conectarse consultará el demonio Portmap y luego se conectará directamente al puerto correcto. Eso resolvió el problema de quedarse sin puertos reservados ...

Desde la perspectiva del cortafuegos, es necesario abrir el puerto TCP / UDP 111 y el puerto real que el servicio RPC está utilizando actualmente. El problema de abrir un puerto aleatorio de este tipo en un firewall generalmente se resuelve restringiendo el servicio RPC, como el servidor NFS, para usar un puerto fijo predefinido.

Iptables / Firewall "introducción"

Un firewall es básicamente un filtro de red basado en políticas. Los firewalls de Linux están construidos alrededor de Netfilter; El marco de procesamiento de paquetes de red del núcleo que está formado por varios módulos del núcleo que realizan tareas específicas:

1. El módulo FILTRO (siempre cargado por defecto) nos permite ACEPTAR o BAJAR principalmente paquetes IP basados ​​en ciertos criterios coincidentes.
2. El conjunto de módulos NAT nos permite realizar traducciones de direcciones de red (SNAT, DNAT, MASQUERADE).
3. El módulo MANGLE nos permite alterar ciertos campos de paquetes IP (TOS, TTL).

Los usuarios configuran el marco Netfilter para satisfacer sus necesidades de firewall utilizando iptables desde la línea de comandos. Con iptables definimos reglas que le indican al núcleo qué hacer con los paquetes IP cuando llegan, pasan o salen de nuestra caja de Linux. Cada proceso principal de Netfilter está representado por una TABLA (FILTRO, NAT, MANGLE) en la jerga de iptables. Tienen varios puntos de enlace específicos en el mapa de flujo de paquetes de red donde el núcleo los invoca para realizar sus tareas. Ciertas secuencias de llamadas TABLE ubicadas específicamente se denominan genéricamente CADENAS integradas que reciben los nombres de PREROUTING, INPUT, FORWARD, OUTPUT y POSTROUTING. Es fácil recordar si asociamos una TABLA con un "tipo de proceso" y una CADENA con la "ubicación" en el mapa de flujo de paquetes de red donde se invocan instancias de esos procesos.

Dado que un paquete IP se recibe en una interfaz de red o se crea mediante un proceso local, hasta que finalmente se entregue o descarte, el motor Netfilter probará secuencialmente y aplicará las reglas contenidas en el mapa de flujo de paquetes de red. En cada bloque identificado por un par TABLE @ CHAIN, el usuario puede agregar una o más de estas reglas consecutivas que contienen un criterio de coincidencia de paquetes IP y el curso de acción correspondiente. Hay acciones (es decir, ACEPTAR, DROP, etc.) que pueden realizarse en más de una TABLA y otras acciones (es decir, SNAT, DNAT, etc.) que son específicas de la TABLA.

es decir, cuando un paquete IP llega desde una interfaz de red, primero lo procesa la cadena PREROUTING invocando las reglas definidas por el usuario de la tabla MANGLE, si las hay. Si no hay reglas que coincidan con el paquete actual, se aplicará el curso de acción predeterminado o "política" correspondiente a MANGLE @ PREROUTING. En este punto, si el paquete no se descartó, el proceso continuará invocando las reglas de la tabla NAT en la cadena PREROUTING (ver el mapa) y así sucesivamente. Para facilitar el diseño de reglas, los usuarios también pueden crear sus propias cadenas personalizadas y "saltar" a ellas desde diferentes puntos del mapa como lo deseen.

Si bien las cadenas integradas pueden tener políticas definidas por el usuario de paquetes ACEPTAR o DROP, las cadenas definidas por el usuario tienen siempre una política predeterminada de CAMBIO por defecto para que el llamante continúe el proceso.

Comandos iptables

Los comandos principales de iptables llenan el mapa de flujo de paquetes de red con las reglas de procesamiento requeridas.

La regla genérica de iptables se puede escribir como:

# iptables <table> <Add/Insert/Delete> <CHAIN> <PKT_MATCHING_CRITERIA> <ACTION>

Se podría leer como:

Netfilter (kernel module) please <Add/Insert/Delete> this rule for <table> at <CHAIN> where packets matching <PKT_MATCHING_CRITERIA> have to be <ACTION>ed

<table>
  -t filter       (the filter table is assumed when omitted)
  -t nat
  -t mangle 

<Add/Insert/Delete>
  -A              (append rule at the end of the chain list)
  -I              (insert rule at the begining of the chain list)
  -D              (Delete rule)

<CHAIN>
  PREROUTING
  INPUT
  FORWARD
  OUTPUT
  POSTROUTING
  USER_DEFINED_CHAIN

<PKT_MATCHING_CRITERIA>
ISO Level-2 matching:
  -i [!] <if_name>    or --in-interface [!] <if_name>
          (OUTPUT and POSTROUTING chains cannot match on input  interfaces)
  -o [!] <if_name>    or --out-interface [!] <if_name>
          (INPUT  and PREROUTING  chains cannot match on output interfaces) 
    -mac-source [!] <xx-xx-xx-xx-xx-xx>
            (OUTPUT and POSTROUTING chains cannot match on input  interfaces)

ISO Level-3 matching:
  -s [!] <src_ip>     or --src [!] <src_ip>   or --source [!] <src_ip>
  -d [!] <dst_ip>     or --src [!] <dst_ip>   or --destination [!] <dst_ip>

ISO Level-4 matching:
  -p [!] <prot_name>    or --protocol [!] <prot_name>  (udp|tcp|icmp)

  Also available when ICMP protocol is defined
  --icmp-type [!] <icmp_type>

  Also available when UDP protocol is defined
  --source-port [!] <udp_src_port>      or --sport [!] <udp_src_port>
  --destination-port [!] <udp_dst_port> or --dport [!] <udp_dst_port>

  Also available when TCP protocol is defined
  --source-port [!] <tcp_src_port>      or --sport [!] <tcp_src_port>
  --destination-port [!] <tcp_dst_port> or --dport [!] <tcp_dst_port>
  --tcp-flags [!] <tcp_flags>   (SYN|ACK|FIN|RST|URG|PSH|ALL|NONE)
    --syn
  --tcp-option [!] <tcp_option#>

  --state [!] <state>
  -m <match> [options]

    note: [!] = negation operator

<ACTION>                (also called TARGET)
  -j ACCEPT             (process continues with rules of the next table in map)
  -j DROP               (discard current packet)
  -j REJECT             (discard current packet with ICMP notification)
      option:
      --reject-with <reject_type>
  -j USER_DEFINED_CHAIN   (start traversing USER_DEFINED_CHAIN rules)
  -j RETURN               (return from USER_DEFINED_CHAIN)
  -j LOG                  (log to syslog, then process next rule in table)
      options:
      --log-level <level>
      --log-prefix <prefix>
      --log-tcp-sequence
      --log-tcp-options
      --log-ip-options
      --log-uid

nat table specific
  -j SNAT             (rewrite the source IP address of the packet)
      option:
      --to <ip_address>
  -j SAME             (idem SNAT; used when more than one source address)
      options:
      --nodst 
      --to <a1-a2>
  -j MASQUERADE       (idem SNAT; used when the replace IP is dynamic)
  -j DNAT             (rewrite the destination IP address of the packet)
      option:
      --to <ip_address>
  -j REDIRECT         (rewrite dst IP to 127.0.0.1, PREROUTING and OUTPUT only)
      option:
      –-to-port <port#>

mangle table specific
  -j ROUTE            (explicitly route packets, valid at PREROUTING)
      options:
      --iface <iface_name>
      --ifindex <iface_idx>
  -j MARK             (set Netfilter mark values)
      options:
      --set-mark <value>
      --and-mark <value>
      --or-mark <value> 
  -j TOS              (set the IP header Type of Service field) 
      option:
      --set-tos <value>
  -j DSCP             (set the IP header Differentiated Services Field)
      options:
      --set-dscp <value>
      --set-dscp-class <class>
  -j TTL              (set the IP header Time To Live field)
      options:
      --ttl-set <value>
      --ttl-dec <value>
      --ttl-inc <value>

Los comandos auxiliares de iptables completan el escenario estableciendo condiciones predeterminadas, enumerando reglas, reglas de vaciado, etc.

#iptables -t <table> -L             
       (Lists the <table> rules in all chains)
#iptables -t <table> -L <CHAIN>     
       (Lists the <table> rules in <CHAIN>)

#iptables -t <table> -N <CHAIN>     
       (Creates a user-defined <CHAIN> for holding <table> rules)
#iptables -t <table> -E <CHAIN> <NEWCHAIN>  
       (Renames <CHAIN> that holds <table> rules to <NEWCHAIN>)

#iptables -t <table> -X   
       (Deletes all user-defined chains created for holding <table> rules)
#iptables -t <table> -X <CHAIN>
       (Deletes user-defined <CHAIN> created for holding <table> rules)

#iptables -t <table> -P <CHAIN> <ACTION>     where <ACTION> = ACCEPT|DROP
       (Sets the default policy of <table> rules at <CHAIN> to <ACTION>)

#iptables -t <table> -F             
       (Flushes (deletes) all <table> rules in all chains)
#iptables -t <table> -F <CHAIN>
       (Flushes (deletes) all <table> rules in <CHAIN>)

#iptables -t <table> -R <CHAIN> <INDEX> <NEWRULE>
       (Replaces <table> rule at position <INDEX> in <CHAIN> with <NEWRULE>

Iptables carga nuestros comandos en el motor de Netfilter en tiempo de ejecución, Netfilter aplica inmediatamente las reglas y configuraciones cargadas, pero no son persistentes. Después de reiniciar, se perderán todas las reglas y configuraciones de Netfilter cargadas previamente. Por esta razón, existen utilidades de iptables que permiten guardar el conjunto de reglas actualmente activo en un archivo y volver a cargarlo más tarde.

#iptables-save > fileName
      (Save the currently active Netfilter ruleset to fileName)

#iptables-restore < fileName
      (Restore Netfilter ruleset to the one saved in fileName)

Resumen de Iptables

Netfilter es un marco extremadamente flexible y potente, pero hay un precio que pagar por él; Iptables es complejo. Desde el punto de vista del usuario, ciertos términos como TABLE, CHAIN, TARGET no coinciden realmente bien con el concepto que representan y al principio no tienen mucho sentido. El tema es largo, los comandos parecen tener una lista interminable de parámetros. Para empeorar las cosas, no hay un solo libro que realmente domine Iptables. En su mayoría se dividen en dos categorías: "libro de recetas" o "libro de páginas de manual". Creo que esta introducción le ofrece una instantánea del panorama de Netfilter / Iptables más la dosis necesaria de material de página de manual previamente digerido. Si es nuevo en iptables, después de leer estos párrafos un par de veces estará listo para leer ejemplos de iptables. Con algo de práctica, pronto se encontrará escribiendo sus propias reglas.

Cortafuegos

Un firewall está diseñado principalmente para permitir o denegar dinámicamente el tráfico de red en función de un conjunto de reglas. En este punto, es fácil entender por qué el marco Linux Netfilter / Iptables es perfecto para la construcción de firewall. Mirando el mapa de flujo de paquetes de red encontramos dos puntos particularmente interesantes en la tabla FILTER en las cadenas INPUT y FORWARD; Podemos decidir allí sobre la dirección de origen IP, el protocolo IP (UDP / TCP), el puerto de destino (80, 21, 443, etc.), etc., si ACEPTAMOS, RECHAZAMOS o simplemente DEJAMOS un paquete IP en particular. Esto es lo que hace un cortafuegos el 80% del tiempo cuando, por ejemplo, protege un servidor web de solicitudes de red no autorizadas. El otro 20% del tiempo está manipulando paquetes de red (NAT, MANGLE).

Escenarios de cortafuegos

Hay cientos de diseños de firewall diferentes que cubren diferentes necesidades, pero 3 de ellos podrían considerarse los escenarios de firewall más típicos.

1. Servidor web simple con una o más interfaces conectadas a Internet. La política incluye reglas básicas para permitir el acceso entrante restringido, el acceso saliente sin restricciones y las reglas contra la suplantación de identidad. El reenvío de IP está desactivado.
2. Este firewall se conecta a Internet y a un área interna protegida. La política incluye reglas básicas para permitir el acceso entrante restringido, el acceso saliente sin restricciones y las reglas contra la suplantación de identidad. Dado que el área protegida utiliza direcciones IP privadas, se necesita NAT de origen. El reenvío de IP está activado.
3. Este firewall se conecta a Internet, área interna protegida y desmilitarizada. La política incluye reglas básicas para permitir el acceso entrante restringido, el acceso saliente sin restricciones y las reglas antifalsificación. Dado que las áreas protegidas y DMZ utilizan direcciones IP privadas, necesitan NAT de origen y destino. El reenvío de IP está activado.

He escrito esto para: http://www.vercot.com/~jeoss/howto/JeossEasyFirewall.html