IPSec para tráfico LAN: ¿consideraciones básicas?

Este es un seguimiento de mi Cifrado absolutamente todo ... pregunta.

Importante : No se trata de la configuración IPSec más habitual, en la que desea cifrar el tráfico entre dos LAN.

Mi objetivo básico es cifrar todo el tráfico dentro de la LAN de una pequeña empresa. Una solución podría ser IPSec. Acabo de comenzar a aprender sobre IPSec, y antes de decidir usarlo y profundizar más, me gustaría obtener una visión general de cómo podría ser esto.

• ¿Existe un buen soporte multiplataforma? Debe funcionar en clientes Linux, MacOS X y Windows, servidores Linux, y no debe requerir hardware de red costoso.

• ¿Puedo habilitar IPSec para una máquina completa (para que no pueda haber otro tráfico entrante / saliente), o para una interfaz de red, o está determinado por la configuración del firewall para puertos individuales / ...?

• ¿Puedo prohibir fácilmente los paquetes IP que no sean IPSec? ¿Y también el tráfico IPSec de "Mallory's evil" que está firmado por alguna clave, pero no la nuestra? Mi concepción ideal es hacer que sea imposible tener dicho tráfico IP en la LAN.

• Para el tráfico interno de LAN: elegiría "ESP con autenticación (sin AH)", AES-256, en "Modo de transporte". ¿Es esta una decisión razonable?

• Para el tráfico LAN-Internet: ¿Cómo funcionaría con la puerta de enlace de Internet? Usaría

  • ¿"Modo túnel" para crear un túnel IPSec desde cada máquina a la puerta de enlace? ¿O también podría usar
  • "Modo de transporte" a la puerta de enlace? La razón por la que pregunto es que la puerta de enlace debería poder descifrar los paquetes que provienen de la LAN, por lo que necesitará las claves para hacerlo. ¿Es eso posible si la dirección de destino no es la dirección de la puerta de enlace? ¿O tendría que usar un proxy en este caso?

• ¿Hay algo más que deba considerar?

Realmente solo necesito una descripción rápida de estas cosas, no instrucciones muy detalladas.

• ¿Existe un buen soporte multiplataforma? Debe funcionar en clientes Linux, MacOS X y Windows, servidores Linux, y no debe requerir hardware de red costoso.

Realmente no tengo mucha experiencia con esto, ya que principalmente tengo sistemas Linux, pero lo hice principalmente trabajando en una máquina con Windows 2000 (esto fue hace algún tiempo). Hubo un problema de que el IPsec no pudo renegociar una nueva clave de sesión después de haber transferido cierto número de bytes (se supone que esto ocurre automáticamente), por lo que la conexión se cortó después de un tiempo, y nunca podría molestarme en cavar en ella más lejos. Probablemente funciona mucho mejor hoy en día.

• ¿Puedo habilitar IPSec para una máquina completa (para que no pueda haber otro tráfico entrante / saliente), o para una interfaz de red, o está determinado por la configuración del firewall para puertos individuales / ...?

¿Cómo funciona es (o, más bien, cómo me las arreglé para conseguir que funcione), se define que una máquina foo debe utilizar solamente IPsec para máquinas de barras , Baz y yow . Cualquier tráfico desde y hacia estas máquinas ahora es seguro y tan confiable como lo son esas máquinas. Cualquier otro tráfico no es IPsec y funciona normalmente.

• ¿Puedo prohibir fácilmente los paquetes IP que no sean IPSec? ¿Y también el tráfico IPSec de "Mallory's evil" que está firmado por alguna clave, pero no la nuestra? Mi concepción ideal es hacer que sea imposible tener dicho tráfico IP en la LAN.

El tráfico de IPsec solo está permitido para las " políticas " de IPsec que usted defina, por lo que cualquier máquina aleatoria no puede enviar paquetes de IPsec; debe existir una política de IPsec que coincida con esos paquetes.

• Para el tráfico interno de LAN: elegiría "ESP con autenticación (sin AH)", AES-256, en "Modo de transporte". ¿Es esta una decisión razonable?

Sí. Se habla de abandonar AH por completo porque es redundante: puede usar ESP con cifrado NULL con el mismo efecto.

• Para el tráfico LAN-Internet: ¿Cómo funcionaría con la puerta de enlace de Internet? Usaría
  • ¿"Modo túnel" para crear un túnel IPSec desde cada máquina a la puerta de enlace? ¿O también podría usar

Yo elegiría esta opción. Como es, no controlo la puerta de enlace yo mismo, y el tráfico no se cifrará fuera de mi red de todos modos, por lo que realmente no veo una necesidad apremiante.

El tráfico de Internet a los hosts que no utiliza IPsec debe verse como posiblemente interceptado; no tiene mucho sentido cifrar en la LAN local cuando su ISP o el ISP de su ISP puede escuchar los mismos paquetes sin cifrar.

• "Modo de transporte" a la puerta de enlace? La razón por la que pregunto es que la puerta de enlace debería poder descifrar los paquetes que provienen de la LAN, por lo que necesitará las claves para hacerlo. ¿Es eso posible si la dirección de destino no es la dirección de la puerta de enlace? ¿O tendría que usar un proxy en este caso?

Según tengo entendido, eso no funciona: necesitaría un proxy.

• ¿Hay algo más que deba considerar?

Vea si puede usar algo sensato como las claves OpenPGP en lugar de los certificados X.509. Uso X.509 ya que eso fue lo único compatible con el demonio de codificación IPsec que usé por primera vez, y no he tenido la energía para considerar rehacerlo todo. Pero debería, y lo haré, algún día.

PS Me y un asociado realizaron una conferencia sobre IPsec en 2007, puede ser útil aclarar algunos conceptos.

Esto suena un poco como una exageración. No puedo decir que haya oído hablar de alguien que encripta todo el tráfico en su LAN. ¿Cuál es tu motivación para conducir para hacer esto?

IPSec es ideal para conectarse a redes no confiables (es decir, DMZ web, etc.) y dentro de redes segregadas con firewalls. A las aplicaciones que usan protocolos RPC (es decir, Microsoft AD, etc.) les gusta usar rangos de puertos efímeros altos, que no coinciden con los firewalls. Dentro de la LAN, sus beneficios dependen de varios factores.

No es una bala de plata, y no necesariamente va a simplificar la seguridad de la red. Le ayudará a operar servicios en Internet u otras redes no confiables sin realizar grandes inversiones en equipos de red.

Si está haciendo esto como un ejercicio o una experiencia de aprendizaje, está bien, pero nada de lo que haya publicado hasta ahora es un argumento convincente para hacer lo que está hablando.