IPSec Host-to-Host VPN (RedHat) ha bisogno dell'inoltro IP?

6

Vogliamo costruire un IPSec VPN Host-to-Host (entrambi RedHat Linux). È davvero obbligatorio attivare l'IP Forwarding, che per impostazione predefinita è disattivato a causa della nostra politica di sicurezza ( /etc/sysctl.conf net.ipv4.ip_forward = 0 )?

Capisco che l'adattatore VPN debba inoltrare il traffico ad altri adattatori di rete. Tuttavia, il rischio per la sicurezza è che questi due server stanno diventando "router". Questi server hanno più schede di rete in cui il traffico deve essere separato.

Quali controlli dovrebbero / potrebbero essere implementati? Ad esempio, iptables per ridurre al minimo il rischio per la sicurezza?

    
posta AntonioM 02.02.2016 - 20:17
fonte

1 risposta

0

Ho appena fatto delle ricerche su questo mentre sono nella tua stessa posizione; Ho impostato una VPN ma volevo assicurarmi che non stia inviando il mondo.

Abilitare l'inoltro nel kernel, non significa che tutto passerà attraverso iptables firewall. Tuttavia, se il firewall consente l'inoltro completo, potresti avere grossi problemi. Fortunatamente iptables sembra che DROP abbia inoltrato i pacchetti per impostazione predefinita. Per dare un'occhiata alle politiche di inoltro del firewall, esegui iptables -L FORWARD .

FORWARD è la catena in cui risiedono le regole del firewall per l'inoltro IP. Se sei curioso di conoscere le diverse tabelle e catene di un pacchetto inoltrato, dai un'occhiata a link .

Ecco come appare la mia catena FORWARD su una macchina Ubuntu, utilizzando il firewall ufw , con una singola 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

Alcune cose da notare:

  • L'azione predefinita è DROP ( policy DROP , buona!).
  • Le uniche due regole ACCEPT sono per le connessioni IPSEC stabilite ( policy match dir in pol ipsec reqid 5 proto esp e policy match dir out pol ipsec reqid 5 proto esp ). Queste regole sono state aggiunte automaticamente dalla mia applicazione IPSEC.
  • La mia catena FORWARD sopra delegati a ufw-before-logging-forward chain ecc. Quando li indago, non vedo altri ACCEPT s. Cioè, dovrei essere al sicuro.

Ecco un estratto da iptables -L dove guardo le catene delegate:

# 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
    
risposta data 19.04.2016 - 14:38
fonte

Leggi altre domande sui tag