¿Tiene algún servidor público como servidores web en su red?

¿Tiene un Wi-Fi de
invitado habilitado pero no desea que los visitantes accedan a su recurso interno? En
esta sesión, hablaremos sobre la segmentación de la seguridad mediante la creación
de múltiples niveles de seguridad en un firewall ASA de Cisco. Al final, también se
proporcionan el ejemplo y la plantilla de configuración de ASA DMZ de Cisco.

La información en esta sesión se aplica a los sistemas ASA 5500 heredados de Cisco
(es decir, ASA 5505, 5510 y 5520), así como a los dispositivos firewall de la serie ASA
5500-X de próxima generación.

Desde la versión 8.3 del código ASA, hubo un cambio importante introducido en la
funcionalidad NAT por parte de Cisco. Cubriremos la configuración de las versiones
anteriores a la 8.3 y de la versión 9.x actual.

Puede descargar la configuración completa del laboratorio y los archivos

de configuración GRATIS

Como parte de nuestro esfuerzo de documentación, mantenemos la información

actual y precisa que proporcionamos. Las documentaciones son revisadas y
actualizadas rutinariamente. Solicitamos su dirección de correo electrónico para
mantenerlo informado cuando se actualice el artículo.

Descargar ahora
Ejemplo de configuración de Cisco ASA DMZ

Principio de diseño

El siguiente diagrama de red describe los requisitos de red comunes en un entorno

corporativo.
Un Cisco ASA se implementa como una puerta de enlace de Internet, que proporciona
acceso de Internet saliente a todos los hosts internos.

Hay cuatro niveles de seguridad configurados en ASA, LAN, DMZ1, DMZ2 y en el

exterior. Su nivel de seguridad de alto a bajo es el siguiente: LAN> DMZ1> DMZ2>
exterior.

 LAN es considerada la red más segura. No solo alberga estaciones de trabajo

internas de usuarios, así como servidores de producción de misión crítica. Los
usuarios de LAN pueden llegar a otras redes. Sin embargo, no se permite el
acceso entrante desde ninguna otra red a menos que se permita
explícitamente.
 DMZ1 aloja servidores web públicos. Cualquiera en Internet puede llegar a los
servidores en el puerto TCP 80. DMZ1 también aloja servidores DNS para Wi-
Fi para invitados en DMZ2.
 DMZ2 está diseñado como una red de invitados no confiable. Su único
propósito es proporcionar acceso a Internet para los visitantes. Para el filtrado
de contenido de Internet, se requiere que usen los servidores DNS internos en
DMZ1.

La idea de diseño aquí es que no permitimos ninguna posibilidad de comprometer la

LAN. Se deniega todo acceso "de entrada" a la LAN a menos que la conexión se inicie
desde los hosts internos. Los servidores en DMZ1 tienen dos propósitos: atender el
tráfico web de Internet y las consultas de resolución de DNS desde DMZ2, la red Wi-Fi
del huésped. Tenemos servidores DNS en la LAN para usuarios internos y
servidores. Pero no queremos abrir ningún agujero de firewall a nuestra red más
segura. El peor de los casos es que, en el caso de que DMZ2 se vea comprometida,
ya que es la red de arrendamiento controlado, potencialmente puede afectar a DMZ1
porque tenemos reglas de firewall abiertas para el acceso de DNS desde DMZ2 a
DMZ1. Se supone que tanto el DMZ1 como el DMZ2 están comprometidos, y el pirata
informático no tiene forma de abrirse camino hacia la subred de la LAN porque
ninguna regla de firewall permite ningún acceso a la LAN en absoluto.

Niveles de seguridad en Cisco ASA Firewall

Antes de saltar a la configuración, me gustaría hablar brevemente sobre cómo

funcionan los ASA de Cisco en un diseño de seguridad multinivel. El concepto no es
específico de Cisco. Se aplica a cualquier otro cortafuegos de calidad empresarial.

De forma predeterminada, se niega el tráfico que pasa de un nivel de seguridad más

bajo a uno más alto. Esto puede ser reemplazado por una ACL aplicada a esa interfaz
de menor seguridad. Además, el ASA, de forma predeterminada, permitirá el tráfico de
interfaces de seguridad más alta a más baja. Este comportamiento también se puede
anular con una ACL. Los niveles de seguridad están definidos por números numéricos
entre 0 y 100. 0 a menudo se coloca en la red no confiable, como Internet. Y 100 es la
red más segura. En nuestro ejemplo, asignamos niveles de seguridad de la siguiente
manera: LAN = 100, DMZ1 = 50, DMZ2 = 20 y fuera = 0.

