
Hola, tengo un servidor en línea que uso como puerta de enlace e iptables está actuando de manera extraña.
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 443 -j BLOCK_CHAIN
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j BLOCK_CHAIN
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i tun+ -j ACCEPT
-A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o tun+ -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -i eth0 -o tun+ -p tcp -m tcp --dport 80 --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -i eth0 -o tun+ -p tcp -m tcp --dport 443 --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A BLOCK_CHAIN -s 173.230.154.149/32 -j REJECT --reject-with icmp-host-prohibited
-A BLOCK_CHAIN -m state --state NEW -j ACCEPT
pero 173.230.154.149 todavía puede acceder al servidor Apache en 80 o 443, no debería bloquearlo
-A INPUT -i eth0 -p tcp -m tcp --dport 443 -j BLOCK_CHAIN
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j BLOCK_CHAIN
y
-A BLOCK_CHAIN -s 173.230.154.149/32 -j REJECT --reject-with icmp-host-prohibited
Sí, es un servidor en línea que enruta todos los servicios web a un servidor personal más grande a través de una VPN con OpenVPN.
Todo funciona como se esperaba, solo que no puedo bloquear la conexión entrante desde cierta IP, obviamente están atacando el servidor.
la tipología de la red es
IP externa XX.XX.X.XX VPN 10.0.0.0/24
-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.0.100
-A PREROUTING -i eth0 -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.0.0.100
Respuesta1
Un paquete que es enrutado en lugar de recibido por un proceso local atraviesa la cadena de filtro/ADELANTE y no la cadena de filtro/ENTRADA, incluso si esto se debe al uso de NAT. Por lo tanto, las reglas de bloqueo actuales en filtro/ENTRADA no tienen ningún efecto. Estas reglas:
-A INPUT -i eth0 -p tcp -m tcp --dport 443 -j BLOCK_CHAIN -A INPUT -i eth0 -p tcp -m tcp --dport 80 -j BLOCK_CHAIN
simplemente debe ser reemplazado por:
-A FORWARD -i eth0 -p tcp -m tcp --dport 443 -j BLOCK_CHAIN
-A FORWARD -i eth0 -p tcp -m tcp --dport 80 -j BLOCK_CHAIN
Evidentemente conviene añadirlas antes de las reglas que permiten el acceso al servidor web para que puedan tener algún efecto. Así que agréguelos al menos antes de estos:
-A FORWARD -i eth0 -o tun+ -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT -A FORWARD -i eth0 -o tun+ -p tcp -m tcp --dport 80 --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT -A FORWARD -i eth0 -o tun+ -p tcp -m tcp --dport 443 --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
Porque una vez que se acepta la conexión inicial, todos los paquetes adicionales serán cortocircuitados por esta regla:
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Por lo que hay que bloquearlos la primera vez que se ven.
Observaciones adicionales:
reglas redundantes
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i tun+ -j ACCEPT -A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
La primera regla anterior, y también la segunda regla, cada una de ellas por separado, hacen que la tercera regla sea redundante.
Asimismo:
-A FORWARD -i eth0 -o tun+ -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT -A FORWARD -i eth0 -o tun+ -p tcp -m tcp --dport 80 --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT -A FORWARD -i eth0 -o tun+ -p tcp -m tcp --dport 443 --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
La primera regla hace que las dos siguientes sean redundantes.
Pero todo esto podría haber sido para probar el problema actual.
a menos que se ejecute un kernel muy reciente (donde el problema está solucionado), no se debe permitir que ninguna regla REJECT rechace un paquete en estado NO VÁLIDO. Dicho paquete "sólo" debe ser DROP-ed, o pueden ocurrir fallas de conexión aleatorias raras del tráfico legítimo.
Esto ahora está documentado en
iptables-extensions(8)
:Advertencia: No debe aplicar indiscriminadamente el objetivo REJECT a paquetes cuyo estado de conexión esté clasificado como INVÁLIDO; en su lugar, solo debes DEJARLOS.
(La página de manual proporciona más fundamentos).
Por lo general,
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
debe ir seguido de:
-A FORWARD -m conntrack --ctstate INVALID -j DROP