Solución 1:
En general:
Ver y modificar la configuración del firewall requiere privilegios de administrador (root ) al igual que los servicios de apertura en el rango de número de puerto restringido. Eso significa que debe iniciar sesión como root o alternativamente use sudo para ejecutar el comando como root. Intentaré marcar dichos comandos con el [sudo] opcional .
Contenido:
- El orden importa o la diferencia entre
-Iy-A - Mostrar la configuración actual del cortafuegos
- Interpretando la salida de
iptables -L -v -n - Conoce tu entorno
- Las cadenas INPUT y FORWARD
- Módulos del núcleo
1. El orden importa o la diferencia entre -I y -A
Lo que debe recordar es que las reglas del firewall se verifican en el orden en que aparecen. El núcleo dejará de procesar la cadena cuando se active una regla que permita o no permita un paquete o una conexión.
Creo que el error más común para los administradores de cortafuegos novatos es que sigan 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 descubra que no surtirá efecto.
La razón de esto es que el -A opció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 la que bloqueaba todo el tráfico que no estaba explícitamente permitido, lo que resultaba 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).
Insertando la regla con -I la nueva regla habría sido la primera de la cadena y funcionará.
2. Mostrar la configuración actual del cortafuegos
Mi recomendación para el administrador del cortafuegos es que observe la configuración real que ejecuta el kernel de Linux, en lugar de tratar de diagnosticar los problemas del cortafuegos 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 -n es tu amigo (aunque a algunas personas les gusta iptables-save mejor). A menudo, cuando se habla de configuraciones, es útil usar el --line-numbers opción también a las rectas numéricas. Hacer referencia a la regla #X hace que discutirlas sea un poco más fácil.
iptables-save salida, pero debe enumerarse por separado agregando el -t nat opción, es decir, [sudo] iptables -L -v -n -t nat --line-numbers .
Ejecutar el comando varias veces y verificar los contadores en aumento puede ser una herramienta útil para ver si realmente se activa una nueva regla.
[[email protected] ~]# 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-save proporciona un script que puede regenerar la configuración del cortafuegos anterior:
[[email protected] ~]# 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 le resulte más fácil de entender.
3. Interpretando la salida de iptables -L -v -n
La política establece la acción predeterminada que utiliza la cadena cuando no coincide ninguna regla explícita. En el INPUT cadena que está configurada para ACEPTAR todo el tráfico.
La primera regla en la cadena INPUT es inmediatamente interesante, envía todo el tráfico (origen 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 objetivo personalizado (fail2ban-SSH ).Como su nombre lo indica, esta regla la mantiene fail2ban (un producto de seguridad que, entre otras cosas, escanea los archivos de registro del sistema en busca de posibles abusos y bloquea la dirección IP del abusador).
Esa regla habría sido creada por una línea de comando de iptables similar a iptables -I INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH o se 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 acertado 784'000 paquetes y 65 Megabytes de datos.
El fail2ban-SSH procesa el tráfico que coincide con esta primera regla. cadena que, como cadena no estándar, aparece debajo de la cadena OUTPUT.
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á bloqueado (con un 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 provienen de esos hosts bloqueados no están ni permitidos ni no permitidos todavía y ahora que la cadena personalizada está completa se compararán 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 se evaluarán en la regla INPUT #2.
La regla INPUT número 2 significa que se trata de un cortafuegos con estado , que rastrea las conexiones. Eso tiene algunas ventajas, solo los paquetes para nuevas conexiones deben verificarse con el conjunto completo de reglas, pero una vez permitidos, los paquetes adicionales que pertenecen a una conexión establecida o relacionada se aceptan sin más verificación.
La regla de entrada #2 coincide con todas las conexiones abiertas y relacionadas y los paquetes que coincidan con esa regla no necesitarán ser evaluados más.
Por el contrario, un filtro de paquetes simple prueba cada paquete contra el conjunto completo de reglas, sin rastrear el estado de la conexión. En tal cortafuegos ningún estado se utilizarían palabras clave.
La regla INPUT #3 es bastante aburrida, todo el tráfico se conecta al loopback (lo o 127.0.0.1) se permite la interfaz.
Las reglas de ENTRADA 4, 5 y 6 se utilizan para abrir los puertos TCP 22, 80 y 443 (los puertos predeterminados para respectivamente SSH, HTTP y HTTPS) otorgando acceso a NUEVAS conexiones (las conexiones existentes ya están permitidas por la regla de ENTRADA 2).
En un cortafuegos 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 de ENTRADA final, #7 es una regla que bloquea todo el tráfico al que NO se le otorgó acceso en las reglas de ENTRADA 1-7. Una convención bastante común:se niega todo lo que no está permitido. En teoría, esta regla podría haberse omitido configurando la POLÍTICA predeterminada en RECHAZAR.
Investigue siempre toda la cadena.
4. Conoce tu entorno
iptables las listas de control de acceso no modificadas en los enrutadores u otros firewalls en su red aún pueden bloquear el tráfico...
- Confirme que un servicio está escuchando (en la interfaz de red/dirección IP correcta) y usando los números de puerto que espera con
[sudo] netstat -plnuto alternativamente usess -tnlp. - Si aún no se supone que sus servicios se estén ejecutando, emule un oyente simple con, por ejemplo, netcat:
[sudo] nc -l -p 123oopenssl s_server -accept 1234 [options]si necesita un agente de escucha TLS/SSL (marqueman s_serverpara ver las opciones). - Verifique que pueda conectarse desde el propio servidor, es decir,
telnet <IP of Server> 123oecho "Hello" | nc <IP of Server> 123o al probar el servicio seguro TLS/SSLopenssl s_client -connect <IP of Server>:1234, antes de intentar lo mismo desde un host remoto.
- ¿Se usa TCP o UDP o ambos (como con DNS)?
- ¿El servicio utiliza 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 registran con Portmap)?
- el infame FTP incluso usa dos puertos , tanto un número de puerto fijo como dinámico cuando se configura para usar el modo pasivo...
- las descripciones de servicio, puerto y protocolo en
/etc/servicesno necesariamente coinciden con el servicio real usando un puerto.
- SELinux también podría estar restringiendo los servicios de red.
getenforceconfirmará si SELinux se está ejecutando. - Aunque se vuelven un poco oscuros, los TCP Wrappers siguen siendo una herramienta poderosa para reforzar la seguridad de la red. Verifique con
ldd /path/to/service |grep libwrapy el/hosts.[allow|deny]archivos de control.
5. INPUT o FORWARD Cadenas
El concepto de cadenas se explica más detalladamente aquí, pero en pocas palabras:
El INPUT La cadena es donde abre y/o cierra los puertos de red para los servicios que se ejecutan localmente, en el host donde emite los comandos de iptables.
El FORWARD La cadena es donde aplica reglas para filtrar el tráfico que el kernel reenvía a otros sistemas, sistemas reales, pero también contenedores Docker y servidores de servidores virtuales invitados cuando su máquina Linux actúa como puente, enrutador, hipervisor y/o traducción de direcciones de red. y redirección de puertos.
Un concepto erróneo 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 un módulo dinámico, en realidad, varios módulos. La mayoría de las distribuciones incluyen netfilter como módulos y los módulos de netfilter requeridos 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 nf_conntrack_ftp que se puede cargar con 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 durante los reinicios depende de la distribución de Linux.
Solución 2:
Iptables/Cortafuegos "introducción"
Un Firewall es básicamente un filtro de red basado en políticas. Los cortafuegos de Linux están construidos alrededor de Netfilter; el marco de procesamiento de paquetes de red del kernel que está compuesto por varios módulos del kernel que realizan tareas específicas:
- El módulo FILTRO (siempre cargado de forma predeterminada) nos permite principalmente ACEPTAR o DESCARTAR paquetes IP en función de ciertos criterios coincidentes.
- El conjunto de módulos NAT nos permite realizar traducciones de direcciones de red (SNAT, DNAT, MASQUERADE).
- El módulo MANGLE nos permite alterar ciertos campos de paquetes IP (TOS, TTL).
Los usuarios configuran el marco de Netfilter para satisfacer sus necesidades de firewall utilizando iptables desde la línea de comandos. Con iptables definimos reglas que 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 enganche específicos en el mapa de flujo de paquetes de la red donde el kernel los invoca para realizar sus funciones. y POSTROUTING. Es fácil de 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 las 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 entrega o descarta, el motor de Netfilter probará y aplicará secuencialmente las reglas contenidas en el mapa de flujo de paquetes de red. En cada bloque identificado por un par [email protected], el usuario puede agregar una o más de estas reglas consecutivas que contienen un criterio de coincidencia de paquetes IP y un curso de acción correspondiente. Hay acciones (es decir, ACCEPT, DROP, etc.) que pueden ser realizadas por más de una TABLE y otras acciones (es decir, SNAT, DNAT, etc.) que son específicas de TABLE.
es decir, cuando un paquete IP llega desde una interfaz de red, primero es procesado por 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 aplica el curso de acción o "política" predeterminado correspondiente de [email protected]. En este punto, si el paquete no se ha descartado, 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 las reglas, los usuarios también pueden crear sus propias cadenas personalizadas. y "salta" hacia ellos desde diferentes puntos del mapa como desees.
Si bien las cadenas integradas pueden tener políticas definidas por el usuario de ACEPTAR o DESCARTAR paquetes, las cadenas definidas por el usuario siempre tienen una política predeterminada inmutable de RETORNO a la persona que llama para continuar con el proceso.
Comandos de Iptables
Los comandos principales de iptables completan 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>
Podría leerse 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 configurando condiciones predeterminadas, reglas de listado, 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 de inmediato 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 poderoso, pero hay que pagar un precio por él; Iptables es complejo. Desde el punto de vista del usuario, ciertos términos como TABLE, CHAIN, TARGET realmente no coinciden muy bien con el concepto que representan y no tienen mucho sentido al principio. 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 brinda una instantánea del panorama de Netfilter/Iptables más la dosis necesaria de material de página de manual predigerido. Si es nuevo en iptables, después de leer estos párrafos un par de veces estará listo para leer ejemplos de iptables. Con un poco de práctica, pronto te encontrarás escribiendo tus 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 cortafuegos. 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 IP de origen, el protocolo IP (UDP/TCP), el puerto de destino (80, 21, 443, etc.), etc., si ACEPTAMOS, RECHAZAMOS o simplemente ABANDONAMOS un paquete IP en particular. Esto es lo que hace un firewall 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 abordan diferentes necesidades, pero 3 de ellos podrían considerarse los escenarios de firewall más típicos.
- Simple servidor web 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 reglas contra la suplantación de identidad. El reenvío de IP está desactivado.
- Este cortafuegos se conecta a Internet ya un área interna protegida. La política incluye reglas básicas para permitir el acceso entrante restringido, el acceso saliente sin restricciones y 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.
- 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 reglas contra la suplantación de identidad. Dado que las áreas protegidas y DMZ usan 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
Solución 3:
Problemas comunes con diferentes protocolos
DNS: El DNS usa el puerto 53 UDP de forma predeterminada, pero los mensajes que no caben en un único datagrama UDP se transmitirán mediante TCP (por lo general, transferencias de zona y demás), lo que requiere que también se abra el puerto 53 TCP cuando ejecuta un servidor de nombres.
Correo electrónico: Muchos ISP de consumo 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 utilizar el relé SMTP del ISP para todos los correos electrónicos salientes y, a veces, también para los correos electrónicos entrantes. §1.1.
En un cortafuegos sin estado que normalmente 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 cortafuegos con estado, no necesita abrir explícitamente el puerto de DATOS, el módulo de ayuda de netfilter reconocerá el puerto dinámico que se asigna y abrirá dinámicamente ese puerto para el cliente correcto marcando la conexión de DATOS como RELATED después de lo cual coincidirá con la regla genérica:
iptables -I INPUT -p tcp -m state ESTABLISHED,RELATED -j ACCEPT
Esto requiere que el módulo kernel correcto se carga, en el caso de FTP manualmente ejecutando, por ejemplo, insmod nf_conntrack_ftp , hacer que la persistencia dependa del reinicio depende de la distribución.
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 firewall, se debe abrir el puerto TCP/UDP 111 y el puerto real que el servicio RPC está usando actualmente. El problema de abrir un puerto aleatorio en un firewall generalmente se resuelve restringiendo el servicio RPC, como NFS. servidor, para usar un puerto fijo predeterminado.