Configuración de topología de laboratorio

En nuestro laboratorio, usamos un host en cada red para representar las

características de esa subred. Un host se coloca en el lado de Internet para la prueba.
Primero cubriremos el ejemplo de configuración para una versión de código ASA más
reciente que 8.3, así como 9.x.

Ejemplo de configuración de Cisco ASA DMZ

Paso 1: Asignar nivel de seguridad a cada interfaz ASA

Configuraremos cuatro interfaces en el ASA. Sus niveles de seguridad son: dentro

(100), dmz1 (50), dmz2 (20) y fuera (0).

interface GigabitEthernet0/0
description to WAN
nameif outside
security-level 0
ip address 10.1.1.1 255.255.255.0
!
interface GigabitEthernet0/1
description to LAN
nameif inside
security-level 100
ip address 192.168.0.1 255.255.255.0
!
interface GigabitEthernet0/2
description to DMZ1
nameif dmz1
security-level 50
ip address 192.168.1.1 255.255.255.0
!
interface GigabitEthernet0/3
description to DMZ2
nameif dmz2
security-level 20
ip address 192.168.2.1 255.255.255.0

Paso 2: configure ASA como una puerta de enlace de Internet, habilite el

acceso a Internet

Hay dos tareas principales para permitir que los hosts internos salgan a Internet,
configurando la traducción de direcciones de red (NAT) y enrutando todo el tráfico al
ISP. No necesita una ACL porque todo el tráfico saliente está atravesando desde un
nivel de seguridad más alto (dentro, dmz1 y dmz2) hasta un nivel de seguridad más
bajo (fuera).

nat (inside,outside) after-auto source dynamic any interface

nat (dmz1,outside) after-auto source dynamic any interface
nat (dmz2,outside) after-auto source dynamic any interface

La configuración anterior indica que cualquier tráfico proveniente de la red interna,

dmz1 y dmz3, traduce la IP de origen a la IP de la interfaz externa para el tráfico
saliente de Internet. La palabra clave "after-auto" simplemente establece este NAT
como la regla menos preferida para ser evaluada después de que se evalúe el NAT
manual y el NAT automático. La razón por la que queremos darle la menor preferencia
es evitar un posible conflicto con otras reglas de NAT. Hablemos brevemente sobre
los cambios principales en el código NAT post-8.3.

NAT en el ASA desde la versión 8.3 y posteriores se divide en dos tipos conocidos
como Auto NAT (Object NAT) y Manual NAT (Twice NAT). El primero de los dos,
Object NAT, se configura dentro de la definición de un objeto de red.

La principal ventaja de Auto NAT es que el ASA ordena automáticamente las reglas
de procesamiento para evitar conflictos. Esta es la forma más fácil de NAT, pero con
esa facilidad viene con una limitación en la granularidad de la configuración. Por
ejemplo, no puede tomar una decisión de traducción basada en el destino en el
paquete como lo haría con el segundo tipo de NAT, Manual NAT. La NAT manual es
más robusta en su granularidad, pero requiere que las líneas se configuren en el
orden correcto para lograr el comportamiento correcto.

El otro cambio en NAT es que usted define un NAT o no lo hace. El tráfico que no
coincida con ninguna regla de NAT atravesará el firewall sin ninguna traducción (como
la exención de NAT, pero sin configurarlo explícitamente, más como una exención de
NAT implícita). Las palabras clave estáticas y globales están en desuso. Ahora se
trata de "NAT".

Lo siguiente es configurar una puerta de enlace predeterminada y enrutar todo el

tráfico al ISP ascendente. 10.1.1.2 es la puerta de enlace que proporciona el ISP.

route outside 0.0.0.0 0.0.0.0 10.1.1.2

También asegúrese de que "inspect icmp" esté configurado en global_policy. Permite

que el tráfico de retorno de icmp pase el ASA mientras el Ping se inicia desde los
hosts internos.

policy-map global_policy
class inspection_default
inspect icmp
En este punto, debería poder hacer ping al host 10.1.1.200 en Internet desde
cualquier subred interna.

Paso 3: configure NAT estática para servidores web, otorgue acceso de

entrada de Internet a servidores web

