IPSec Host-to-Host VPN (RedHat) necesita reenvío de IP?

6

Nos gustaría construir una VPN IPSec de host a host (tanto RedHat Linux). ¿Es realmente obligatorio activar el reenvío de IP que está desactivado de forma predeterminada debido a nuestra política de seguridad ( /etc/sysctl.conf net.ipv4.ip_forward = 0 )?

Entiendo que el adaptador VPN tiene que reenviar el tráfico a otros adaptadores de red. Sin embargo, el riesgo de seguridad es que estos dos servidores se están convirtiendo en "enrutadores". Estos servidores tienen múltiples adaptadores de red en los que el tráfico debe estar separado.

¿Qué controles deberían / podrían implementarse? Por ejemplo, iptables para minimizar el riesgo de seguridad?

    
pregunta AntonioM 02.02.2016 - 20:17
fuente

1 respuesta

0

Acabo de hacer una investigación sobre esto ya que estoy en el mismo asiento que tú; He configurado una VPN pero quería asegurarme de que no estoy reenviando el mundo.

Habilitar el reenvío en el kernel, no significa que todo pasará a través de iptables firewall. Sin embargo, si el firewall permite todo el reenvío, es posible que esté en un gran problema. Afortunadamente iptables parece que DROP reenvía paquetes de forma predeterminada. Para ver sus políticas de reenvío de firewall, ejecute iptables -L FORWARD .

FORWARD es la cadena donde residen las reglas de firewall para el reenvío de IP. Si tiene curiosidad acerca de las diferentes tablas y cadenas que atraviesa un paquete reenviado, consulte enlace .

Esto es lo que parece mi cadena FORWARD en una máquina Ubuntu, usando el firewall ufw , con una única VPN:

# iptables -L FORWARD
Chain FORWARD (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  192.168.0.0/24       192.168.1.0/24       policy match dir in pol ipsec reqid 5 proto esp
ACCEPT     all  --  192.168.1.0/24       192.168.0.0/24       policy match dir out pol ipsec reqid 5 proto esp
ufw-before-logging-forward  all  --  anywhere             anywhere
ufw-before-forward  all  --  anywhere             anywhere
ufw-after-forward  all  --  anywhere             anywhere
ufw-after-logging-forward  all  --  anywhere             anywhere
ufw-reject-forward  all  --  anywhere             anywhere

Algunas cosas a tener en cuenta:

  • La acción predeterminada es DROP ( policy DROP , ¡bien!).
  • Las únicas dos reglas de ACCEPT son para conexiones IPSEC establecidas ( policy match dir in pol ipsec reqid 5 proto esp y policy match dir out pol ipsec reqid 5 proto esp ). Esas reglas se agregaron automáticamente en mi aplicación IPSEC.
  • Mi cadena FORWARD sobre los delegados a la cadena ufw-before-logging-forward , etc. Cuando los investigo no veo ACCEPT s adicional. Es decir, debería estar a salvo.

Aquí hay un extracto de iptables -L donde miro las cadenas delegadas:

# iptables -L
[...]

Chain ufw-after-forward (1 references)
target     prot opt source               destination

[...]

Chain ufw-after-logging-forward (1 references)
target     prot opt source               destination
LOG        all  --  anywhere             anywhere             limit: avg 3/min burst 10 LOG level warning prefix "[UFW BLOCK] "

[...]

Chain ufw-before-forward (1 references)
target     prot opt source               destination
ufw-user-forward  all  --  anywhere             anywhere

[...]

Chain ufw-before-logging-forward (1 references)
target     prot opt source               destination

[...]

Chain ufw-reject-forward (1 references)
target     prot opt source               destination

[...]

Chain ufw-skip-to-policy-forward (0 references)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere

[...]

Chain ufw-user-forward (1 references)
target     prot opt source               destination

[...]

Chain ufw-user-logging-forward (0 references)
target     prot opt source               destination
    
respondido por el Ztyx 19.04.2016 - 14:38
fuente

Lea otras preguntas en las etiquetas