IPSec per il traffico LAN: considerazioni di base?

Questo è un seguito alla mia crittografia assolutamente tutto ... domanda.

Importante : non si tratta della configurazione IPSec più normale, in cui si desidera crittografare il traffico tra due LAN.

Il mio obiettivo di base è crittografare tutto il traffico all'interno della LAN di una piccola azienda. Una soluzione potrebbe essere IPSec. Ho appena iniziato a conoscere IPSec e prima di decidere di usarlo e immergermi più profondamente, vorrei avere una panoramica di come potrebbe essere.

• C'è un buon supporto multipiattaforma? Deve funzionare su client Linux, MacOS X e Windows, server Linux e non dovrebbe richiedere hardware di rete costoso.

• Posso abilitare IPSec per un intero computer (quindi non può esserci altro traffico in entrata / in uscita) o per un'interfaccia di rete o è determinato dalle impostazioni del firewall per le singole porte / ...?

• Posso facilmente vietare i pacchetti IP non IPSec? E anche il traffico IPSec di "Mallory's evil" che è firmato da una chiave, ma non dalla nostra? La mia idea ideale è rendere impossibile tale traffico IP sulla LAN.

• Per il traffico interno alla LAN: sceglierei "ESP con autenticazione (no AH)", AES-256, in "Modalità trasporto". È una decisione ragionevole?

• Per il traffico LAN-Internet: come funzionerebbe con il gateway Internet? Vorrei usare

  • "Modalità tunnel" per creare un tunnel IPSec da ogni macchina al gateway? O potrei anche usare
  • "Modalità di trasporto" al gateway? Il motivo per cui chiedo è che il gateway dovrebbe essere in grado di decrittografare i pacchetti provenienti dalla LAN, quindi avrà bisogno delle chiavi per farlo. È possibile, se l'indirizzo di destinazione non è l'indirizzo del gateway? O dovrei usare un proxy in questo caso?

• C'è qualcos'altro che dovrei considerare?

Ho solo bisogno di una rapida panoramica di queste cose, non di istruzioni molto dettagliate.

• C'è un buon supporto multipiattaforma? Deve funzionare su client Linux, MacOS X e Windows, server Linux e non dovrebbe richiedere hardware di rete costoso.

Non ho molta esperienza con questo, poiché ho principalmente sistemi Linux, ma l'ho fatto funzionare principalmente su una macchina Windows 2000 (questo era qualche tempo fa). Si è verificato un problema per il quale IPsec non è riuscito a rinegoziare una nuova chiave di sessione dopo che è stato trasferito un certo numero di byte (ciò dovrebbe avvenire automaticamente), quindi la connessione si è interrotta dopo un po 'e non ho mai potuto disturbarmi a scavare ulteriore. Probabilmente funziona molto meglio al giorno d'oggi.

• Posso abilitare IPSec per un intero computer (quindi non può esserci altro traffico in entrata / in uscita) o per un'interfaccia di rete o è determinato dalle impostazioni del firewall per le singole porte / ...?

Come funziona (o, piuttosto, come sono riuscito a farlo funzionare), tu definisci che una macchina foo deve usare solo IPsec per macchine bar , baz e yow . Qualsiasi traffico da e verso queste macchine è ora sicuro e affidabile come quelle macchine. Qualsiasi altro traffico non è IPsec e funziona normalmente.

• Posso facilmente vietare i pacchetti IP non IPSec? E anche il traffico IPSec di "Mallory's evil" che è firmato da una chiave, ma non dalla nostra? La mia idea ideale è rendere impossibile tale traffico IP sulla LAN.

Il traffico IPsec è consentito solo per quelle " politiche " IPsec definite dall'utente, pertanto qualsiasi macchina casuale non può inviare pacchetti IPsec; deve esistere una politica IPsec corrispondente a tali pacchetti.

• Per il traffico interno alla LAN: sceglierei "ESP con autenticazione (no AH)", AES-256, in "Modalità trasporto". È una decisione ragionevole?

Sì. Si parla di abbandonare completamente AH perché è ridondante: è possibile utilizzare ESP con crittografia NULL con lo stesso effetto.

• Per il traffico LAN-Internet: come funzionerebbe con il gateway Internet? Vorrei usare
  • "Modalità tunnel" per creare un tunnel IPSec da ogni macchina al gateway? O potrei anche usare

Vorrei scegliere questa opzione. Al momento non controllo personalmente il gateway e il traffico non sarà crittografato al di fuori della mia rete, quindi non vedo davvero un bisogno urgente.

Il traffico Internet verso gli host che non utilizzano IPsec deve essere visto come eventualmente intercettato: non ha molto senso crittografare la LAN locale quando il proprio ISP o ISP può ascoltare gli stessi pacchetti non crittografati.

• "Modalità di trasporto" al gateway? Il motivo per cui chiedo è che il gateway dovrebbe essere in grado di decrittografare i pacchetti provenienti dalla LAN, quindi avrà bisogno delle chiavi per farlo. È possibile, se l'indirizzo di destinazione non è l'indirizzo del gateway? O dovrei usare un proxy in questo caso?

A quanto ho capito, non funziona - avresti bisogno di un proxy.

• C'è qualcos'altro che dovrei considerare?

Scopri se puoi usare qualcosa di sensato come le chiavi OpenPGP invece dei certificati X.509. Uso X.509 poiché questa è stata l'unica cosa supportata dal demone di codifica IPsec che ho usato per la prima volta, e non ho avuto l'energia per cercare di rifare tutto. Ma un giorno dovrei e lo farò.

PS Io e un associato abbiamo tenuto una conferenza su IPsec nel 2007, potrebbe essere di aiuto chiarire alcuni concetti.

Sembra un po 'eccessivo. Non posso dire di aver mai sentito parlare di qualcuno che ha bloccato tutto il traffico sulla propria LAN. Qual è la tua motivazione trainante per farlo?

IPSec è ideale per la connessione a reti non attendibili (ad es. DMZ Web, ecc.) E all'interno di reti segregate con firewall. Le app che utilizzano protocolli RPC (ad es. Microsoft AD, ecc.) Amano utilizzare intervalli di porte effimere elevate, che non si adattano ai firewall. All'interno della LAN, i vantaggi dipendono da una serie di fattori.

Non è un proiettile d'argento e non semplifica necessariamente la sicurezza della rete. Ti aiuterà a gestire servizi su Internet o altre reti non attendibili senza fare enormi investimenti in dispositivi di rete.

Se lo stai facendo come esercizio o esperienza di apprendimento, va bene, ma nulla di ciò che hai pubblicato fino a questo punto è un argomento convincente per fare ciò di cui stai parlando.