Primero definimos dos objetos para el servidor web, uno para su IP interna y otro para
su IP pública.

object network WWW-EXT

host 10.1.1.10
!
object network WWW-INT
host 192.168.1.10

Tenemos dos formas de configurar NAT, NAT automática (NAT de objeto) y NAT
manual (NAT doble). Para Auto-NAT, inserte esta configuración en el objeto WWW-
INT.
 nat (dmz1,outside) static WWW-EXT service tcp www www

Para NAT manual, defina el objeto de servicio web y configure la NAT manual en el
modo de configuración global. En nuestro ejemplo, vamos a demostrar Manual
NAT. Sólo puede tener un conjunto de configuración a la vez.

object service WEB-SERVICE

service tcp source eq www
!
nat (dmz1,outside) source static WWW-INT WWW-EXT service WEB-SERVICE
WEB-SERVICE

Cuando un host que coincide con la dirección IP 192.168.1.10 en el segmento dmz1

establece una conexión procedente del puerto TCP 80 (WWW) y esa conexión sale
por la interfaz externa, queremos traducir que sea el puerto TCP 80 (WWW) en el
exterior Interfaz y traducir esa dirección IP para ser 10.1.1.10.

Eso parece un poco extraño ... "proviene del puerto TCP 80 (www)", pero el tráfico
web está destinado al puerto 80. Es importante comprender que estas reglas de NAT
son de naturaleza bidireccional. Como resultado, puede volver a redactar esta frase
cambiando la redacción. El resultado tiene mucho más sentido:

Cuando los hosts en el exterior establezcan una conexión a 10.1.1.10 en el puerto

TCP de destino 80 (www), traduciremos la dirección IP de destino a 192.168.1.10 y el
puerto de destino será el puerto TCP 80 (www) y lo enviaremos a dmz1 .

Debido a que el ASA niega de forma predeterminada el tráfico desde el exterior a la

red dmz1, los usuarios de Internet no pueden acceder al servidor web a pesar de la
configuración de NAT. Necesitaremos configurar las ACL y permitir que el tráfico
entrante de Internet acceda al servidor web.

access-list OUTSIDE extended permit tcp any object WWW-INT eq www

!
access-group OUTSIDE in interface outside

Los estados de ACL permiten el tráfico desde cualquier lugar al servidor web (WWW-
INT: 192.168.1.10) en el puerto 80.

En versiones anteriores del código ASA (8.2 y anteriores), el ASA comparó una
conexión o un paquete entrante con la ACL en una interfaz sin haber traducido
primero el paquete. En otras palabras, la ACL tenía que permitir el paquete como si
fuera a capturar ese paquete en la interfaz. En el código 8.3 y posterior, el ASA des-
traduce ese paquete antes de verificar las ACL de la interfaz. Esto significa que para
el código 8.3 y posterior, se permite el tráfico a la IP real del host y no a la IP traducida
del host. Tenga en cuenta que utilizamos WWW-INT en este ejemplo.

Paso 4: Control de acceso del segmento de seguridad

Vamos a resumir el comportamiento predeterminado en un ASA de Cisco.

 El tráfico iniciado desde una interfaz de seguridad más baja se deniega cuando
se va a una interfaz de seguridad más alta
 El tráfico iniciado desde una interfaz de seguridad más alta se permite cuando
se va a una interfaz de seguridad más baja

Específicamente en nuestro ejemplo,

 El tráfico iniciado desde "adentro" puede ir a cualquier otro segmento de la

interfaz: "dmz1", "dmz2" y "afuera".
 El tráfico iniciado desde "dmz1" puede ir a "dmz2" y "afuera". Se niega cuando
se va a "adentro".
 El tráfico iniciado desde "dmz2" solo se permite cuando se va a "afuera". Todos
los demás segmentos de acceso están denegados.

Las reglas predeterminadas pueden ser sobrescritas por ACLs. En nuestro ejemplo,
necesitamos que los invitados en dmz2 puedan usar los servidores DNS en
dmz1. Necesitaremos configurar las ACL para permitir específicamente el acceso.

! define network objects

object network INSIDE-NET
subnet 192.168.0.0 255.255.255.0
!
object network DMZ1-NET
subnet 192.168.1.0 255.255.255.0
!
! define DNS server object
object network DNS-SERVER
host 192.168.1.10
!
access-list DMZ2-ACL extended permit udp any object DNS-SERVER eq
domain
access-list DMZ2-ACL extended deny ip any object INSIDE-NET
access-list DMZ2-ACL extended deny ip any object DMZ1-NET
access-list DMZ2-ACL extended permit ip any any
!
access-group DMZ2-ACL in interface dmz2

