☰

¿Qué pasa con este firewall de iptables saliente?

tag-icon • tag-icon firewall iptables tcpip
¿Qué pasa con este firewall de iptables saliente?

Tengo un servidor de correo que me gustaría proteger permitiendo únicamente conexiones SALIENTES en los distintos puertos que utiliza. Las reglas de entrada funcionan bien: las maneja el host de la VM.

No he podido descubrir mucho sobre esto y, aunque el siguiente script casi funciona, descarta paquetes, por ejemplo aquí para el puerto 993:

Mar 25 16:08:11 lorina kernel: [200590.714226] IPTables-Dropped: IN= OUT=ens18 SRC=[local IP here] DST=[remote IP here] LEN=148 TOS=0x00 PREC=0x00 TTL=64 ID=37253 DF PROTO=TCP SPT=993 DPT=14826 WINDOW=243 RES=0x00 ACK PSH FIN URGP=0

Aquí está el guión. Tenga en cuenta que ens19 es la interfaz LAN (que me gustaría mantener abierta) y ens18 es la WAN.

iptables -A OUTPUT -o lo -p all -j ACCEPT
iptables -A OUTPUT -o ens19 -p all -j ACCEPT
iptables -A OUTPUT -p icmp -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -p udp -m owner --uid-owner systemd-timesync -j ACCEPT

ip6tables -A OUTPUT -o lo -p all -j ACCEPT
ip6tables -A OUTPUT -p icmpv6 -j ACCEPT
ip6tables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A OUTPUT -p tcp --dport 53 -j ACCEPT
ip6tables -A OUTPUT -p udp --dport 53 -j ACCEPT
ip6tables -A OUTPUT -p udp -m owner --uid-owner systemd-timesync -j ACCEPT

while read h; do
        ip6tables -A OUTPUT -m conntrack --ctstate NEW -d $h -j ACCEPT &> /dev/null
        iptables -A OUTPUT -m conntrack --ctstate NEW -d $h -j ACCEPT
done < /usr/local/etc/hosts-to-allow.list

while read p; do
        ip6tables -A OUTPUT -m conntrack --ctstate NEW -p tcp --dport $p -j ACCEPT
        iptables -A OUTPUT -m conntrack --ctstate NEW -p tcp --dport $p -j ACCEPT
done < /usr/local/etc/ports-to-allow.list

ip6tables -A OUTPUT -o ens18 -j LOGGING
ip6tables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
iptables -A OUTPUT -o ens18 -j LOGGING
iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4

iptables -A OUTPUT -o ens18 -j REJECT
ip6tables -A OUTPUT -o ens18 -j REJECT

Interesante nota al pie

Los paquetes descartados por estas reglas pueden ser normales y todavía los veo ocasionalmente. El usuario Doug S proporcionó una explicación para esto en los foros de soporte de Ubuntu:

Su ejemplo de línea de registro es para un paquete que no es "NUEVO". Puede saberlo por las banderas TCP al final de la línea.

Supongo que se trata de un paquete persistente de una sesión TCP ya cerrada y olvidada; de lo contrario, habría atravesado la ruta RELACIONADA Y ESTABLECIDA.

Esto sucede mucho con iptables, dependiendo de su enrutador y/u otras cosas en los paquetes que viajan. ¿Por qué? Porque para las conexiones TCP, Linux tiende a utilizar una secuencia de cierre "semidúplex" en la que cualquiera de los lados de la sesión puede iniciar la terminación de la conexión mediante un único protocolo de enlace FIN-ACK bidireccional (que coloca la conexión en el estado CLOSE_WAIT), en lugar de un Apretón de manos FIN-ACK completo de 4 vías.

Observe siempre las banderas para saber con seguridad qué está pasando. creo que estas bien

Hasta ahora, en el archivo /var/log/syslog de hoy tengo 115 entradas que terminan en "RES=0x00 ACK FIN URGP=0", y 93 de ellas son de mi LAN.

Respuesta1

Supongo que su lista de puertos a permitir contiene el puerto 993, por lo que no esperaba la entrada de registro que citó. Tenga en cuenta, sin embargo, que parece estar utilizando la lista de puertos para incluir en la lista blancadestinopuerto mientras que su registro muestra 993 como elfuentepuerto del paquete bloqueado.

información relacionada