En primer lugar, no hay nada que temer de estar en una asignación de IP pública, siempre que sus dispositivos de seguridad estén configurados correctamente.
¿Con qué debería reemplazar NAT si no tenemos redes físicamente separadas?
Lo mismo con lo que los hemos estado separando físicamente desde los años 80, enrutadores y firewalls. La gran ganancia de seguridad que obtienes con NAT es que te obliga a una configuración predeterminada de denegación. Para obtener cualquier servicio a través de él, debes hacer agujeros explícitamente . Los dispositivos más elegantes incluso le permiten aplicar ACL basadas en IP a esos agujeros, al igual que un firewall. Probablemente porque tienen 'Firewall' en la caja, en realidad.
Un firewall configurado correctamente proporciona exactamente el mismo servicio que una puerta de enlace NAT. Las puertas de enlace NAT se usan con frecuencia porque son más fáciles de acceder a una configuración segura que la mayoría de los firewalls.
Escuché que se supone que IPv6 e IPSEC hacen que todo esto sea seguro de alguna manera, pero sin redes físicamente separadas que hacen que estos dispositivos sean invisibles para Internet, realmente no puedo ver cómo.
Esta es una idea falsa. Trabajo para una universidad que tiene una asignación de IPv4 / 16, y la gran mayoría de nuestro consumo de direcciones IP está en esa asignación pública. Ciertamente, todas nuestras estaciones de trabajo e impresoras para usuarios finales. Nuestro consumo de RFC1918 se limita a dispositivos de red y ciertos servidores específicos donde se requieren dichas direcciones. No me sorprendería si acabaras de temblar, porque ciertamente lo hice cuando me presenté el primer día y vi el post-it en mi monitor con mi dirección IP.
Y sin embargo, sobrevivimos. ¿Por qué? Porque tenemos un firewall externo configurado para la denegación predeterminada con un rendimiento limitado de ICMP. El hecho de que 140.160.123.45 sea teóricamente enrutable, no significa que pueda llegar allí desde cualquier lugar en el Internet público. Para eso se diseñaron los firewalls.
Dadas las configuraciones correctas del enrutador, y diferentes subredes en nuestra asignación pueden ser completamente inalcanzables entre sí. Puede hacerlo en tablas de enrutadores o firewalls. Esta es una red separada y ha satisfecho a nuestros auditores de seguridad en el pasado.
De ninguna manera pondré nuestra base de datos de facturación (¡con mucha información de tarjeta de crédito!) En Internet para que todos la vean.
Nuestra base de datos de facturación se encuentra en una dirección IPv4 pública, y lo ha sido durante toda su existencia, pero tenemos pruebas de que no puede llegar allí desde aquí. El hecho de que una dirección esté en la lista pública de rutas v4 no significa que se garantice su entrega. Los dos cortafuegos entre los males de Internet y los puertos de bases de datos reales filtran el mal. Incluso desde mi escritorio, detrás del primer firewall, no puedo acceder a esa base de datos.
La información de la tarjeta de crédito es un caso especial. Eso está sujeto a los estándares PCI-DSS, y los estándares establecen directamente que los servidores que contienen dichos datos deben estar detrás de una puerta de enlace NAT 1 . Los nuestros son, y estos tres servidores representan nuestro uso total del servidor de direcciones RFC1918. No agrega ninguna seguridad, solo una capa de complejidad, pero necesitamos marcar esa casilla de verificación para auditorías.
La idea original de "IPv6 hace que NAT sea cosa del pasado" se presentó antes de que el auge de Internet realmente alcanzara la corriente principal. En 1995, NAT fue una solución para evitar una pequeña asignación de IP. En 2005 se consagró en muchos documentos de Mejores Prácticas de Seguridad, y al menos en un estándar importante (PCI-DSS para ser específico). El único beneficio concreto que ofrece NAT es que una entidad externa que realiza reconocimiento en la red no sabe cómo se ve el panorama de IP detrás del dispositivo NAT (aunque gracias a RFC1918 tienen una buena suposición), y en IPv4 sin NAT (como como mi trabajo) ese no es el caso. Es un pequeño paso en defensa en profundidad, no uno grande.
El reemplazo de las direcciones RFC1918 son las llamadas direcciones locales únicas. Al igual que RFC1918, no enrutan a menos que sus compañeros acuerden específicamente dejarlos enrutar. A diferencia de RFC1918, son (probablemente) globalmente únicos. Los traductores de direcciones IPv6 que traducen un ULA a una IP global sí existen en el engranaje perimetral de mayor rango, definitivamente todavía no en el engranaje SOHO.
Puedes sobrevivir bien con una dirección IP pública. Solo tenga en cuenta que "público" no garantiza "accesible", y estará bien.
Actualización 2017
En los últimos meses, Amazon AWS ha agregado compatibilidad con IPv6. Se acaba de agregar a su oferta de amazon-vpc , y su implementación brinda algunas pistas sobre cómo se espera que se realicen implementaciones a gran escala.
- Se le asigna una asignación / 56 (256 subredes).
- La asignación es una subred completamente enrutable.
- Se espera que establezca sus reglas de firewall ( grupos de seguridad ) de manera apropiada restrictiva.
- No hay NAT, ni siquiera se ofrece, por lo que todo el tráfico saliente provendrá de la dirección IP real de la instancia.
Para agregar uno de los beneficios de seguridad de NAT, ahora están ofreciendo una puerta de enlace de Internet solo para Egress . Esto ofrece un beneficio similar a NAT:
- No se puede acceder directamente a las subredes detrás de Internet.
Lo que proporciona una capa de defensa en profundidad, en caso de que una regla de firewall mal configurada permita accidentalmente el tráfico entrante.
Esta oferta no traduce la dirección interna en una sola dirección como lo hace NAT. El tráfico saliente seguirá teniendo la IP de origen de la instancia que abrió la conexión. Los operadores de firewall que buscan incluir recursos en la lista blanca en la VPC estarán mejor fuera de la lista blanca de bloques de red, en lugar de direcciones IP específicas.
Enrutable no siempre significa accesible .
1 : Los estándares PCI-DSS cambiaron en octubre de 2010, se eliminó la declaración que ordenaba las direcciones RFC1918 y se reemplazó el 'aislamiento de red'.