Las ACL permiten que el tráfico iniciado desde dmz2 acceda al servidor DNS en el
puerto UDP 53. Recuerde que hay un "deny ip any" implícito al final de la ACL. Si nos
detenemos aquí, el acceso a Internet de dmz2 se interrumpirá. Agregamos tres líneas
más para denegar el acceso a dmz1 y a las redes internas al tiempo que permitimos
que el restablecimiento del tráfico vaya a Internet.

¿Qué pasa con las ACL en dmz1 y las interfaces internas? No necesitamos ninguna
ACL en esas interfaces porque el comportamiento de seguridad predeterminado
cumple con nuestros requisitos.

Paso 5: Verificación y resolución de problemas

En esta sesión, demostraré algunas técnicas de verificación y solución de problemas

para validar rápidamente la configuración e identificar el problema, si corresponde.

La primera técnica es usar el ping ICMP para verificar la conectividad de la

red. Obviamente, el ping está funcionando no concluye que todo lo demás también
funciona. Sin embargo, es una herramienta simple para confirmar que el paquete
desde el punto A puede llegar al punto B. En nuestro ejemplo, deseamos verificar que
los hosts en cada subred interior, dmz1 y dmz2 tengan acceso a Internet. Intentamos
hacer ping al host de Internet a 10.1.1.200 desde cada red interna.

En el ASA, habilitamos el modo de depuración de ICMP e hicimos el terminal como el

monitor de salida de mensajes de depuración. De forma predeterminada, los
mensajes de depuración se envían al búfer de registro en lugar de a la pantalla. Debe
ver los registros haciendo "mostrar registro". En nuestro caso, queríamos ver los
registros inmediatamente cuando aparecían en la pantalla.

ASA1# debug icmp trace

ASA1# terminal monitor

Ping se inició desde dentro del host 192.168.0.200, dmz1 host 192.168.1.10 y dmz2
host 192.168.2.10. Se están recibiendo respuestas.

Estudie el mensaje de depuración y verá exactamente cómo fluyen los paquetes

ICMP a través de la red.
 1. Solicitud de eco ICMP desde adentro: 192.168.0.200 hacia afuera: 10.1.1.200
(El ASA ve un paquete de ping entrante desde el host de la interfaz interna
192.168.0.200 y trata de llegar al host 10.1.1.200 en la interfaz externa)
2. La solicitud de eco ICMP se traduce dentro: 192.168.0.200 al exterior: 10.1.1.1
(El ASA detectó una regla NAT que coincidiría, y la usó para traducir la IP de
origen de 192.168.0.200 a 10.1.1.1)
3. Respuesta de eco ICMP desde el exterior: 10.1.1.200 al interior: 10.1.1.1 (El
host 10.1.1.200 en Internet respondió a la solicitud de ping y envía el tráfico de
retorno al 10.1.1.1)
4. Respuesta de eco ICMP sin traducir fuera: 10.1.1.1 al interior: 192.168.0.2002
(El ASA ve el tráfico de retorno de ping y coincide con una sesión de tráfico
establecida cuando se generó el tráfico de ping de salida. El ASA sabe
exactamente quién lo solicitó y quién está esperando desesperadamente para
ello. El ASA anula la traducción de la IP de 10.1.1.1 a 192.168.0.200 y la envía
a 192.168.0.200).

Después de la prueba, recuerde desactivar el modo de depuración porque consume

recursos del sistema.

ASA1# no debug all

La segunda técnica es utilizar Packet Tracer para simular paquetes que pasan por el
ASA y ver cómo el ASA trata el paquete paso a paso. Es una herramienta excelente
cuando no tiene acceso a ningún lado de los servidores para generar tráfico real. O
antes de ponerlo en funcionamiento, quería asegurarse de que la configuración hará
lo que se pretende.

Haremos dos pruebas de rastreo de paquetes para validar estos servicios críticos:

El ASA permitirá el tráfico web entrante al servidor web en DMZ1.

El ASA permitirá a los usuarios en DMZ2 acceder al servidor DNS en DMZ1.

Primero simulamos el tráfico de navegación web iniciado desde un host en Internet

con IP 10.1.1.200, tratando de llegar al servidor web en el puerto 80. Los siguientes
estados de comando:

“Genere un paquete falso y empújelo a través de la interfaz externa del ASA en la

dirección de entrada. El paquete viene con la IP de origen 10.1.1.200 utilizando un
número de puerto alto aleatorio 1234 y la IP de destino 10.1.1.10 para el servidor web
en el puerto 80 ".

ASA1# packet-tracer input outside tcp 10.1.1.200 1234 10.1.1.10 http

detailed
Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7fffd1991830, priority=1, domain=permit, deny=false
hits=43, user_data=0x0, cs_id=0x0, l3_type=0x8
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0100.0000.0000
input_ifc=outside, output_ifc=any

Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (dmz1,outside) source static WWW-INT WWW-EXT service WEB-SERVICE
WEB-SERVICE
Additional Information:
NAT divert to egress interface dmz1
Untranslate 10.1.1.10/80 to 192.168.1.200/80

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group OUTSIDE in interface outside
access-list OUTSIDE extended permit tcp any object WWW-INT eq www
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7fffd12e7660, priority=13, domain=permit, deny=false
hits=1, user_data=0x7fffd8eb9d00, cs_id=0x0, use_real_addr,
flags=0x0, protocol=6
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=192.168.1.200, mask=255.255.255.255, port=80,
tag=any, dscp=0x0
input_ifc=outside, output_ifc=any
 Phase: 4
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (dmz1,outside) source static WWW-INT WWW-EXT service WEB-SERVICE
WEB-SERVICE
Additional Information:
Static translate 10.1.1.200/1234 to 10.1.1.200/1234
Forward Flow based lookup yields rule:
in id=0x7fffd1cc1b50, priority=6, domain=nat, deny=false
hits=1, user_data=0x7fffd12e6270, cs_id=0x0, flags=0x0,
protocol=6
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=10.1.1.10, mask=255.255.255.255, port=80, tag=any,
dscp=0x0
input_ifc=outside, output_ifc=dmz1
...
output omitted for brevity
...
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: dmz1
output-status: up
output-line-status: up
Action: allow

Al examinar los resultados del rastreador de paquetes, aprendimos lo siguiente:

 La fase 1 es la ACL de nivel MAC de capa 2, no tenemos ninguna restricción

de nivel de MAC configurada y todo el tráfico está permitido de forma
predeterminada.
 En la Fase 2, el paquete se está desintegrando antes de enviarlo a la interfaz
ACL externa. Es por eso que necesitamos utilizar la IP real o la IP interna
WWW-INT al configurar la ACL. Es un cambio importante desde el código ASA
8.3. Antes del código 8.3, primero se verificaba la ACL antes de anular la
configuración de NAT.
  La fase 3 muestra que se está verificando la ACL externa y se permite el
tráfico.
 El restablecimiento de las fases hizo que el paquete pasara por varias
verificaciones de políticas, como QoS, mapas de políticas, etc. No tenemos
ninguno de los configurados, por lo que no hubo ningún efecto en el paquete.
 Al final, se muestra un buen resumen. La interfaz de entrada está fuera, la
interfaz de salida es dmz1 y el tráfico se envía correctamente.

De manera similar, podemos hacer el paquete de pruebas de rastreo entre dmz2 y

dmz1, para verificar que el host en dmz2 tenga acceso al servidor DNS de dmz1.

ASA1# packet-tracer input dmz2 udp 192.168.2.10 1234 192.168.1.10

domain detailed
Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7fffd1a76710, priority=1, domain=permit, deny=false
hits=12, user_data=0x0, cs_id=0x0, l3_type=0x8
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0100.0000.0000
input_ifc=dmz2, output_ifc=any

Phase: 2
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 192.168.1.10 using egress ifc dmz1

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
 access-group DMZ2-ACL in interface dmz2
access-list DMZ2-ACL extended permit udp any object DNS-SERVER eq
domain
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7fffd1cdad10, priority=13, domain=permit, deny=false
hits=0, user_data=0x7fffd8eb9b80, cs_id=0x0, use_real_addr,
flags=0x0, protocol=17
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=192.168.1.10, mask=255.255.255.255, port=53, tag=any,
dscp=0x0
input_ifc=dmz2, output_ifc=any
...
output omitted for brevity
...
Result:
input-interface: dmz2
input-status: up
input-line-status: up
output-interface: dmz1
output-status: up
output-line-status: up
Action: allow

 Como no hay NAT involucrado, la Fase 2 se dirigió directamente a la búsqueda

de rutas. La interfaz de salida dmz1 fue identificada.
 La fase 3 verifica la ACL y le otorgó el tráfico.
 El reinicio de las fases se mantuvo igual. Al final, el paquete se envió con éxito
a través de la interfaz dmz1.

Los resultados de ambos paquetes de seguimiento confirmaron que nuestra

configuración es correcta. Vamos a probar la prueba del trazador de paquetes en algo
que no debería funcionar. Queríamos ver que el ASA en realidad bloquea el tráfico.

El servidor web no está configurado para servir tráfico FTP. Enviaremos una solicitud
de FTP al servidor web y veremos qué sucede.

ASA1# packet-tracer input outside tcp 10.1.1.200 1234 10.1.1.10 ftp

detailed
Phase: 1
Type: ROUTE-LOOKUP
 Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 10.1.1.10 using egress ifc outside

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (nat-no-xlate-to-pat-pool) Connection to PAT address
without pre-existing xlate

El ASA eliminó el paquete porque no hay reglas de NAT configuradas para transferir
el tráfico de FTP a nada. Ni siquiera llegó al punto de control de ACL.

Configuración de código Cisco ASA pre-8.3

Paso 1: Asignar nivel de seguridad a cada interfaz ASA (igual)

Paso 2: configure ASA como una puerta de enlace de Internet, habilite el

acceso a Internet

Configuramos un "NAT global" para usar la interfaz externa IP para navegar por
Internet. El número “10” es el ID de grupo de NAT que se extraerá del NAT
global. Luego, definimos el ID de grupo de NAT 10 para que cada una de las subredes
internas utilice el NAT global.

global (outside) 10 10.1.1.1

nat (inside) 10 192.168.0.0 255.255.255.0
nat (dmz1) 10 192.168.1.0 255.255.255.0
nat (dmz2) 10 192.168.2.0 255.255.255.0

Eso es todo lo que necesitabas para Internet saliente.

La ruta por defecto a la puerta de enlace de Internet se configura de la misma manera.

route outside 0.0.0.0 0.0.0.0 10.1.1.2

Paso 3: configure NAT estática para servidores web, otorgue acceso de
entrada de Internet a servidores web

Configure un NAT estático uno a uno para el servidor web. La ACL permite que
cualquier persona en Internet acceda al servidor web en el puerto 80. La diferencia en
la configuración es que usamos la IP pública de NAT en lugar de la IP interna del
servidor web en la ACL.

static (dmz1,outside) 10.1.1.10 192.168.1.10 netmask 255.255.255.255

access-list OUTSIDE extended permit tcp any host 10.1.1.10 eq www
access-group OUTSIDE in interface outside

Paso 4: Control de acceso del segmento de seguridad

Primero configuramos las ACL para permitir el acceso de DNS desde dmz2 a dmz1.

access-list DMZ2-ACL extended permit udp any host 192.168.1.10 eq

domain
access-list DMZ2-ACL extended deny ip any 192.168.0.0 255.255.255.0
access-list DMZ2-ACL extended deny ip any 192.168.1.0 255.255.255.0
access-list DMZ2-ACL extended permit ip any any
!
access-group DMZ2-ACL in interface dmz2

De forma predeterminada, el código ASA anterior a 8.3 tratará de NAT cualquier

tráfico que pase por una interfaz. No queremos que ASA realice traducciones de
direcciones de red entre interfaces internas a menos que el tráfico se dirija a la
interfaz externa. La siguiente configuración básicamente indica que el tráfico que va
desde "adentro" a "dmz1" o "dmz2" no hace NAT (o NAT a la misma IP con la que
vinieron). La misma lógica aplica el tráfico que va de dmz2 a dmz1.

static (inside,dmz1) 192.168.0.0 192.168.0.0 netmask 255.255.0.0

static (inside,dmz2) 192.168.0.0 192.168.0.0 netmask 255.255.0.0
static (dmz2,dmz1) 192.168.0.0 192.168.0.0 netmask 255.255.0.0

En las pruebas de rastreo de paquetes, puede observar que las ACL comprueban los
paquetes antes de ser NAT.

Eso es todo lo que necesita configurar en un ASA que ejecuta un código anterior a
8.3. Concluye el tutorial sobre el ejemplo de configuración de ASA DMZ de Cisco.

Puede descargar la configuración com